Forem: itsmegsg

Web Pentesting Beginner Roadmap (2026): From Recon to Server-Side Attacks

itsmegsg — Thu, 19 Mar 2026 13:26:04 +0000

The Web Pentesting Beginner’s Roadmap: From Recon to Server-Side
A structured reference guide for anyone who just finished their first web security course.

After completing the Hacksmarter Web Pentesting course, I wanted to consolidate the methodology into a single source of truth. Whether you are preparing for a bug bounty or just securing your own apps, this is the mental framework you need.

1. Reconnaissance (The Foundation)

Pro-Tip: Always check robots.txt and sitemap.xml before running heavy scans. You’d be surprised what developers "hide" in plain sight.

Fingerprinting: Use Curl, Burp/Caido, or the Wappalyzer extension to identify the tech stack.

Directory Brute Forcing: Dirsearch, dirb, or gobuster to find hidden endpoints.

Subdomains & Vhosts: FFUF (with custom scripts) and gobuster.

Business Logic Prep: Become a user! Map out the site functionalities. What can a standard user do vs. an Admin?

OSINT: Google Dorks, Shodan, and Nmap for port scanning.

2. Authentication Assessment

Credential Attacks: Testing for weak passwords and credential stuffing.

MFA Bypass: Can you skip the 2FA step by manipulating the URL or response?

Password Resets: Testing for predictable tokens or Host Header Injection in reset links.

OAuth: Checking for misconfigured redirect URIs.

3. Session Management

Cookie Security: Ensure HttpOnly and Secure flags are set.

Session Fixation: Does the session ID stay the same after login? (It shouldn't).

JWT (JSON Web Tokens): Test for weak secrets or the infamous alg: none vulnerability.

4. Authorization (The "Permission" Gap)

IDOR (Insecure Direct Object Reference): Changing id=123 to id=124 to see someone else's data.

Broken Access Control: Accessing /admin as a guest.

Mass Assignment: Can you add "is_admin": true to a profile update JSON?

5. Client-Side Vulnerabilities

XSS: Reflected, Stored, and DOM-based attacks.

CSRF: Forcing users to perform actions without their consent (e.g., changing an email).

The Rest: Open Redirects, CORS misconfigurations, HTML Injection, and Clickjacking.

6. Server-Side Vulnerabilities

Injections: SQLi and NoSQLi.

SSRF: Forcing the server to make requests to internal metadata services (e.g., AWS/GCP).

File Uploads: Bypassing filters to upload a Web Shell (PHP/JSP).

Execution & Traversal: Path Traversal, SSTI (Template Injection), and OS Command Injection.

The Open Book of Active Directory: Leveraging (and Securing) LDAP Queries

itsmegsg — Sun, 18 Jan 2026 11:51:41 +0000

1. Introduction: The Convenience Trap

Active Directory (AD) is designed for collaboration. By default, it acts like a global office directory. However, this convenience often leads to an information disclosure vulnerability. Even a low-privileged user can query a massive amount of data about every other user, group, and machine in the domain.

In this article, we explore how an attacker uses simple LDAP queries to extract sensitive information and how a Blue Teamer can surgically shut those leaks down using dsacls.

2. The Lab Setup

To follow along, the lab environment consists of two virtual machines on the same NAT network:

Target

Windows Server 2019
Domain Controller: cybercommando.org

Attacker

Kali Linux

Scenario

The attacker has already gained an initial foothold and possesses credentials of a standard domain user:

Username: prabhu

3. What is ldapsearch?

ldapsearch is a command-line utility used to query LDAP directories. While Windows administrators often rely on PowerShell and GUI tools, ldapsearch is the Swiss Army Knife for attackers and Linux-based administrators.

It allows you to:

Bind (authenticate) to a Domain Controller
Perform granular searches using LDAP filters
Retrieve raw directory attributes

4. The Attacker's Reconnaissance

Once inside the network, the attacker does not need exploits. They only need to ask Active Directory the right questions.

The Global User Search

The attacker begins by listing all users and inspecting metadata fields for human mistakes.

ldapsearch -h "URL" -x -D "user@domain_name" -W -b "Domain_Name" "(objectClass=user)" description

Explanation

-x : Simple authentication
-D : Bind DN (compromised user)
-b : Base DN (search root)
description : Attribute being queried

The Leak

The attacker discovers a user object where an administrator mentioned important details in the description field.

Because Authenticated Users have read access by default, this sensitive information is exposed to any logged-in domain user.

Impact

With this leaked password, an attacker can:

Perform password spraying
Identify accounts still using default credentials
Escalate privileges silently

5. Blue Team Defense: Surgery with dsacls

Deleting the description value is only a temporary fix. The real solution is controlling who can read sensitive attributes.

Goal

Admins can read the description
Standard users cannot

The dsacls Command

Run the following on the Domain Controller:

dsacls "CN=manoj,CN=Users,DC=cybercommando,DC=org" /D "Authenticated Users":RP;description

Breakdown

CN=manoj,... : Target user object
/D : Explicit deny
Authenticated Users : Group being restricted
RP;description : Deny Read Property for the description attribute only

This command can be adapted to protect multiple users or entire OUs.

6. Verification

Back on the Kali machine, rerun the same ldapsearch command.

Result

The user object is returned
The description attribute of User: Manoj is missing

Why This Works

The Domain Controller evaluates the ACL, detects the explicit deny rule, and redacts the sensitive attribute before responding.

Conclusion: Privacy Is a Permission

Active Directory security is not only about strong passwords; it is about visibility control.

Understanding how attackers view AD through LDAP allows Blue Teamers to:

Identify silent data leaks
Enforce the principle of least privilege
Harden environments without breaking functionality

Rule of thumb:

If a standard user does not need to see an attribute to do their job, they should not be able to see it at all.

Windows Registry Internals — A Beginner-Friendly Deep Dive

itsmegsg — Sat, 20 Dec 2025 12:17:52 +0000

What We’ll Cover

Windows Registry Internals

Unit 1: Architecture & Anatomy
Unit 2: The Logical Structure
Unit 3: Data Types & Values
Unit 4: Tools & Manipulation

Unit 1: Architecture & Anatomy

The Windows Registry is a hierarchical database that stores low-level configuration settings for the operating system and applications.

Almost every serious Windows component talks to the registry in some form.

1. The Concept of “Hives”

A Hive is a logical group of registry keys backed by physical files on disk.

At boot time, Windows loads these hive files and assembles the registry tree.

2. Physical Location of Registry Hives

Most system hives are stored at:

C:\Windows\System32\config

Critical Hives

Hive	Purpose
SAM	User accounts & password hashes
SECURITY	Local security policies
SOFTWARE	Installed software settings
SYSTEM	Drivers, services, boot config
DEFAULT	Default user profile

The User Hive (Exception)

Each user has a personal hive:

C:\Users\<Username>\NTUSER.DAT

This contains user-specific settings like wallpaper, mouse speed, and application preferences.

Unit 2: The Logical Structure (Root Keys)

Windows presents registry data using logical Root Keys.

The Big Two

HKEY_LOCAL_MACHINE (HKLM)

Applies to the entire system
Shared by all users
Backed by SYSTEM, SOFTWARE, SAM, SECURITY hives

HKEY_CURRENT_USER (HKCU)

Applies only to the logged-in user
Backed by NTUSER.DAT

Derived Root Keys

HKEY_USERS (HKU) – All loaded user profiles
HKEY_CLASSES_ROOT (HKCR) – File associations
HKEY_CURRENT_CONFIG (HKCC) – Hardware profile at boot

Unit 3: Keys, Values & Data Types

Keys act like folders
Values act like files

Each value has:

Name
Type
Data

Common Data Types

REG_SZ

Human-readable string

REG_DWORD

32-bit integer (often used as on/off flags)

REG_BINARY

Raw binary data

REG_EXPAND_SZ

Expandable string with variables like %SystemRoot%

REG_MULTI_SZ

Multiple strings stored as a list

Unit 4: Tools & Manipulation

Registry Editor

Open with:

Win + R → regedit

⚠️ Always export a key before editing.

Backup & Restore

Export: Right-click key → Export
Restore: Double-click .reg file

Automation with .reg Files

If you want to make changes to registry, you can simply create a .reg file, double click it and make changes.
Here as an example we are creating a .reg file for creating a game setting of FULLSCREEN. Since fullscreen settings have boolean value of On/Off we have used the REG_DWORD value here to set it to 1 ie true,.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\MyGame]
"PlayerName"="itsmegsg"
"FullScreen"=dword:00000001

Command Line (REG)

Command-Line can also be used to make changes to Windows Registry. Here is a simple example.

REG ADD HKCU\Software\MyGame /v PlayerName /t REG_SZ /d "itsmegsg"

Final Thoughts

The Windows Registry is foundational for Windows internals, malware analysis, forensics, and Active Directory security.

Once you understand its structure, it becomes a powerful ally instead of a black box.

Hunting Malware Like a Pro: A Beginner's Guide to YARA

itsmegsg — Sun, 14 Dec 2025 12:49:00 +0000

Introduction: The "Ctrl+F" of Cyber Security

Imagine you are looking for a specific needle in a massive haystack. Now, imagine that needle is a piece of malware hiding inside thousands of files on a corporate server. How do you find it? You don't browse manually—you use YARA.

YARA (Yet Another Ridiculous Acronym) is the industry standard tool for malware research and detection. It allows defenders to create descriptions (called "rules") of malware families based on text or binary patterns. Think of it as a super-powered "Ctrl+F" that doesn't just look for words, but for the specific DNA of a virus.

YARA was created by Victor Alvarez of VirusTotal (now owned by Google). It has since become the Swiss Army Knife for the entire security industry.

If you are getting into YARA, you cannot ignore Florian Roth (known as Neo23). He is arguably the most prolific writer of YARA rules in the community. His GitHub repositories (like signature-base) are the gold standard, providing thousands of free rules that protect companies worldwide.

What Does YARA Actually "See"?

YARA is a Static Analysis tool. This means it inspects files without actually running them (which is safer!). It primarily looks for three things. Here is how to understand them without the computer science jargon:

1. Strings (The Words)

This is the simplest layer. YARA looks for specific readable text inside the file.

Example: If a hacker writes a program and leaves the sentence "Hacked by Lazarus" inside the code, YARA can search for that exact phrase.
Limitation: Attackers often encrypt or scramble their words to hide them.

2. Binary Patterns (The DNA)

Not everything in a computer file is readable text. Most of it is "machine code"—the raw instructions the computer CPU reads.

Analogy: Even if a virus changes its name, the raw code (Hexadecimal patterns) used to build it often stays the same. YARA scans for these "digital fingerprints" inside the hex of the file.

3. Behaviors (The Blueprint)

Wait, if YARA doesn't run the file, how does it see behavior?

The Blueprint Analogy: YARA looks at the "Import Table" of a file—a list of tools the program asks Windows to provide.
Example: If YARA sees a file packing "Microphone Access" and "Internet Connection" tools, it infers the behavior: Spyware. It doesn't need to watch the spy work; it just checks the spy's bag.

Proof of Concept: Catching the "Internet Hunter"

To show you how this works in practice, I built a simple Proof of Concept (POC) in my Kali Linux lab.

The Goal: Write a YARA rule that detects any Windows program capable of connecting to the internet, regardless of what the file is named.

Step 1: Creating the "Dummy Malware"

I wrote a small C program that doesn't do anything malicious, but it imports the WININET.dll library. This is the standard Windows library used for browsing the web. If a program has this, it has the capability to talk to the internet.

#include <windows.h>
#include <wininet.h>
#include <stdio.h>

int main() {
    // We just load the internet tools, we don't attack anything!
    HINTERNET hInternet = InternetOpenA("MalwareAgent", INTERNET_OPEN_TYPE_DIRECT, NULL, NULL, 0);

    if (hInternet) {
        printf("Internet Library Loaded Successfully!\n");
    }
    return 0;
}

I compiled this into a Windows Executable (internet_test.exe) using the MinGW compiler on Kali.

Step 2: Writing the YARA Rule

Now, I wrote a rule named yara_for_internet. I told YARA to look for the "MZ" header (which proves it is a Windows .exe file) AND the specific library string "WININET.dll".

import "console"

rule yara_for_internet
{
   meta:
     author = "itsmegsg"
     description = "Checks for executables that can connect to the internet"
     confidence = "medium"

   strings:
     $mz = { 4D 5A }           This is for Mark Zowkowsksi
     $dll = "WININET.dll"      This is for the dll file
     $int = "InternetOpenA"     This is for the specific function

   condition:

     ($mz and ($dll or $int))  - I put a simple condition here. It should be an executable with either WININET or InternetOpenA

}

Step 3: The Moment of Truth

I ran the rule against my folder containing the dummy malware.

Command:
yara yara_for_internet.yar <folder path>

Folder contents - I am scanning this entire file with the above YARA rule

The Result:

As you can see, YARA immediately flagged the file. It looked inside the file's structure, saw the tools it was carrying, and alerted me immediately.

Conclusion

YARA moves us from "guessing" to "hunting." Instead of waiting for an antivirus update, we can write our own logic to detect threats based on what they are and what they can do.

If you are getting started in Blue Teaming, mastering YARA is one of the best investments you can make.

Introducing osquery_hunter — Lightweight Windows Triage Tool for DFIR & Threat Hunting

itsmegsg — Sat, 18 Oct 2025 03:31:38 +0000

Introducing osquery_hunter

When you're working a security incident and don't have an EDR agent or enterprise console to lean on, you still need a quick way to understand what's running on a Windows host.

That’s where osquery_hunter comes in — a simple Python-based helper that uses osquery to collect process and network data, then flags unsigned or suspicious binaries for rapid triage.

What It Does

Lists all active processes and network sockets using osquery.
Flags executables not simultaneously trusted in the local Windows trust store and Microsoft-signed.
Displays potential LOLBIN (Living off the Land) usage.
Helps identify unsigned or third‑party binaries still active in memory.
Perfect for quick DFIR triage, incident response, and blue‑team checks.

Requirements

Python: 3.10+ (tested on 3.11)
osquery: version 5.19.0 (Windows x64)

Official download: https://osquery.io/downloads/

Verified SHA256 (osqueryi.exe):

EDA5AC01F705F976957ABD8C9D14BBD355616EBEF6C5B45F28A2AE44F53E207D

Quick Start

# 1. Create and activate a virtual environment (optional)
python -m venv .venv
. .\.venv\Scripts\Activate.ps1

# 2. Install dependencies
pip install -r requirements.txt

# 3. Run the script
python .\osquery_hunter.py

If osqueryi.exe isn’t on PATH, point to it directly:

$env:OSQUERYI_PATH = "C:\Program Files\osquery\osqueryi.exe"

Why This Project Exists

In many environments, especially air‑gapped or restricted systems, analysts don’t have EDR coverage everywhere.

osquery_hunter gives you a portable way to inspect process behavior and verify binary signatures using native Windows APIs and osquery data.

It’s open source and fully auditable — designed to complement, not replace, commercial tools.

Repository

👉 GitHub: ItsmeGSG/osquery_hunter

Closing Thoughts

The best DFIR tools are often the simplest.

osquery_hunter started as a lab helper and evolved into a compact, no‑dependency triage companion that gives you insight into what’s really happening on a Windows box.

Give it a star ⭐ on GitHub if you find it useful or extend it for your environment!

MIT Licensed — developed for educational and defensive security purposes.

ADS — Alternate Data Streams (Beginner friendly PoC)

itsmegsg — Tue, 30 Sep 2025 16:35:59 +0000

One-line summary: NTFS Alternate Data Streams (ADS) let a file carry named hidden streams of data (e.g. file.txt:secret). They’re useful for metadata but can be abused for stealthy storage — here’s a safe, beginner lab showing how to hide an image or a benign PowerShell script in an ADS and how to run it in a controlled environment.

⚠️ Lab safety & ethics: Run these steps only in an isolated Windows VM with an NTFS disk. Snapshot the VM first. Do not try on production systems or devices you don’t own/authorize.

What is an ADS? (short & simple)

An Alternate Data Stream (ADS) is an extra named data stream attached to an NTFS file. The normal content you see is the default stream. An ADS is like a hidden compartment inside a briefcase — the briefcase is the visible file, and the ADS is the hidden pocket.The beauty is you can create any number of secret compartments(ADS) for a single file.

Key facts :

ADS is an NTFS feature (not FAT/exFAT) and may be lost if the file is moved to a non-NTFS filesystem.
A file can hold multiple named streams: filename:stream1, filename:stream2, etc.
Explorer shows only the default stream size; ADS bytes are stored in NTFS metadata (MFT) and require special tools to see.
There is no simple NTFS switch to disable ADS — defenders must scan and monitor for them.

Why it matters

Legitimate uses: metadata, compatibility with legacy resource forks, application-specific needs.
Abuse potential: attackers can hide scripts, small binaries, images, or exfiltrated data inside ADS to evade cursory checks. Modern AV/EDR can and does detect many ADS-related behaviours, but ADS remains a stealthy lever in many scenarios.

Important ADS commands (cmd method)

Commands


echo Diwali wishes > C:\Lab\Diwali.txt    # To create visible host file, in this case a TXT file named Diwali.

copy /b "C:\Lab\images\diya.jpg" "C:\Lab\Diwali.txt:Diya"   # Command to copy a image file to the ADS of Diwali.txt

dir /R C:\Lab # Command to list all ADS files in a directory. 

copy /b "C:\Lab\Diwali.txt:Diya" "C:\Temp\Diya_extracted.jpg"   # Command to extract the image file from ADS and paste it in a folder

start "C:\Temp\Diya_extracted.jpg"  # Command to open the file

What you’ll see

dir /R or streams -s C:\Lab will show Diwali.txt:Diya.
After extract, the default image viewer opens the Diya_extracted.jpg.

I am attaching screenshots with similar commands executed in my VM.

PowerShell payload in ADS (PoC)

Quick lab PoC overview

Step 1. A harmless looking Image-File is downloaded into the victim machine.
This is the payload/exploit for this particular setup. This seemingly harmless text file has ADS with powershell scripts in it. Since this is a lab setup the powershell script is kept to bare minimum. It scans for images stored in the system. It copies all such files to a location within the system. It compresses and makes them into a single file. It finally uploads the file to a remote server. Ideally I would have put 2 more lines to break the compressed file into smaller chunks. Since this is a lab setup and I had very few photos in my VM, I took the liberty of not doing it.

Step 2. The AD script is shown in the below screenshot. It is obfuscated to hide few details. But the important fact is such scripts can be written with very little effort.

Powershell script is partly shown :

Step 3. The script is executed. I have also attached a screenshot to show that a .rar file has been created because of the powershell script. This entire exercise emulates a classic data exfiltration scenario.

Executing the script:

Final result in victim machine:

Cleanup (remove ADS and artifacts)

# remove ADS from host file
Remove-Item -Path 'C:\Users\Testuser1\Downloads\Diwali_wishes.jpg' -Stream Cracker -ErrorAction SilentlyContinue

Detection & Blue-Team hints (short)

Quick tools: Sysinternals streams.exe (streams -s <path>) and PowerShell Get-Item -Stream *.
Automated scan: run a scheduled PowerShell script that enumerates files with more than one stream and reports them (I’ll publish one in the Blue-Team post - my subsequent post).
Logging & monitoring: watch for suspicious PowerShell process invocations that read unusual file streams or for CreateProcess events where command lines reference temp extracts. Use Procmon/Sysmon to capture and tune alerts.
Forensics: MFT and USN journal entries can help timeline ADS creation/deletion.

Conclusion & what’s next

ADS is a small NTFS feature with outsized impact: it’s legitimately useful but can be abused for stealth. In this post we created ADS entries for both an image and a benign PowerShell payload, demonstrated in-memory execution, and showed verification and cleanup steps.

Next post (coming soon): a detailed Blue-Team guide showing a reusable PowerShell ADS scanner, Sysmon rules to detect suspicious ADS usage, a Procmon walkthrough, and a short response playbook for triage & remediation. Stay tuned!

References & further reading

Microsoft docs on file streams and NTFS (search for NTFS alternate data streams).
Sysinternals Streams.exe — small tool for listing/deleting streams.

Abusing LOLBins: rundll32.exe Lab & Sysmon Detection

itsmegsg — Tue, 02 Sep 2025 06:41:54 +0000

1. Introduction

When attackers compromise a Windows system, they don’t always drop flashy malware. Instead, they often live off the land by abusing built-in Windows tools that administrators themselves rely on. These tools, known as LOLBins (Living-Off-the-Land Binaries), are signed by Microsoft and trusted by the OS. Because of this, their misuse often slips past antivirus and security defenses.

In this post, we’ll explore what LOLBins are, why they are stealthy, and walk through a hands-on lab where a simple DLL is executed using the LOLBin rundll32.exe. Finally, we’ll flip perspectives to the defender’s side and see how Sysmon logs reveal the tell-tale signs of abuse.

2. What are LOLBins?

LOLBins are legitimate executables and scripts that come pre-installed with operating systems (like Windows). Attackers can abuse them to perform malicious actions without dropping custom malware.

Examples:

rundll32.exe
certutil.exe
powershell.exe
mshta.exe

Since they are signed by Microsoft and widely used for admin tasks, their execution often bypasses security controls and raises less suspicion.

👉 How attackers use LOLBins:

Downloading payloads
Executing arbitrary code
Lateral movement
Data exfiltration

👉 How defenders detect misuse:

Monitor unusual command-line arguments
Trace parent-child process relationships
Analyze telemetry from Sysmon or EDR tools

3. Why are LOLBins Stealthy?

LOLBins are stealthy because:

They are trusted, signed binaries already present in Windows.
They allow attackers to avoid dropping new executables (lowers AV detection risk).
They can proxy malicious commands through normal admin utilities (e.g., certutil for downloads, rundll32 for DLL execution).
Their execution blends in with normal system/admin behavior.
They often run with inherited or elevated privileges, giving attackers powerful access while appearing benign.

4. Lab Setup

4.1 Basic Windows-Only Setup

In this setup, I created a .dll file locally and executed it with rundll32.exe.

The Hello.dll file is harmless and only pops up a message box.
But an attacker could replace it with malicious code.

What happened?

I compiled a DLL with an exported function.
Used rundll32.exe to execute it.
Proof: the pop-up “Hello from rundll32”.

Why rundll32.exe?

Built-in LOLBin, signed by Microsoft
Loads and executes arbitrary DLLs
Can bypass application whitelisting controls

👉 Significance: even though the message box is harmless, the same method could load a Cobalt Strike beacon, keylogger, or ransomware.

4.2 Advanced: Kali + Windows Setup

Here I simulated a more realistic attacker scenario using Kali + Windows.

Attempted to download Hello.dll from Kali to Windows using certutil.
WSC blocked the download.
Switched to PowerShell Invoke-WebRequest and successfully downloaded it.
Executed DLL using rundll32.exe.

4.3 Blue-Team Activities

Sysmon Event ID 1 (Process Creation) revealed the suspicious process:

CommandLine → shows rundll32.exe loading a DLL from Desktop (unusual).
ParentProcess → cmd.exe, confirming it was manually launched.
User & IntegrityLevel → shows who executed it and privilege level.
Hashes → defenders can track the specific DLL in the future.

Key Fields to Watch in Event ID 1:

Image → C:\Windows\System32\rundll32.exe
CommandLine → rundll32.exe C:\Users\testuser1\Desktop\Hello.dll,HelloExport (suspicious location)
CurrentDirectory → C:\Users\testuser1\Desktop\ (should normally be System32)
User → ANNU\testuser1
ParentImage → cmd.exe (manual execution chain)
Hashes → unique fingerprint (can be checked in VirusTotal)
IntegrityLevel → High (ran with elevated permissions)

5. Conclusion

LOLBins highlight a critical reality in modern security: attackers don’t always need to bring their own tools. By abusing trusted binaries like rundll32.exe, they can execute arbitrary code, evade detection, and blend into normal activity.

Even a harmless “Hello World” DLL shows how dangerous this technique can be if swapped for real malware.

👉 For defenders: monitor command-line arguments, parent-child processes, and execution paths (like DLLs from user directories). Understanding these abuse cases helps red teams demonstrate risk and blue teams detect attacks.

Lab Setup: Using SOCKS Proxies, ProxyChains, and SSH Dynamic Port Forwarding

itsmegsg — Fri, 15 Aug 2025 05:43:38 +0000

Meta Description: Step-by-step SOCKS proxy lab setup with SSH dynamic port forwarding, ProxyChains integration, and real pentesting scenarios with screenshots.

LAB SETUP for achieving SOCKS PROXY

Networking setup

I have 3 VMs with multiple virtual network adaptors in each. I have explained them briefly here:

a. Kali (Attacker)

├─ eth0: 192.168.56.x → Host-only network that can talk to Ubuntu

└─ eth1: 10.0.2.x → NAT ( For Internet)

b. Ubuntu (Jump Host)

├─ enp0s3: 192.168.56.x → Host-only network with Kali

└─ enp0s8: 10.10.20.1 → Internal network that can talk to Windows machine

c. Windows Server 2019 (Target)

└─ NIC: 10.10.20.x → Internal network with Ubuntu

Prerequisites

-SSH is installed & enabled in both Ubuntu & Kali.

Setting up the SOCKS proxy from my attacker machine (KALI)

What ssh -D does

The -D [port] option sets up dynamic port forwarding.
SSH listens on a local port (e.g., 127.0.0.1:1080).
That port speaks SOCKS protocol (SOCKS4 or SOCKS5 depending on your client request).
Any program that supports SOCKS can send traffic to this port.

SSH then forwards that traffic over the encrypted SSH connection to the remote host, which then connects to the destination server on your behalf.

Using nmap scans to scan the windows machine from my Kali. Remember, Kali cannot ping/reach the windows machine directly.

SOCKS in comparison to SSH Local port forwarding.

a. When local port forwarding is used you cannot use any other port other than the one for which port forwarding is setup.

b. Whereas using socks “D” dynamic port forwarding makes every port accessible from the Kali.

Combining proxychains with SOCKS

Here I have used proxychains to do a nmap scan of the otherwise unreachable host. Also, I have shown that ICMP pings are not proxied because ProxyChains only supports TCP connections. This is why the ping test fails even when other tools work.

Top Tools and Applications That Support SOCKS5 Proxies

itsmegsg — Fri, 15 Aug 2025 05:43:17 +0000

Meta Description: Explore popular tools and applications that support SOCKS5 proxies, including browsers, SSH tunnels, Tor, and penetration testing frameworks.

Tools and Applications That Use SOCKS5 Proxies

Finally, let’s look at some common tools, services, and applications that leverage SOCKS5 proxies. Knowing these will help you recognize where SOCKS proxies can fit into your workflow or network design:

· Web Browsers: Most web browsers support SOCKS proxies. For example, Mozilla Firefox and Google Chrome can be configured to use a SOCKS5 proxy for all web traffic. This is useful for quickly testing a website through a proxy or routing browsing activity via an anonymizing network. A common scenario is setting your browser’s proxy to 127.0.0.1:9050 (Tor’s local SOCKS proxy) to route all traffic through the Tor network for anonymity. Browser extensions like FoxyProxy make it easy to switch proxies on the fly (e.g., toggling between a Burp Suite proxy and a SOCKS pivot proxy as described in some dev.to tutorials).

· OpenSSH (SSH Dynamic Port Forwarding): The ssh client has a built-in option -D that opens a local SOCKS5 proxy on the specified port. This is a fantastic tool for admins and pentesters. By running ssh -D 1080 [user]@[jumpbox], you create a SOCKS5 proxy at localhost:1080 that tunnels through your SSH connection to the remote host. No special software needed — you’re effectively using SSH as an encrypted SOCKS VPN. Many people use this trick to access internal networks or even to securely browse the internet via their home server when on untrusted Wi-Fi.

· Tor (The Onion Router): Tor is an anonymity network that routes traffic through multiple encrypted relays. Importantly, the Tor client itself exposes a SOCKS5 proxy interface on your machine (by default on port 9050). Applications that want to use Tor simply point their traffic to this local SOCKS5 proxy. Tools like ProxyChains often use this, and even the Tor Browser internally uses the SOCKS proxy to send your web requests into the Tor network. So while Tor is much more than just a single proxy, from the user’s perspective it behaves as a local SOCKS5 proxy that gives you access to the entire Tor network.

· ProxyChains and ProxyCap/Proxifier: We discussed ProxyChains on Linux. On Windows, Proxifier and ProxyCap are popular GUI tools that allow you to force applications to use a proxy (they can work with SOCKS5). These tools are used in environments where an application doesn’t natively support proxies. For instance, if a particular corporate app has no proxy settings but you need it to go through a SOCKS proxy, Proxifier can intercept its traffic and redirect it. Proxifier supports SOCKS5, SOCKS4, HTTP proxies, etc., and can apply rules for which traffic to proxy.

· Shadowsocks: Shadowsocks is an open-source encrypted proxy project widely used to bypass censorship (notably in countries with heavy internet filtering). Technically, Shadowsocks is a secure SOCKS5 proxy: you run a Shadowsocks client locally which provides a SOCKS5 proxy interface, and it encrypts and relays traffic to a Shadowsocks server elsewhere. Because it uses encryption and can often evade detection, it’s used as a lightweight alternative to VPNs. For our purposes, it’s an example of a tool built on the SOCKS5 protocol, extending it with encryption.

· Metasploit and C2 Frameworks: Many penetration testing frameworks have features to create SOCKS proxies for pivoting. For instance, Metasploit can deploy a SOCKS4a proxy on a compromised host (via meterpreter) – allowing the attacker to route tools through that host. Other red-team C2 platforms (Cobalt Strike, etc.) also offer SOCKS proxy modules. While these might not be user-facing “tools you run,” it’s good to be aware that under the hood they are using the SOCKS protocol for providing pivoting infrastructure.

· Chisel and SSHuttle: These are tools for creating tunnels and pivots. Chisel is described as “a fast TCP/UDP tunnel, transported over HTTP, secured via SSH.” In practice, one of Chisel’s common use modes is to create a SOCKS5 proxy to pivot into a network (similar to SSH -D but using the Chisel client/server). SSHuttle is another tool that transparently tunnels traffic (often compared to a poor man’s VPN), but conceptually it’s doing a similar job. These tools often go hand-in-hand with ProxyChains — for example, a pen-tester might run Chisel to establish a SOCKS proxy through a compromised host, then configure ProxyChains to use that SOCKS proxy, enabling all their tools to work through the new tunnel.

· BitTorrent and Other P2P Clients: Many BitTorrent clients (uTorrent, qBittorrent, Vuze, etc.) allow configuration of a SOCKS5 proxy for all peer communications. Users concerned about exposing their IP on P2P networks use this to funnel torrent traffic through a proxy (often one provided by a VPN service). SOCKS5 is ideal since it supports UDP (used by torrent trackers and the DHT system) – something HTTP proxies can’t do – and doesn’t modify data (ensuring the torrent protocol functions correctly). Keep in mind, this hides your IP from other peers, but unless the proxy itself is encrypted or combined with a VPN, your ISP can still detect that you’re torrenting.

· Automation Tools and APIs: Various programming languages and tools have native support for SOCKS. For example, Python’s requests library or Node.js can often be configured to use a SOCKS proxy for outgoing connections. This is useful when writing scripts that need to scrape websites, test from different network vantage points, or connect through intermediate hops. Even cURL supports SOCKS5 (--socks5 flag) which is handy for quick tests. Many QA teams use these to simulate traffic from different IPs or to test failover via backup proxies.

In essence, any time you need a generic, flexible proxy solution, SOCKS5 is the go-to, and there’s a rich ecosystem of tools that support it. Cybersecurity professionals, in particular, should be comfortable with setting up and using SOCKS proxies and tools like ProxyChains, because they are invaluable for safe reconnaissance, controlled exploitation, and accessing segregated networks during engagements.

Conclusion: SOCKS proxies might not be as commonly discussed as VPNs or HTTP proxies in everyday life, but in technical circles (especially networking and security) they are extremely useful. We started with the basics – a SOCKS proxy is a middleman that relays traffic without caring what that traffic is – and then delved into how that simple concept enables a wide range of advanced uses from pentest pivoting to anonymous browsing. We compared SOCKS with other proxies and VPNs, highlighting where each shines. Armed with this understanding, you should be able to identify when a SOCKS5 proxy could help in your work, configure one (perhaps with a quick ssh -D or a proxy service), and integrate it with tools like ProxyChains for maximum effect. Happy proxying!

Next: Part 6 – Lab Setup: Using SOCKS Proxies, ProxyChains, and SSH Dynamic Port Forwarding

Proxy Chaining Explained: Using ProxyChains for Stealth and Pivoting in Pen-Testing

itsmegsg — Fri, 15 Aug 2025 05:42:41 +0000

Meta Description: Understand proxy chaining and learn how ProxyChains routes traffic through multiple proxies for stealth, anonymity, and pentest pivoting.

Proxy Chaining and ProxyChains

You might have noticed that using a single proxy still leaves a single point of exposure (the proxy itself sees your info). To further increase anonymity or to navigate through multiple network hops, people use proxy chaining – connecting through multiple proxies in series. The idea of proxy chaining is that your traffic goes through one proxy after another (potentially in different locations or networks) before reaching the destination. For example, your data might go from your computer -> Proxy A -> Proxy B -> Proxy C -> target server. Each proxy only sees the IP of the previous hop, not your original IP, which makes tracing back to you more difficult. This layered approach is similar in spirit to how Tor routes traffic through multiple relays. In fact, using Tor with other proxies is an example of proxy chaining (often called Tor-over-VPN, VPN-over-Tor, etc., depending on order).

In practice, setting up a chain of proxies manually can be tedious. This is where the popular tool ProxyChains comes in. ProxyChains (specifically the updated proxychains-ng) is a program that forces any application’s TCP connections through a series of proxies by hooking network calls. You configure ProxyChains with a list of proxies (SOCKS4, SOCKS5, or HTTP) and a chaining mode (strict, dynamic, random, etc.), and then you prefix your application command with proxychains. The tool will ensure that the app’s traffic is redirected through the proxies in the chain you defined.

For example, many penetration testers configure ProxyChains to use Tor’s SOCKS5 proxy (127.0.0.1:9050) as the last link in the chain, possibly preceded by other proxies, to combine anonymity networks with their own hops. With ProxyChains, you could run: proxychains nmap -sT target.com and have your Nmap scan traffic go through, say, a SOCKS proxy on a compromised host and then out through the Tor network. This dramatically increases anonymity (though also increases latency) and can help bypass egress restrictions. As another example, if you set up an SSH dynamic SOCKS proxy to a jump box (as described earlier), you can add socks5 127.0.0.1 1080 (or whatever port) to ProxyChains’ config. Then running proxychains firefox would route your browser through the SSH tunnel into the network where the jump box resides, allowing you to browse internal sites.

Key points about ProxyChains:

· Instead of a single proxy, it connects many proxies in series (hence "chains"). You can chain proxies of different types. By default, it often includes Tor as one proxy (since Tor itself is a network of proxies, this becomes a multi-layer chain).

· This greatly increases anonymity because an adversary would have to trace through multiple providers/jurisdictions to find the origin. It also helps evade simple IP-based blocking, as your apparent source IP can rotate or be from an expected network.

· ProxyChains is commonly used in penetration testing to mask the source of attacks or scans. It can also help testers bypass outbound firewall rules by bouncing through intermediate hosts that have access. For example, if a target network only allows HTTP out, you might compromise a web server inside and use it as a SOCKS pivot; then ProxyChains can route your attack tools through that pivot.

· The tool supports TCP connections only, which is usually fine because most applications (except ICMP ping, some UDP services, etc.) use TCP. It can handle DNS queries by sending them through the SOCKS proxy as UDP (to avoid DNS leaks), which is important when using something like Tor (you don’t want to do DNS lookups outside the proxy chain).

· ProxyChains allows different chaining strategies:

· Strict chain (use proxies in a fixed order exactly as listed),

· Dynamic chain (skip dead proxies in the sequence),

· Random chain or Round-robin (to vary the order). This flexibility can balance between reliability and anonymity.

· It’s easy to use on Linux: many pentesting distros like Kali have proxychains-ng preinstalled. On Windows, ProxyChains isn’t natively available, but alternatives like Proxifier serve a similar purpose.

In summary, proxy chaining is a technique for enhancing anonymity or navigating complex network paths by using multiple proxies. ProxyChains (tool) is a convenient way to implement this for your applications without needing each app to support proxies individually. Cybersecurity professionals often rely on ProxyChains when they need to route tool traffic through multiple hops – for example, chaining a corporate HTTP proxy with an external SOCKS proxy, or chaining a compromised host’s SOCKS proxy with Tor for anonymized exploitation traffic.

Real-world note: A classic use of ProxyChains in pentesting is to put socks5 127.0.0.1 9050 (Tor) at the end of your chain in /etc/proxychains.conf, ensuring all tool traffic goes through Tor. With Tor running and ProxyChains configured, you can route, for instance, your SQLMap or Metasploit traffic through multiple Tor nodes — greatly obscuring attribution (at the cost of speed).

Next: Part 5 – Tools and Applications That Support SOCKS5 Proxies

Real-World SOCKS Proxy Use Cases for Cybersecurity and Network Administration

itsmegsg — Fri, 15 Aug 2025 05:42:17 +0000

Meta Description: Discover real-world SOCKS proxy use cases, from penetration testing pivots to bypassing firewalls, boosting privacy, and improving network speed.

Real-World Use Cases for SOCKS Proxies

SOCKS proxies have a variety of applications in the real world, especially in cybersecurity and network administration contexts. These scenarios highlight where SOCKS proxies outperform traditional proxies and why they’ve become a staple in penetration testing toolkits. Here are some common use cases and scenarios where SOCKS proxies are useful:

· Bypassing Firewalls and Network Restrictions: SOCKS proxies are often used to tunnel out of restricted networks. For example, in a corporate or school environment where certain sites or services are blocked, a SOCKS5 proxy can help route traffic to an outside server that isn’t blocked, effectively bypassing the firewall. Because SOCKS can carry any protocol, it’s ideal for circumventing more restrictive filters that go beyond just web filtering. (Of course, use this only where it’s permitted!) In some cases, administrators themselves set up SOCKS proxies on bastion hosts to allow controlled external access without opening raw network access.

· Anonymity and Privacy: Simply hiding your IP address can grant a degree of anonymity for everyday browsing or specific tasks. A SOCKS proxy will mask your IP so that the target service sees the proxy’s IP instead. People use SOCKS5 proxies (often in combination with tools like Tor) to anonymize their web traffic or scanner traffic during penetration testing. Unlike HTTP proxies, SOCKS proxies support a wider variety of traffic, allowing you to stay anonymous even for non-web activities. For instance, a penetration tester could run scanning tools through a SOCKS proxy so the scans appear to come from another location, helping avoid easy tracing.

· Penetration Testing & Pivoting: In cybersecurity assessments, after gaining access to one machine in a network, attackers/testers often set up a SOCKS proxy on the compromised host to pivot deeper into the network. The compromised host (or a jump server) acts as a pivot proxy, allowing the tester’s tools to connect through it to reach internal systems that were not directly accessible. Using a SOCKS proxy for pivoting lets the tester run tools like nmap, RDP clients, browsers, etc., as if they were inside the target network. This technique is invaluable for red teams and OSCP students: for example, compromise one machine, turn it into a SOCKS proxy, and route all further attacks through that to hit other internal hosts – all transparently via ProxyChains or similar. It’s much more flexible than trying to forward individual ports; a SOCKS proxy on a pivot can forward any port to any host in the internal network as needed. I have simulated this and explained it with screenshots in the LAB SECTION.

· Accessing Internal Resources (Jump Hosts): Even outside of malicious scenarios, SOCKS proxies are useful for administrators. Consider a secure network where direct access is blocked. An admin might SSH into a bastion host and use dynamic port forwarding (SSH -D option) to create a SOCKS5 proxy on their local machine that tunnels through the SSH connection. This allows the admin to use their local web browser (or API client, etc.) to access an internal web interface or service by simply pointing it to the local SOCKS proxy. In effect, you’re browsing from the perspective of the remote network, all while using your local tools. This is much simpler than setting up a full VPN in many cases and doesn’t require special privileges on the intermediate server beyond SSH.

· Web Scraping and Automation: SOCKS proxies are popular in web scraping because of their flexibility. A scraper might need to fetch not just standard HTTP pages, but also handle things like CAPTCHA solving services or FTP downloads. SOCKS5 proxies can be used to rotate through different IP addresses (for example, via proxy pools) to avoid IP-based blocking. Because they don’t alter data, they work seamlessly with HTTPS and other protocols that scrapers might encounter. Many web scraping providers offer SOCKS5 proxy endpoints for clients to use.

· Peer-to-Peer, Torrenting, and Streaming: A lot of P2P applications (like BitTorrent clients) support SOCKS5 proxies. The reasoning is that you can hide your IP from other peers or trackers by relaying traffic through a proxy, without losing functionality. SOCKS5 is well-suited here because it supports UDP (important for tracker communications and peer discovery in torrents) and doesn’t interfere with the data packets. Additionally, if using a proxy from a VPN provider (like some VPN services provide a SOCKS5 proxy endpoint), it can sometimes give better speeds than a full VPN for torrenting since only the torrent traffic goes through it and possibly with less encryption overhead. Note: While a SOCKS proxy can hide your IP on P2P networks, remember it doesn’t encrypt the traffic – your ISP could still detect torrenting activity, so some users combine this with a VPN or only torrent over HTTPS connections.

· Improving Network Performance or Latency: In some scenarios, a proxy might improve performance. For example, gamers have used SOCKS proxies to connect through servers that route traffic more optimally to game servers, potentially reducing latency. Also, by masking your traffic’s true origin, you might avoid certain ISP throttling (some ISPs throttle specific protocols or sites; routing through a proxy can make the traffic type less obvious). A SOCKS proxy, being lightweight, is a good choice here over a VPN if you only care about the performance aspect.

· Testing from Different Geographic Locations: If you want to test how a service behaves from another country (perhaps it’s geo-restricted or has different content), you can use a SOCKS proxy server located in that region. This is commonly done for QA of web services and apps. SOCKS proxies are handy because you can test not just web but any networked application from that perspective. For example, an API call from your software, DNS resolution, etc., can all be tested via a SOCKS proxy in another region. Some QA and monitoring tools integrate SOCKS proxies to simulate requests from various IPs.

As you can see, SOCKS proxies fill a lot of niches but important roles. They are like multi-purpose tunnels that can be employed wherever flexibility and routing of traffic is needed without application-level smarts. For cybersecurity professionals, they are everyday tools—whether it’s for hiding your identity during recon, pivoting in a network, or simply getting around an obstacle during an engagement.

Next: Part 4 – Proxy Chaining & ProxyChains

SOCKS4 vs SOCKS5: Key Differences, Security Features, and Comparisons with HTTP & VPN

itsmegsg — Fri, 15 Aug 2025 05:41:52 +0000

Meta Description: Compare SOCKS4 and SOCKS5 proxies, their key features, and how they stack up against HTTP proxies and VPNs in security and flexibility.

SOCKS4 vs SOCKS5: Proxy Versions

Over time, the SOCKS protocol has evolved. SOCKS4 and SOCKS5 are the two main versions, with SOCKS5 being the more advanced and widely used today. Both versions serve the same basic purpose, but there are important differences in features and capabilities:

· Protocol Support: SOCKS4 supports only TCP connections. SOCKS5 supports both TCP and UDP traffic. UDP support in SOCKS5 is crucial for applications like DNS queries, certain games, VoIP, and other UDP-based protocols which SOCKS4 cannot handle.

· DNS Resolution: SOCKS4 clients must resolve domain names themselves (sending the proxy an IP address), whereas SOCKS5 can perform DNS resolution on behalf of the client. This means with SOCKS5, you can send a domain name through the proxy and let the proxy resolve it. This is safer for privacy (preventing DNS leaks) and useful behind firewalls – the target domain name is not exposed to local network DNS servers.

· Authentication: SOCKS4 has very minimal authentication (it essentially trusts clients based on IP or not at all). SOCKS5 supports various authentication methods, including plain username/password and GSSAPI for secure authentication. This allows a SOCKS5 server to restrict access to authorized users.

· IPv6 support: SOCKS4 was designed for IPv4 only. SOCKS5 supports IPv6 in addition to IPv4, as well as domain name addresses.

· Proxy chaining: SOCKS5 introduced support for proxy chaining (the ability to route from one proxy to another) as well as better support for working through firewalls (because of UDP and remote DNS capabilities). In practice, proxy chaining is often implemented by client software (or by running one SOCKS proxy through another), but SOCKS5 was designed with this flexibility in mind.

· Security: By itself, SOCKS is not an encrypted protocol. However, SOCKS5 allows encryption at the authentication stage and can be used in conjunction with secure tunneling. For example, running a SOCKS5 proxy over SSH (which is encrypted) is a common way to get an encrypted SOCKS tunnel. SOCKS5’s support for authentication and its flexibility makes it more secure than SOCKS4 when properly deployed. (Note that statements about SOCKS5 “encryption” usually refer to these added layers or to specific implementations like SSH or SSL tunneling; the SOCKS5 protocol itself does not encrypt the payload of your traffic).

Bottom line: SOCKS5 is a significant upgrade over SOCKS4 and is the de-facto standard today (even though SOCKS5 has existed since 1996). It provides greater versatility and security features. One source sums it up well: SOCKS4 is basic and legacy (TCP only, no auth, no DNS relay), whereas SOCKS5 “improves on nearly every aspect of SOCKS4” – adding UDP support, authentication, remote DNS, IPv6, etc. Unless you’re dealing with a very old system that only knows SOCKS4, you’ll likely be using SOCKS5 for modern applications.

SOCKS Proxy vs HTTP Proxy (and Other Proxies)

It’s useful to compare SOCKS proxies with the more familiar HTTP proxies (and by extension, HTTPS proxies) since both are commonly used but in different scenarios.

· Layer & Protocol: An HTTP proxy operates at the application layer (Layer 7 of OSI) and understands HTTP(S) protocol. It can only handle web traffic (HTTP/HTTPS requests). In contrast, a SOCKS proxy operates at the session layer (Layer 5) and is agnostic to the traffic type. This means an HTTP proxy only works for web browsing (and other apps that specifically speak HTTP), whereas a SOCKS proxy can carry any protocol (web, FTP, SMTP, peer-to-peer, etc.) because it doesn’t need to know the details of that traffic. For example, you couldn’t use an HTTP-only proxy to forward a Skype call or a torrent stream, but you can do that with a SOCKS proxy.

· Data Handling: Because an HTTP proxy understands the HTTP protocol, it can read and even modify the content of web requests and responses. This allows for features like content filtering, caching, and scanning for malware in HTTP traffic. A company or school might use an HTTP proxy to block certain websites or cache frequently accessed pages. A SOCKS proxy, on the other hand, does not interpret the data it’s carrying. It will not modify your traffic or cache it. This makes SOCKS proxies simpler “pipe-like” proxies – great for flexibility and speed, but they don’t provide caching or content filtering on their own.

· Performance: Generally, SOCKS proxies have less overhead. Since they don’t inspect or manipulate traffic at the application level, they tend to be faster for raw data transfer and introduce minimal latency. HTTP proxies, while potentially adding value through caching or filtering, involve more processing per packet. For tasks like large downloads, streaming, or gaming, a SOCKS5 proxy might offer better throughput or lower latency than an HTTP proxy because it’s not bogging down inspecting the payload. One source notes that SOCKS proxies “operate at a lower level and do not need to understand or process the data,” making them faster for simple data transfer.

· Use Cases: If your goal is to filter or log web activity (say, in a corporate environment or parental control setting), an HTTP proxy is suitable because it can look into the content (e.g., URLs, headers) and enforce rules. If your goal is to tunnel various types of traffic or bypass restrictions without caring about content, SOCKS is often the better choice. For instance, a SOCKS proxy can tunnel non-HTTP traffic through firewalls by piggybacking on allowed ports. It’s common to use SOCKS when you need a generic solution that “just passes bytes” – for example, routing email or database connections through a proxy – tasks an HTTP proxy cannot do.

In summary, HTTP proxies are specialized for web traffic and can enforce web-related policies (but can’t handle other protocols), while SOCKS proxies are generalists that will proxy almost anything but don’t offer protocol-specific features. Many providers and tools support both. Often, cybersecurity pros use SOCKS5 proxies when they need to route arbitrary traffic (not just web) through intermediate hosts, especially in penetration testing or network troubleshooting scenarios where multiple protocols might be in play.

SOCKS Proxy vs VPN

Because both SOCKS proxies and VPNs can hide your IP address and help bypass network restrictions, it’s worth clarifying how they differ:

Encryption and Security: The biggest difference is that a VPN (Virtual Private Network) encrypts all your traffic between your device and the VPN server, whereas a SOCKS proxy does not encrypt traffic by itself. A VPN creates an encrypted tunnel at the network level (often using protocols like OpenVPN, WireGuard, IPsec, etc.), which means anyone intercepting your connection (e.g. your ISP) cannot see the contents or even the specific destinations of your traffic. In contrast, with a SOCKS proxy, the data packets are not encrypted by the SOCKS protocol – they’re only encapsulated and forwarded. Anyone monitoring your connection (like a firewall or ISP) can still observe which IPs you are communicating with and potentially read the data (if it’s not otherwise encrypted by the application). This is why, if you use a SOCKS proxy for privacy, you should ideally use it in combination with encryption (for example, using SSH tunnels or running the SOCKS proxy over TLS, or only using it with protocols that are encrypted like HTTPS). In fact, it’s common to pair SOCKS with other tools: for example, using an SSH dynamic port forward (which creates a local SOCKS5 proxy over an encrypted SSH connection) – this gives you the flexibility of SOCKS with the security of SSH encryption. Please read the LAB SECTION to see how I have used SOCKS with SSH dynamic port forward, the commands and execution are pretty simple.

Scope (System vs Application): A VPN typically captures all network traffic from your device and routes it through the VPN server (system-wide tunneling). A SOCKS proxy usually needs to be configured per-application (or system-wide via proxy settings or special software) – not all apps will automatically use a SOCKS proxy without configuration. This means a VPN is more of a broad brush (covering everything, which can include DNS, etc.), whereas a SOCKS proxy is more granular (you can point certain programs to it). For example, you might configure your web browser to use a SOCKS5 proxy and keep other traffic direct, whereas with a VPN, your entire device’s traffic is tunneled.

Features: VPNs often come with additional features like DNS leak protection, kill-switches, split tunneling, etc., and they often use authentication and encryption by design. A standalone SOCKS proxy service is usually more barebones – it’s just a proxy endpoint. Any extra features (like rotation, multiple hops, etc.) have to be managed by the user or a specialized client. SOCKS5 does support authentication, but it won’t, for instance, automatically reconnect if a connection drops (whereas many VPN clients have reconnection or kill-switch features to prevent leaks).

Performance: Because a SOCKS proxy does not encrypt or deeply inspect traffic, it can be a bit faster in terms of raw throughput and latency. A well-configured SOCKS5 proxy might offer better speeds than a VPN in bandwidth-intensive activities like large downloads, P2P sharing, or online gaming. VPN encryption adds some overhead (though modern VPNs are quite fast with minimal impact for most cases). If you’re very latency-sensitive (e.g. a gamer), using a SOCKS proxy could potentially result in slightly lower ping than using a VPN to a similar location, since the proxy isn’t encrypting/decrypting packets. In fact, some users prefer SOCKS proxies for activities like torrenting or gaming to maximize speed, accepting the trade-off of no encryption.

Use Case Distinctions: If privacy and security are your primary concerns (for example, evading a censoring regime or preventing any local surveillance), a VPN (or a SOCKS proxy over a VPN) is generally a more robust solution, since encryption shields your data from prying eyes. If speed or protocol flexibility is the goal (for example, accessing an internal network through a jump box, or speeding up certain connections) and you’re not as worried about encryption (or you have encryption at the application layer), a SOCKS proxy might be preferable. In practice, many power users use both: for instance, they might connect to a VPN, and inside that, use a SOCKS proxy to reach a specific network segment or service. However, for an average scenario, a reputable VPN service is a more all-in-one privacy solution, whereas SOCKS proxies shine in niche cases or as building blocks in a larger setup.

Next: Part 3 – Real-World Use Cases for SOCKS Proxies