Skip to main content

HTB Autopilot - Full Writeup (Insane Windows, Season 12)



October 23, 2026

12 min read
Insane Windows / AD HackTheBox Season 12 Grommunio Domain Admin
Attack chain
Grommunio → Seafile SSRF → Redis Poison → grofiles RCE → PHP-FPM → Postfix root → Chisel pivot → NTLM relay → firepwd → XOR runas → Domain Admin

HTB Autopilot is an Insane-rated Windows Active Directory machine from HackTheBox Season 12. The attack chain starts with a Grommunio mail server, abuses a Seafile plugin SSRF to poison a Redis cache, achieves RCE via a sendmail hook, pivots into the internal AD environment, and ends with a Domain Admin shell via NTLM relay.

Want more detailed walkthroughs, writeups, and cybersecurity content?

01. Reconnaissance

Start where every box starts, a thorough nmap scan. Autopilot keeps things focused: port 443 is the star of the show.

nmap -sC -sV -oA autopilot 10.129.40.254

PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 8.9p1
25/tcp  open  smtp     Postfix smtpd
443/tcp open  ssl/http nginx 1.18.0
| ssl-cert: Subject: commonName=autopilot.htb
| Subject Alternative Name:
|   DNS:grommunio.autopilot.htb
|   DNS:files.autopilot.htb
|   DNS:autodiscover.autopilot.htb

The SSL certificate's Subject Alternative Names are the gift that keeps giving. Three subdomains discovered without touching a wordlist.

Pro tip: Always check SSL certificate details before reaching for wordlists. SANs often reveal the entire attack surface.

02. Grommunio Files Plugin to Seafile SSRF

Grommunio ships with a Files plugin that lets users connect external storage backends. One of those backends is Seafile, and that is where things get interesting.

The key insight: when Grommunio connects to a Seafile server to list or download files, it follows whatever URL that Seafile server returns. If we control the Seafile server and make it return a gopher URL as the download link, Grommunio becomes our SSRF puppet, reaching internal services we cannot touch directly.

Concept
Fake Seafile server → Grommunio fetches file → Grommunio follows gopher URL → Redis on localhost gets poisoned → sendmail reads poisoned cache → RCE

03. Redis Cache Poisoning via Gopher SSRF

The mechanism is elegant: Grommunio's Files plugin caches sendmail binary paths in Redis. When a share notification email is triggered, Grommunio looks up the sendmail path in Redis and executes whatever path it finds there. If we can poison that Redis key to hold a bash reverse shell, we get code execution.

The SSRF chain: Grommunio follows our gopher link, writes our Redis SET command to localhost on port 6379, and the key is poisoned.

Timing note: The gopher payload must be in the Seafile server before you trigger the file download action in Grommunio's Files UI. The FILE endpoint fires only when Grommunio tries to fetch the actual file contents.

04. Triggering RCE, Shell as grofiles

The final trigger: upload a file via WebDAV and share it via email. This makes Grommunio invoke sendmail, which reads our poisoned Redis key instead of the real binary path.

The email share type is the magic number, it forces Grommunio to invoke sendmail. Once triggered, a reverse shell lands as the grofiles user on the mail host.

Enjoying this writeup? Get the full experience on the CyberMaster app.

05. Lateral Movement via PHP-FPM FastCGI

From the grofiles shell, local enumeration reveals PHP-FPM listening on port 9000. PHP-FPM's FastCGI protocol is unauthenticated when exposed locally, and it can be abused to execute arbitrary PHP code by setting the right FastCGI environment variables.

This gives us a shell as wwwrun, a different service user that can access files grofiles cannot.

06. Privilege Escalation, Root via Postfix

With execution in the web context, we look at Postfix configuration. Postfix's master.cf defines transport services, and a misconfigured transport with a writable script gives us root.

The path: abuse the grommunio Admin API's dbconf endpoint to rewrite Postfix's daemon directory setting, then drop a malicious binary into the attacker-controlled directory. When Postfix respawns its child processes, our binary runs as root.

Key insight: Postfix's daemon directory is a privileged primitive. Any attacker who can control this setting can achieve root-level code execution on the next daemon restart.

07. Pivoting into the AD Environment

Autopilot is a Linux mail server fronting a Windows Active Directory environment. From root on the mail server, we can see the internal AD network. Time to pivot.

Chisel creates a SOCKS5 proxy through the compromised mail server, allowing us to scan the internal AD domain. A Windows host named WS02 shows up with unsigned SMB on port 445.

08. IMAP NTLM Relay to SMB on WS02

The mail server runs IMAP. When an email client connects and authenticates, it sends NTLM credentials. If we can intercept that NTLM authentication and relay it to WS02's SMB (which does not require signing), we get authenticated access as that user.

Key observation: SMB signing disabled is the prerequisite for NTLM relay. Without it, relayed authentication would be rejected.

09. Credential Extraction, firepwd on Thunderbird

On WS02, look for installed applications. Thunderbird is present, and it stores credentials in an encrypted NSS key database that can be decrypted offline with firepwd.

Domain credentials extracted. Now we can attempt to reach higher-privileged systems in the domain.

10. Go Binary Analysis, XOR Key Extraction

On WS02, there is a custom Go binary, a runas wrapper, that runs a privileged command with a hardcoded XOR-encrypted credential. Extracting it requires a bit of reverse engineering work.

Transfer the binary to Kali and analyze it with pefile. Identify the XOR key from the binary's data section, decrypt the ciphertext, and reveal the Domain Admin password.

11. Domain Admin and Root Flag

With Domain Admin credentials in hand, the rest is textbook: use psexec to get a shell on the DC as Administrator, grab root.txt, and dump all domain hashes for completeness.

root.txt: Autopilot fully compromised

Key Takeaways

1. SSL certs as recon gold. The SAN fields handed us three subdomains instantly. Always check certificate details before reaching for wordlists.

2. SSRF via storage backend. The Grommunio to Seafile to gopher chain is a clever multi-hop SSRF. Three indirections to write one cache key.

3. Redis as an execution vector. If you can write to Redis unauthenticated, you can control what binaries get executed.

4. SMB signing matters. Unsigned SMB is the prerequisite for relay attacks. In a real engagement, SMB signing should be enforced domain-wide.

5. Credential hygiene. Thunderbird credentials persisting in a roaming profile, a Go binary with a hardcoded XOR-encrypted password, both are avoidable. Credentials should never live in application configs or compiled binaries.

Final Thoughts

HTB Autopilot is a great example of a realistic enterprise attack chain. No single vulnerability is exotic, the power is in chaining them. The Grommunio SSRF into Redis is particularly creative, and the NTLM relay through the mail server's IMAP authentication is something you would find in real engagements against hybrid on-prem and cloud environments.

If you found this HTB Autopilot writeup helpful, check out more writeups and labs.

For more detailed walkthroughs, writeups, and cybersecurity content

Download the CyberMaster app and support the work

HTB Autopilot Writeup · Insane · Season 12 · Windows AD

Comments

Popular posts from this blog

HTB Touch - Full Writeup (Easy Windows, Season 12)

Buy Me a Coffee Enjoying the writeup? Support the work. Season 12, Easy Windows. Finished it in an evening. Learned more than I expected. I finished the Touch machine on Hack The Box last night. It is rated Easy, and honestly, it earns that rating. There is no memory corruption, no exotic bug, no clever bypass that makes you feel like a wizard. What it has instead is a chain of small, believable mistakes that stack on top of each other until you are sitting on a SYSTEM shell wondering how you got there. That is why I wanted to write about it. Not because the box is hard, but because it is real. The Setup Touch is a Windows box themed around an airport. It picks up a thread from the earlier Layover machine, where you uncover a passenger name and a booking reference that you then reuse here. That small continuity detail is a nice touch, and it mirrors how real attackers actually operate. They rare...

Reverse Domain Naming as an Identity Scheme: Uniqueness Without Governance

  Introduction Reverse domain name notation writing identifiers like com.example.app instead of app.example.com has become a de facto standard for naming software packages and applications. This convention is pervasive across programming ecosystems and platforms, from Java class packages to Android app IDs and iOS bundle identifiers. It was adopted to ensure global uniqueness and avoid naming collisions without requiring a central authority. However, reverse-DNS naming was never backed by formal regulation or ownership verification . In practice, any developer can choose any reverse domain string for their software, regardless of whether they own that Internet domain. This gap between implied and actual ownership creates security and trust challenges that attackers can exploit. Threat model:   Adversaries can abuse the assumed trust in domain-based names by impersonating brands or organizations in their identifiers. For example, a malicious Android app could declare a packa...

Android vs iPhone Security: Why No System is 100% Secure

When I went to the CYBERUS Spring School in early April 2025 (April 7–11, 2025, at Université Bretagne Sud in Lorient, France), one of the topics we talked about was the age old query: Which phone is safer, the  iPhone or the  Android ? The conversations were instructive to me as a security enthusiast. We discussed technical ideas like mobile app sandboxing and even how two apps from the same developer could access data in spite of platform security measures. The discussions underlined an important realization I've had over the years: while IOS and Android both have robust security mechanisms, neither is completely impenetrable. In this essay, I'll provide a professional (but hopefully easy-to-read) analysis of Android vs iPhone security, interspersed with my own viewpoints, demonstrating why no system can claim perfect security. Security by Design: IOS and Android Approaches Apple's IOS and Google's Android have fundamentally different approa...