Post cover image

June 11, 2026

Exploiting Weak Credentials, WebDAV, and SMB Shares: An INE Host-Based Attacks Walkthrough

Introduction

Aditya Bhardwaj

7 min read

Introduction

When people think about compromising Windows systems, they often imagine sophisticated exploits, zero-days, or advanced malware. In reality, many successful attacks begin with something far simpler: weak credentials, exposed services, and small configuration mistakes that quietly expand an attacker's opportunities.

In this INE Host-Based Attacks lab, I was tasked with compromising two Windows servers and recovering four hidden flags. The challenge provided a few hints, several common penetration testing tools, and some wordlists. What initially appeared to be a straightforward exercise quickly evolved into a lesson in methodical enumeration, credential attacks, WebDAV abuse, and SMB post-exploitation.

Rather than relying solely on automated exploitation, this walkthrough focuses on the thought process behind each decision, including failed attempts that ultimately revealed valuable information.

— -

Lab Objectives

Targets

  • target1.ine.local
  • target2.ine.local

Goals

  • Capture Flag 1
  • Capture Flag 2
  • Capture Flag 3
  • Capture Flag 4

Tools Used

  • Nmap
  • Hydra
  • Metasploit Framework
  • Cadaver
  • smbclient

Initial Reconnaissance

Every assessment starts with answering two questions:

  1. Is the target reachable?
  2. What services are exposed?

I began by confirming connectivity to both systems before performing service enumeration.

ping -c 4 target1.ine.local
ping -c 4 target2.ine.local

With connectivity confirmed, I moved on to service discovery.

nmap -sV -sC target1.ine.local
nmap -sV -sC target2.ine.local

Key Findings

Target 1

  • IIS 10.0 Web Server
  • HTTP Basic Authentication
  • SMB
  • RDP

Target 2

  • SMB
  • RDP

The first target immediately stood out.

The web server responded with:

401 Unauthorized

and required HTTP Basic Authentication.

At that moment, one of the challenge hints suddenly became very relevant:

-> User "bob" might not have chosen a strong password.

Whenever a lab explicitly provides a username and mentions weak credentials, it is usually signaling an intended attack path.

Rather than immediately attacking SMB or searching for hidden web content, I decided to focus on authentication.

Target 1 — Attacking HTTP Basic Authentication

My initial hypothesis was simple:

If the application relies on HTTP Basic Authentication and the challenge specifically mentions Bob, recovering Bob's password is likely the first foothold.

Why Basic Authentication Matters

HTTP Basic Authentication relies entirely on username and password validation performed by the web server.

While credentials are transmitted Base64-encoded rather than encrypted, the real weakness often lies elsewhere:

If users choose poor passwords, the authentication mechanism becomes vulnerable to password guessing attacks.

To test this theory, I launched Hydra against the authentication endpoint.

hydra -l bob \
-P /usr/share/metasploit-framework/data/wordlists/unix_passwords.txt \
target1.ine.local \
http-get /

After a short period of testing, Hydra returned valid credentials:

bob:password_123321
Hydra brute-force results showing bob:password_123321 as the valid credential for target1.ine.local

The result validated both the challenge hint and my attack path.

With valid credentials in hand, I authenticated to the web application expecting immediate access to sensitive content.

Instead, I found myself staring at the default IIS welcome page.

Default IIS Windows Server welcome page at target1.ine.local

At first, it felt like a dead end.

However, experience has taught me that successful authentication often grants access to far more than what is immediately visible.

Following the WebDAV Trail

While reviewing the lab documentation, I noticed something unusual.

The provided resources specifically referenced:

  • Cadaver
  • ASP Web Shells

Those recommendations felt oddly specific.

Why would a challenge focused on IIS provide a WebDAV client and an ASP web shell?

That question led me to suspect that WebDAV was involved.

What is WebDAV?

WebDAV (Web Distributed Authoring and Versioning) extends HTTP by allowing users to remotely manage files on a web server.

Depending on configuration, WebDAV may allow:

  • File uploads
  • File modifications
  • File deletions
  • Directory browsing

When upload permissions are combined with executable server-side technologies such as ASP, WebDAV can quickly become a path to remote code execution.

Before manually exploring, I decided to validate my theory using Metasploit.

A Failed Exploit That Revealed Valuable Information

Using Bob's credentials, I loaded Metasploit's IIS WebDAV upload module.

use exploit/windows/iis/iis_webdav_upload_asp
set RHOSTS target1.ine.local
set HttpUsername bob
set HttpPassword password_123321
exploit

The exploit failed.

No session was created.

Initially, this looked like a setback.

However, reviewing the module output carefully revealed something important.

The module reported:

  • Authentication successful
  • File upload successful
  • File rename successful

Only the final payload execution stage failed.

This changed everything.

Even though I did not obtain a shell, I had effectively confirmed that:

  • WebDAV was enabled
  • WebDAV was writable
  • File uploads were possible

The exploit had failed, but it had already provided valuable intelligence.

Rather than continuing to force Metasploit, I switched to manual enumeration.

Discovering Flag 1 Through WebDAV

Using Cadaver, I authenticated with Bob's credentials.

cadaver target1.ine.local

After connecting, I began exploring the available directories.

Almost immediately, I discovered:

/webdav

Inside the directory were several files:

flag1.txt
readme.txt
test.asp
Cadaver WebDAV client showing flag1.txt, readme.txt, and test.asp in the /webdav directory

Finding the first flag was satisfying, but another file was even more interesting.

The presence of test.asp suggested that IIS was configured to execute Classic ASP pages.

That observation was critical.

If the server processed ASP files and WebDAV allowed uploads, file upload permissions could potentially be converted into remote code execution.

The intended attack path was becoming increasingly clear.

After reading the contents of flag1.txt, I successfully captured Flag 1.

Achieving Remote Code Execution

With ASP execution confirmed, I uploaded an ASP web shell through WebDAV.

put /usr/share/webshells/asp/webshell.asp

The upload succeeded immediately.

After navigating to the uploaded file through a browser, I was presented with a functional command execution interface.

At that point, I had effectively transformed file upload access into remote code execution.

To verify execution, I ran:

whoami

The command executed successfully.

ASP web shell running on target1.ine.local showing server info

The next challenge hint stated:

Valuable files are often on the C: drive.

Rather than overcomplicating the process, I began with simple filesystem enumeration.

Sometimes the simplest approach is the correct one.

Capturing Flag 2

While browsing the root of the C: drive, a file immediately stood out:

C:\flag2.txt

The challenge designers had been surprisingly literal.

Reading the file revealed the second flag.

type C:\flag2.txt
Web shell showing C drive directory listing with flag2.txt Web shell reading flag2.txt content showing the captured flag value

With Target 1 complete, I shifted my attention to the second server.

Target 2 — An SMB-Centric Attack Surface

Unlike the first host, Target 2 presented a much smaller attack surface.

There was:

  • No web application
  • No WebDAV
  • No obvious upload functionality

Only SMB and RDP were exposed.

The challenge hint stated:

By attempting to guess SMB user credentials, you may uncover important information that could lead you to the next flag.

This strongly suggested that SMB authentication would be the primary entry point.

First, I tested anonymous access.

smbclient -L //target2.ine.local -N

The result:

NT_STATUS_ACCESS_DENIED

Anonymous enumeration was disabled.

Credential attacks would be required.

A Valuable Lesson About Hydra

I launched Hydra against SMB using the supplied user and password wordlists.

My initial run used the -f option:

hydra \
-L /usr/share/metasploit-framework/data/wordlists/common_users.txt \
-P /usr/share/metasploit-framework/data/wordlists/unix_passwords.txt \
target2.ine.local smb -t 32 -f

Hydra quickly discovered:

rooty:spongebob

At first, I considered stopping there.

However, curiosity got the better of me.

I removed the -f flag and allowed Hydra to continue testing.

That decision proved crucial.

Additional credentials began appearing:

rooty:spongebob
demo:password1
auditor:hellokitty

This reinforced an important lesson:

The first valid credential is not always the most valuable credential.

Had I stopped after discovering Rooty's account, I would have missed the administrator credentials entirely.

Escalating to Administrative SMB Access

Why Administrative Shares Matter

administrator:pineapple

Using those credentials, I enumerated available shares.

smbclient -L //target2.ine.local -U administrator

Among the available shares were:

ADMIN$
C$
Shared
Shared2
Shared3

Why Administrative Shares Matter

Windows automatically creates hidden administrative shares such as:

  • ADMIN$
  • C$

Access to these shares is typically restricted to administrators.

Successful access effectively provides direct visibility into the underlying filesystem.

When I connected to the C$ share, I immediately gained access to the system drive.

smbclient //target2.ine.local/C$ -U administrator
None

While enumerating the root directory, I quickly discovered:

flag3.txt

After downloading the file, I successfully recovered Flag 3.

Following the Final Hint

Only one objective remained.

The final challenge hint stated:

The Desktop directory might have what you're looking for.

With administrative SMB access already established, following that hint was straightforward.

I navigated through:

C:\Users\Administrator\Desktop

Inside the Desktop directory sat:

flag4.txt

Exactly where the hint suggested it would be.

Lessons Learned

This lab reinforced several practical lessons that apply far beyond a training environment.

Weak Passwords Remain Dangerous

Both attack paths began with credential attacks rather than software vulnerabilities.

Poor password choices continue to create compromise opportunities.

Failed Exploits Can Still Be Valuable

Metasploit never produced a shell.

However, its output confirmed that WebDAV was writable, which ultimately led to manual exploitation.

Enumeration Often Beats Exploitation

The most valuable discoveries came from understanding the environment rather than blindly launching exploits.

Administrative Shares Are Powerful

Once administrative SMB credentials were obtained, filesystem access became trivial.

Don't Stop at the First Credential

Removing Hydra's -f flag revealed the most valuable account in the entire lab.

Sometimes patience pays off.

Conclusion

This lab demonstrated a complete attack chain built primarily on weak credentials, service enumeration, and post-authentication abuse.

The compromise of the first target relied on recognizing the significance of HTTP Basic Authentication, identifying WebDAV functionality, and converting file upload access into remote code execution. The second target highlighted the value of thorough credential testing and the power of administrative SMB access.

More importantly, the exercise reinforced a lesson that applies to real-world assessments:

Successful penetration testing is rarely about launching the most sophisticated exploit.

It is about gathering evidence, forming hypotheses, validating assumptions, and allowing enumeration to guide the next step.

Every flag recovered in this lab was ultimately the result of following information uncovered during the assessment rather than making assumptions about where the attack should go next.