The model proposes candidates; the extension mutates the seeded request and fires variants through Burp so logging, auth, proxy, and scope stay intact.

Why not just use Burp’s AI?

Because credit meters change how you test. Burp’s AI (and similar cloud features) are great, but:

• It’s Pro-only and credit-metered; credits deplete fast under real fuzz-iterate workflows.

• Continuous iteration on internal/staging traffic becomes a budgeting exercise.

• I wanted a local-first, human-in-the-loop flow where Burp remains the control plane and nothing leaves my box unless I say so.

So I built the thing I wanted.

What I built (and why it’s different)

Local LLM Assistant (Montoya API) — a Burp extension that adds a Local LLM tab and context menu action.

Key differences vs credit-metered AI:

• Works on Community Edition — no Pro lock-in.

• No credits, no cloud — run your own model with Ollama or any approved local runtime.

• MCP bridge — if you don’t have a local model, route via an MCP client (Claude Desktop / VS Code MCP) that can fetch seeds and send variants through Burp.

• Burp stays the network control plane — all traffic is visible in Burp’s Logger; auth, proxy, and scope rules still apply.

How it helps in practice

Seed from Burp
Right-click any request → Use this request as seed. The extension extracts params by location (URL / BODY / JSON / COOKIE) and cookies.

Two generation modes

• Command mode: pick vulnerability family (SQL/NoSQL/XSS/etc.), choose location and count → get candidate inputs instantly.

• Prompt mode: write a short instruction (“vary boolean/time-based checks”) → get a structured list.

Send through Burp
The extension mutates the seeded request and fires variants in parallel via Burp’s HTTP stack (optionally add each to Repeater).

Encoding variants
Turn on URL/Base64/HTML encoding to cover boring but useful permutations.

Timing & observability
See generation time, send time, and total wall-clock — makes it obvious whether the model or the network is the bottleneck.

Results I’m seeing

On representative staging runs: ~11–20s end-to-end (generate + send), down from ~3–4 minutes in my first prototype.
The wins came from parallel sends and a stricter structured output format. Fewer context switches; faster triage.

This doesn’t replace human judgment. It just removes keystrokes so I can spend time on auth edges, tenant boundaries, weird encodings, and evidence.

Where AI helps — and where it doesn’t

Helps

• Quickly proposing benign detection inputs

• Covering dull variants + alternate encodings

• Promoting “plausible” cases into Repeater for human digging

Doesn’t replace

• Understanding auth flows, tenant isolation, data paths

• Turning a quirky response into a verified finding with evidence

• Severity/exploitability judgment and remediation

Guardrails (by design)

• Human-in-the-loop: no autonomous crawling; I select the seed and click Send.

• Authorized targets only: defaults and docs emphasize staging/lab use.

• Local-first: local model or MCP via a local bridge with optional bearer tokens.

• Observability: everything flows through Burp’s Logger.

Architecture at a glance

• Burp extension (control plane): mutates the seed, fires via Burp’s HTTP stack (Logger/Repeater visible).

• Tiny HTTP bridge: /v1/seed, /v1/send endpoints the MCP client or local model can call.

• Model: local runtime (Ollama etc.) or MCP client.

• Crucial: the LLM never talks directly to the target; Burp owns network I/O.

Quick start

Repo: github.com/KaustubhRai/BurpSuite_LocalAI

1. Build the JAR or install the release JAR in Burp → Extensions → Add.

2. Pick your brain:

   • Local: run Ollama (or another approved local runtime) and set Base URL/Model in the extension tab, or

   • MCP: enable the MCP bridge and register the MCP server in your client (Claude Desktop / VS Code).

3. Right-click a request → Use as seed → choose Command or Prompt mode → Send.

4. Watch Logger (Sources → Extensions) for traffic, status, size, and timings.

Roadmap

• Auto-iterate: time-boxed rounds of plan → send → observe → rank by response deltas (status/latency/body/header), keep top-K, tweak strategy.

• Playbooks: repeatable sequences for common test families.

• Assertions library: non-destructive checks and diffing to speed triage.

All still human-started and scope-bound. The model proposes; Burp executes.

Most of my time went into security cert prep, especially BSCP. Nearly every security nerd has heard or used BurpSuite in their life. Its creator PortSwigger, offers BSCP. And for that certification, they have given a FREE and an extensive list of Theory + Labs to practice on - Web Security Academy.

For the same, i have jotted down some rough notes throughout. These were meant to be private. But since I haven’t written anything else, and this pile has real value, I’m dumping it here.

Notes

Use it, skim it, steal from it - whatever helps.

Enjoy

These "escapades" represent pivotal moments in cybersecurity history, serving as landmarks for how vulnerabilities have been discovered, exploited, and fixed. They have shaped how we practice cybersecurity today and will definitely influence future decisions and technologies we build to protect our data, devices, and 🌐 networks.

Below, I’ll try to pen down some of the legendary exploits, classic CTF machines, infamous security bugs, and even geopolitically driven incidents that have impacted cybersecurity on a global scale.

1. The Legendary Exploits:

Classics that are considered timeless by the cybersecurity community - each one is unique in how it reshaped our understanding of vulnerabilities, attacks, and defenses:

• EternalBlue (MS17-010): A notorious exploit developed by the NSA, that got leaked by the Shadow Brokers. It led to large-scale ransomware attacks like WannaCry and NotPetya. EternalBlue was a gift to any hacker worth their salt because it targeted a super common SMB vulnerability on Windows. If it was unpatched, you were toast.

  

• Heartbleed (CVE-2014-0160): A vulnerability in the OpenSSL library that allowed attackers to read sensitive information directly from the memory of affected systems. Like reading password of your bank account from a post-it note. The impact was immense, leading to countless servers being compromised due to leaked encryption keys and private data that taught us that even “secure” tools can have massive holes.

• Stuxnet: The James Bond of malware. A sophisticated worm that targeted industrial control systems (ICS) in Iran, believed to be a joint effort by the U.S. and Israel to sabotage nuclear facilities. Stuxnet was the first instance of a malware that specifically targeted programmable logic controllers (PLCs), showcasing the potential for real-world consequences of cyberwarfare.

• Shellshock (CVE-2014-6271): A vulnerability in the Unix Bash shell that allowed remote code execution - from web servers to your smart fridge. Shellshock impacted millions of servers, embedded systems, and IoT devices, as Bash was embedded deeply into many Unix-based environments. Why? Because someone thought it was a great idea to not sanitize inputs. Millions of devices could suddenly be commandeered remotely. Fun times 🙂.

  

• BlueKeep (CVE-2019-0708): A critical vulnerability in Remote Desktop Services on older Windows systems. BlueKeep could allow attackers to remotely execute code without any form of authentication. Like leaving your front door open with a giant “come on in” sign in neon color for hackers.

• Spectre and Meltdown: These hardware-level vulnerabilities targeted CPUs and exploited side-channel attacks to extract sensitive data from kernel memory. It showed us that even CPUs could be tricked into leaking sensitive data. These bugs were a wake-up call for the entire industry, forcing chip manufacturers and OS vendors to rethink their security models.

• Stagefright (Android Vulnerability): A bug affecting the Android media playback library, allowing RCE on vulnerable devices just by sending a malicious MMS. It was one of the biggest threats to Android devices globally back in the day.

• Dirty Cow (CVE-2016-5195): A privilege escalation vulnerability in the Linux kernel, affecting Android devices and many Linux distributions. It was all about exploiting how Linux handled copy-on-write (COW). For Android users, this bug also meant anyone could root your device without asking nicely.

Other Notable Mentions:

• SQL Slammer

• WannaCry

• Morris Worm

• Conficker ( also known as Downup, Downadup, and Kido)

• KRACK (Wi-Fi WPA2 Vulnerability)

• Log4Shell (Log4j Vulnerability)

2. The famous CTF Machines across different platforms:

CTF machines serve as practical learning playground for those wishing to practice security techniques in a controlled environment. Here are some of the most famous ones for different platforms:

• Hack The Box: Legacy - Classic Windows machine that teaches the fundamentals of network and OS exploitation. If you haven’t mastered SMB vulnerabilities, it’s time to get cracking. Legacy is where you understand why patching is not optional.

• VulnHub: Kioptrix Series - A great Linux-based series focusing on privilege escalation and web vulnerabilities, ideal for beginners looking to dive into old-school Linux, and the series really makes you sweat through those privilege-escalation hoops.

• Hack The Box: Jeeves - Famous for quirky challenges from enumeration to Windows exploitation, great for those new to Active Directory and similar setups.

• TryHackMe: Blue - Another CTF related to EternalBlue, designed for beginners to understand the steps involved in exploiting SMB vulnerabilities.

• VulnHub: Mr. Robot - wanna feel like Elliot? A CTF inspired by the popular TV series - Mr Robot, covering web vulnerabilities and privilege escalation techniques, along with a touch of cryptography.

• TJ Null's List - If you're aiming for certifications like OSCP, PWK, OSWE, or any offensive cert, you’ve probably heard of TJ Null's famous list of machines. This list gives you a roadmap of what to solvehack on different platforms to achieve those certs.

• Mobile-Specific CTFs:

  • Androgochi (Android CTF) - Focuses on Android app security, covering reverse engineering and common vulnerabilities in Android apps.

  • iOS Security Challenges - iOS-specific challenges from platforms like iCTF, which highlight vulnerabilities like insecure data storage and jailbreak techniques.

3. Famous Bugs in Security:

Security problems usually happen because someone, somewhere, took a shortcut. That later became famous because it caused big problems. Let’s talk about the bugs that have haunted developers and kept us security folks employed 🥳.

• Input Validation Failures: Wrote some code and thought, “Nah, why would anyone enter a SQL command in that text box”? Yeah, they will. Not validating input properly is like giving attackers a key to your database. SQLi and XSS are the gifts that keep on giving - all because some dev trusted user input a little too much.

• Authentication and Authorization Flaws: Using “12345” as password during testing and forgetting to change it later. Or just slapping together some session management without worrying too much about hijacking. The result? An attacker gets in because someone cut a corner. The "I'll fix it later" that never happens.

  

• Hardcoded Secrets: Hardcoding the API keys directly in your code - like no one's gonna look in there. Until your repo goes public, and some bot scrapes your AWS credentials faster than you can say “oopsies”. The kind of mistake that turns a dev’s life into a fire drill on a Friday evening.

• Insecure Deserialization: A magic trick that works perfectly until you realize your magician friend is a con artist. Deserialization bugs let attackers take untrusted serialized data and use it to execute whatever code they like.

• Improper Error Handling: A normal console.log(err) is always good for debugging, right? Except when it ends up in production, and suddenly every user (or hacker) sees your entire stack trace. Sometimes less is more - like just throwing a “Something went wrong” instead of displaying your dirty laundry.

• Misconfigured Security Headers: Like forgetting to lock the door on your way out. Security headers like CSP, HSTS, X-Frame-Options - if you don’t set these, you’re basically inviting attackers to have a field day with XSS and MITM attacks. Annoying to set up? Sure. Necessary? Absolutely.

• Race Conditions in Code: Imagine two people racing to grab the same resource, and whoever gets there first wins—except in code, the winner gets root privileges. Dirty Cow showed us what happens when you don’t properly handle concurrent processes. It’s messy and gives attackers the upper hand.

4. Geopolitical Incidents That Shaped Security:

Cybersecurity is not just nerds in hoodies - but also about countries flexing their muscles; thats heavily influenced by geopolitics. The following incidents show how vulnerabilities and exploits have played a role in shaping global security policies:

• Stuxnet: Allegedly the U.S. and Israel dropped this beauty into Iran’s nuclear facilities, and boom - centrifuges were spinning out of control. It wasn’t just a cyber attack; it was cyber warfare in action, and it changed the game forever; to cause physical damage to infrastructure.

• The Shadow Brokers Leak: A bunch of exploits straight from the NSA’s vault got leaked, including EternalBlue. This leak changed the landscape of cybersecurity, giving both researchers and malicious actors tools that were never supposed to see the light of day. And in the hands of anyone with a grudge.

• NotPetya Attack: Russia decided to mess with Ukraine, and NotPetya happened. It pretended to be ransomware, but the goal was just chaos. The collateral damage was insane - the attack led billions in losses for companies worldwide.

• China and the Great Firewall: We've all heard about China's firewall. The software we use here? They have their own versions. Their Google isn't our Google, their Amazon/Flipkart isn't our Amazon/Flipkart - everything is different there. This is thanks to the Great Firewall of China. It's not about blocking websites; it's a mix of censorship, surveillance, and cyber skills. Not just keeping content out but controlling everything inside the borders. Impressive, but scarrry 🎃.

• SolarWinds Hack: Late 2020, Russians allegedly slipped a backdoor into SolarWinds, and it ended up in U.S. government and corporate networks. The attack was a masterclass in supply chain exploitation - you’re only as secure as your weakest vendor.

• Operation Olympic Games: Pre-Stuxnet, this operation was reportedly launched by the U.S. to disrupt Iran's nuclear progress. It laid the groundwork for how cyber operations could be a key tool in modern geopolitical conflicts causing real-world disruption.

Conclusion: The Legacy of These Classics

Cybersecurity isn’t just about code and 🛠️ exploits - it’s about people, history, and the stories behind how we got here. The vulnerabilities, exploits, machines, and incidents covered represent key lessons in security.

Understanding them is not just about mastering technical skills but also about comprehending how intertwined security is with global events, technological evolution, and human creativity.

By learning these iconic elements of cybersecurity, one gains an appreciation for both the offensive and defensive measures that have been developed over the years.

And hey, the next time you're stuck 🐞 debugging an error or 🔧 patching a vulnerability, just remember - you’re contributing to the next chapter of cybersecurity history.

This understanding enables us to spot weaknesses and safeguard the system more effectively. One powerful technique to achieve this is taint analysis. In that spirit, let’s delve into the concepts of sources and sinks.

Understanding Taint Analysis

Taint analysis is a method used to track the flow of data through a program, start to end. It helps in identifying how data from an untrusted source can affect the execution of a program, potentially leading to security breaches.

The Role of Sources and Sinks

In taint analysis, the concepts of sources and sinks are fundamental:

• Sources: These are points in the program where untrusted data enters. Examples include user input fields, network interfaces, and external databases.

• Sinks: These are points where the data ends up or is executed. Sinks can include places where data is written to a file, displayed on the UI, or used in a database query.

Why Taint Analysis is Important

When we test systems or do code reviews, we don’t always have the luxury of a UI to observe how data flows. In such a scenario taint analysis is apt. It allows us to trace the path of user inputs through the system, highlighting how they interact with different components and where they ultimately end up.

This visibility is critical in identifying potential vulnerabilities, such as SQL injection points, cross-site scripting (XSS) vulnerabilities, and other forms of data mishandling.

Finding Sources and Sinks in Different Languages and Frameworks

The methods for identifying sources and sinks can vary depending on the programming language and framework being used. Here’s a guide on how to approach this in some common scenarios:

JavaScript and Web Development sources

JavaScript sources include various properties and methods that can accept user input:

• document.URL: Returns the URL of the document.

• document.documentURI: Returns the URI of the document.

• document.cookie: Accesses the cookies associated with the document.

• document.referrer: Returns the URI of the document that is linked to the current document.

• window.name: Returns the name of the window.

• history.pushState() and history.replaceState(): Allow manipulation of the browser history.

TypeScript and React sources

• State Variable

  • defined using the useState hook or other state management libraries.

  • e.g., const [inputValue, setInputValue] = useState('');

• Event Handler

  • functions that handle events like onChange, onClick, onSubmit, etc

  • e.g., const handleInputChange = (event) => { ... }

• Input Element

  • where the user types their input

  • e.g., <input type="text" value={inputValue} onChange={handleInputChange} />

• Form Elements

  • HTML elements like <input>, <textarea>, and <select>. These elements are often sources of user input.

• Props

  • It is a pattern to share information between a parent component and a child component. User input can be passed down as props from a parent component.

  • e.g., const MyComponent = ({ initialValue }) => { ... }

DOM-XSS sinks

These are some sinks that can lead to DOM-based XSS vulnerabilities:

• document.write() and document.writeln(): Write directly to the document.

• element.innerHTML and element.outerHTML: Allow manipulation of the HTML content of elements.

• element.insertAdjacentHTML(): Inserts HTML at specified positions relative to the element.

JavaScript Injection sinks

Potentially dangerous functions that can execute JavaScript code:

• eval(): Executes a string of JavaScript code.

• function(): Creates a new function from a string of code.

• setTimeout() and setInterval(): Execute code after a delay or at intervals if passed a string.

• element.onevent: Assigns event handler attributes.

Open-Redirection sinks

These properties can lead to open redirection vulnerabilities:

• location: Represents the location (URL) of the document.

• location.href: Gets/sets the entire URL.

• location.assign() and location.replace(): Navigate to a new URL.

• element.src: Sets the source of an element, such as an iframe or image.

Python and Django/Flask

Common Sources

• request.GET['input']: Retrieves query parameters.

• request.form['input']: Retrieves form data.

• request.cookies['cookie_name']: Retrieves cookies.

Sinks

• cursor.execute(query): Executes a database command.

• render_template('template.html'): Renders a template.

• subprocess.call('command'): Executes a shell command.

Java and Spring

Common Sources

• @RequestParam String input: Retrieves request parameters.

• request.getParameter("input"): Retrieves request parameters.

• request.getCookies(): Retrieves cookies.

Sinks

• jdbcTemplate.update(query): Executes a database update.

• response.getWriter().write(output): Writes to the HTTP response.

• Runtime.getRuntime().exec(command): Executes a system command.

C# and ASP.NET

Common Sources

• Request.QueryString["input"]: Retrieves query string parameters.

• Request.Form["input"]: Retrieves form data.

• Request.Cookies["cookie_name"]: Retrieves cookies.

Sinks

• sqlCommand.ExecuteNonQuery(): Executes a database command.

• Response.Write(output): Writes to the HTTP response.

• Process.Start(command): Starts a new process.

Steps to Implement Taint Analysis

1] Identify Sources: Begin by mapping out where user inputs enter your system. This could be through form fields, API endpoints, or other interfaces.

2] Trace the Flow: Follow the data as it moves through your system. Look for functions and methods that process or manipulate this data.

3] Identify Sinks: Determine where the data ends up, whether it’s being stored, displayed, or used in critical operations.

4] Analyze and Mitigate: Look for patterns where data might be mishandled. Ensure that all data reaching sinks is properly validated and sanitized to prevent vulnerabilities.

Tools to Aid

There are various tools available to help identify sources and sinks.

PortSwigger Labs

PortSwigger offers practical labs where one can practice identifying sources and sinks: PortSwigger Labs

Semgrep

Semgrep is a powerful tool for rule-based scanning. It allows you to create custom rules to identify sources and sinks in your code. Read more about how Semgrep can be used: Semgrep Documentation

Burp Canary

Burp Canary, an extension in BurpSuite that’s pre-installed in Burp’s browser. This enhances sources and sinks analysis by injecting unique tokens (“canaries”) into the requests and tracks their flow. This precise tracking highlights how user input (sources) moves through the system to critical endpoints (sinks), identifying potential vulnerabilities. This automation complements taint analysis. Read more at: Burp Canary

BurpSuite BCheck Scripts

For scenarios where a UI is available, you can develop a BCheck script in Burp Suite to automate the identification of sources and sinks while you casually browse the application. Here is an example script for JavaScript sinks:

BCheck Script

metadata: 
    language: v2-beta 
    name: "JS sinks for DOM-XSS (passive)" 
    description: "JavaScript sink that could lead to DOM-XSS." 
    author: "Kaustubh" 
    tags: "passive" 

given response then 
    if {latest.response} matches "document.write|document.writeln|document.domain|\.innerHTML|\.outerHTML|\.insertAdjacentHTML|\.onevent" then 
        report issue and continue: 
            severity: info 
            confidence: firm 
            detail: "JavaScript sink that could lead to DOM-XSS." 
            remediation: "Investigate if this sink can be used to do a DOM-XSS." 
    end if

Checkout more Bcheck scripts here

Conclusion

Understanding sources and sinks is crucial in identifying potential vulnerabilities in a system. By recognising where untrusted data enters (sources) and where it is executed or stored (sinks), can safeguard against attacks

I’ve been working on something cool and it’s finally ready for the spotlight. Meet, Rahasya,my latest creation designed to up your secret scanning game. This tool is all about making sure those sneaky secrets don’t end up where they shouldn’t.

Why Rahasya?

We all know the struggle — keeping API keys, passwords, and other sensitive info out of public repositories is a must, but it can be a pain to manage.

That’s where Rahasya comes in. It bundles some of the best open-source tools into one package, making comprehensive scans a breeze.

What’s Inside?

Rahasya combines the strengths of several top-tier tools like GitLeaks, Gitty Leaks, TruffleHog, Detect Secrets, Git Guardian, and Talisman. Whether you’re a developer or a security engineer, Rahasya is here to make your life easier and your code safer.

How to Use It?

Pull the Docker image and run it in your project’s root directory where it’s git cloned.

Dockerbash

# download the image
$ docker pull raikaustubh/rahasya # run the image at the project's location in a self deleting container once its done using
$ docker run -it --rm -v "$(PWD):/repo" raikaustubh/rahasya

You can customize the scans to fit your needs, whether you want to run all tools at once or pick and choose specific ones. The results are organized neatly, so reviewing them is a breeze.

Shift Left Security for Devs

Rahasya isn’t just for security pros; it’s great for developers too. You can deploy it as a GitHub Action, which means every time you push code or create a pull request, Rahasya will run the scans and alert you to any issues.

It’s a fantastic way to integrate security into your development process right from the start.

Want to Know More?

I’ve written an in-depth post about Rahasya on BreachForce. If you’re curious to dive deeper into what Rahasya can do, head over to

Take a gander here: BreachForce Blog.

Stay tuned for more updates and tools. I might not post often, but when I do, I make sure it’s worth your time. 🚀

An update! I’ve recently wrote a blog post about BChecks in Burp Suite, and I’m stoked to say it’s not just chilling in my drafts anymore. It’s out there, basking in the glory of not just on my company’s blog, but also on a popular cybersecurity community blog, BreachForce. 🎉 (And here I am, upgrading from my cozy personal blog corner to the big league!)

This piece is starting point on BChecks, I’ve explored the whole nine yards - what BChecks are, their role in turning security testing from a snooze fest into something slick by automating the yawn-inducing parts, and of course, the all-important ‘how-to’ of writing a BCheck complete with the syntax and a variety of examples to guide through each step. 📝

I’ve tried making the blog engaging and understandable as much as possible, so that it doesn’t look like any old technical manual.

Curious? You can jump over to Company’s Blog Page or BreachForce.

Also, I’ve been working on some BChecks of my own and have uploaded them to my GitHub repo.

Take a gander here: My GitHub BChecks Repo.

Stay tuned for more wisdom nuggets as I lazily upload only 2 posts annually.

Thats all for now! 🚀

When it comes to VAPT, it’s not just about the tools we use; it’s also about knowing the ins and outs of the language the application is built upon.

Every programming language has its unique quirks and features that can significantly impact your VAPT strategy. Whether it’s a Python web app or a Java-based system, each language brings its own set of potential vulnerabilities and loopholes.

I’ve compiled a list of key points to keep in mind while performing VAPT on applications written in different languages. I’ve tried to make it a handy reference that you can quickly glance at during your assessments. If you spot something familiar in the code, these notes could instantly point you towards potential vulnerabilities to investigate.

If you’ve got some insights or suggestions to add, don’t hesitate! I’ve enabled commenting on the Notion page, so drop your thoughts and let’s make this a collaborative effort.

Check out my notes right here: VAPT Notes

Happy hacking! 🌐💻

Big news in the world of API security! The OWASP API Top 10, that holy grail of API security risks, just got a fresh update. Not officially up on their site yet, but they’ve released a new list of risks that have earned their spot in the Top 10.

A lot of folks have created new resources tailored to the 2023 version of API security best practices. And APISEC University did too. They’ve updated their course to align with these latest insights: OWASP API Security Top 10 and Beyond!

Completed that course and compiled some notes.

Check out my notes right here: Link to OWASP API Top 10 and Beyond Notes.

Currently for Secrets Scanning to find sensitive information, i used to have different different tools. I used to juggle a bunch of secret scanning tools, running them one by one, waiting for each to finish before starting the next.

That’s where I was, trying to keep track of different syntaxes of differnt tools, output formats, and those pesky ansi escape codes when you try to pipe the output from terminal to a file. Trust me, it’s as fun as trying to solve a Rubik’s Cube in the dark. 😵

So, I thought, why not make life simpler? My first thought was a bash script to run all these tools sequentially. But then, the little voice in my head said, “you’re a comp sci engineer. trained for suffering in the name of engineering. automate it even more. make your life harder just for shitz and giggles.” 😞

And that’s how I stumbled upon the idea of dockerizing these tools. Because, why not challenge yourself when you are already building something like this for the first time.

Let’s look into the tools I’ve picked for this little adventure:

1. GitLeaks: It’s like the Sherlock Holmes of finding leaks in your Git repos.Check it out.

2. Gitty Leaks: Think of it as the Watson to Git Leaks’ Sherlock. Have a look.

3. Talisman: This one’s like the guardian angel for your code, keeping those secrets safe. Give it a gander.

Now, for the meat of the matter. I’ve got setup guides for each OS - Windows, Linux, and MacOS. You’ll find step-by-step instructions that even your grandma could follow (no offense to tech-savvy grandmas out there).

For the rebels who just want to skip to the good stuff (I see you 😤), jump right to the end for the Docker script¹.

And before running thess tools, whenever you download a repo to scan, ALWAYS git clone it, dont download it directly as a zip form the UI. Since its not initialized as a git repo, the tools dont work properly.

GitLeaks

Windows Setup: -

1. To run GitLeaks in Windows, the prequiste is only installing it through Go. So install GO, easiest way is with the .msi package.

2. After Installing GO, download the appropriate pacakge from releases. If not sure then run command, echo %PROCESSOR_ARCHITECTURE% or wmic computersystem get systemtype in cmd.

3. Unzip the package, and COPY the .exe file into the repo, that needs to be scanned.

4. Run

gitleaks.exe detect -v

Linux Setup: -

1. Same as windows setup, first check if Go is installed or not (go version). If not then install that and then git clone the git leaks repo.

2. cd into the gitleaks locally downloaded repo. and run make build

3. a file named gitleaks will be there now. copy that file into the repo and cd into the repo you want to scan and run

./gitleaks detect -v

MacOS Setup: -

1. Simplest way - brew install gitleaks

2. git clone the repo and cd into the repo

3. run

gitleaks detect -v

Gitty Leaks

Windows Setup: -

1. Installing Gitty Leaks in windows is a bitch and a half, what i have found is install it on a
   WSL, if you use windows.

2. For WSL installation, its same as Linux

Linux and MacOS Setup: -

1. pip3 install gittyleaks - prequistes that, python3 and git must be there

2. cd into the repo and run gittyleaks --find-anything

Talisman

Windows Setup: -

1. Download the proper talisman pacakge from Releases.

2. Copy that .exe into the repo that needs to be scanned.

3. Run talisman_windows_amd64.exe -s (mine was amd64 package)

Linux Setup: -

1. Check architecture of system, run arch

2. Download, that specific package from Releases for linux.

3. (Mine was x86_64) so downloading linux_amd_64 package

4. Run

wget https://github.com/thoughtworks/talisman/releases/download/v1.31.0/talisman_linux_amd64 chmod +x talisman_linux_amd64 sudo mv talisman_linux_amd64 /usr/local/bin/talisman cd <repo to scan>/ talisman --scan

MacOS Setup: -

1. To know the system architecture, run dpkg --print-architecture

2. After knowing, that specific architecture, find that package in Releases, and download that pacakage. Give it executable permissions and copy that file into the repo that needs to be scanned and run the talisman scan.

wget https://github.com/thoughtworks/talisman/releases/download/v1.31.0/talisman_darwin_arm64 chmod +x talisman_darwin_arm64 // Copy the talisman_darwin_arm64 into the repo ./talisman_darwin_arm64 --scan

If you want to run an indivual tool on its own, the setup for installation is above.

Moving on, now if you want to run it on a repo to scan the secrets OWASP’s got this neat repo called wrongsecrets - it’s like a playground for secret scanning.

Now, for my pièce de résistance - the Docker script to bind them all. Imagine it like a master spell that conjures all three tools in one go.

# Use a base image with Python, git, and other necessary tools
FROM python:3.10-slim-buster # Install necessary tools and dependencies
RUN apt-get update && \ apt-get install -y git wget make curl unzip procps && \ wget https://go.dev/dl/go1.21.2.linux-amd64.tar.gz && \ tar -xvf go1.21.2.linux-amd64.tar.gz && \ mv go /usr/local && \ rm go1.21.2.linux-amd64.tar.gz # Set environment variables
ENV PATH="$PATH:/usr/local/go/bin"
ENV GIT_DISCOVERY_ACROSS_FILESYSTEM=true # Install gittyleaks and Gitleaks
RUN pip install gittyleaks && \ wget -O /tmp/gitleaks.tar.gz https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz && \ tar -xzf /tmp/gitleaks.tar.gz -C /usr/local/bin gitleaks && \ chmod +x /usr/local/bin/gitleaks && \ rm /tmp/gitleaks.tar.gz # Install Talisman
RUN wget -O /usr/local/bin/talisman https://github.com/thoughtworks/talisman/releases/download/v1.31.0/talisman_linux_amd64 && \ chmod +x /usr/local/bin/talisman # Install Talisman HTML Report
RUN mkdir -p ~/.talisman && \ curl https://github.com/jaydeepc/talisman-html-report/archive/v1.3.zip  -o ~/.talisman/talisman_html_report.zip -J -L && \ cd ~/.talisman && \ unzip talisman_html_report.zip -d . && \ mv talisman-html-report-1.3 talisman_html_report && \ rm talisman_html_report.zip # Embed a Python script for cleaning the gittyleaks report
RUN echo 'import re\n\
import sys\n\
\n\
def remove_ansi_escape_codes(file_path):\n\ ansi_escape = re.compile(r"\x1B\[\d+(;\d+)*m")\n\ with open(file_path, "r") as file:\n\ content = file.read()\n\ cleaned_content = ansi_escape.sub("", content)\n\ with open(file_path, "w") as file:\n\ file.write(cleaned_content)\n\
\n\
if __name__ == "__main__":\n\ remove_ansi_escape_codes(sys.argv[1])' > /usr/local/bin/clean_gittyleaks_report.py && \ chmod +x /usr/local/bin/clean_gittyleaks_report.py # Update the entrypoint script
RUN echo '#!/bin/bash\n\
\n\
# Ensure we are in the mounted Git repository directory\n\
if [ ! -d "/repo/.git" ]; then\n\ echo "Error: Git repository not found in /repo"\n\ exit 1\n\
fi\n\
cd /repo\n\
\n\
mkdir -p /repo/Secret_Detection_Reports\n\
\n\
echo "\n\nStarting gittyleaks..."\n\
gittyleaks --find-anything | tee /repo/Secret_Detection_Reports/gittyleaks_report.txt\n\
python /usr/local/bin/clean_gittyleaks_report.py /repo/Secret_Detection_Reports/gittyleaks_report.txt\n\
\n\
echo "\n\nStarting gitleaks..."\n\
gitleaks detect --source=. --report-format=json --report-path=/repo/Secret_Detection_Reports/gitleaks_report.json\n\
\n\
echo "\n\nStarting Talisman..."\n\
talisman --scanWithHtml --reportDirectory=/repo/Secret_Detection_Reports\n\
\n\
# Check if the Talisman HTML report directory exists\n\
if [ -d "/repo/Secret_Detection_Reports/talisman_reports/data" ]; then\n\ # Start an HTTP server in the Talisman HTML report directory\n\ cd /repo/Secret_Detection_Reports/talisman_reports/data\n\ python -m http.server 8000 &\n\
else\n\ echo "Talisman HTML report directory not found"\n\
fi\n\
' > /usr/local/bin/entrypoint.sh && \
chmod +x /usr/local/bin/entrypoint.sh # Set the entrypoint to the embedded script
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

Before you run this, make sure Docker’s up and running.

- Open the docker desktop/docker daemon.

- Create a file named just Dockerfile and save the script

- Build the image from the script, with docker build -t secrets-checker .

- then head over to your repo and let it rip with

bash

docker run -it --rm -v "$(PWD):/repo" secrets-checker && cd talisman_html_report/ && python3 -m http.server 8000

- Voila! You’ll have reports waiting for you in Secret_Detection_Reports and talisman_html_report.

Pro tip: The Talisman needs a server to show its full glory, so that’s what the latter part of the command is. Just hit up localhost:8000 after the scan, and you’re golden. And, don’t forget to turn off the server once you’re done playing detective.

Footnotes

1. The beauty of this script - once the image is built, every time you run the command, it fires up in a container and poof - it’s gone once it’s done, leaving behind just the reports on your machine. No hassle of remembering to delete containers and saving stuff from container to local host ↩

You know how sometimes you dive into learning something new and end up with a shit ton of notes? Well, that’s what happened to me with APISEC University’s courses.

APISEC University, for those who might not know, offers free and hands-on courses dedicated to API Security 💪

I went all in, devouring their courses and jotting down notes like there’s no tomorrow. And guess what? I’ve decided to share these nuggets of wisdom with all of you! Why keep all the goodies to myself, right?

also this helps me to keep up with writing on these blogs

I’ve compiled all my notes in Notion – might not win any awards for being super organized but there’s something for everyone in there for you to get up to speed with API security.

Notion really does not transfer from one platform to others all that seamlessly, or I am just too chill (or lazy, but let’s stick with chill) to look it up for more than 5 mins. So simply sharing the link for the notes.

These notes are are primarily from the API Penetration Testing Course from APISEC University.

Check out my notes right here: Link to API Penetration Testing Notes.

This war-game Bandit, is targeted to the absolute beginners and teaches the basics of most of the Linux commands and security concepts. And also forms a base to be able to play other wargames by OverTheWire.

Each wargame by OverTheWire has different levels of difficulty and has multiple levels in each wargame. Bandit has 33 Levels to solve and it teaches about :

• SSH

• File Structure, Commands, Permissions in Linux

• Bash Scripting

• Git

  (I might have missed some of the other stuff in mentioning here)

The objective of each level is to find a password for the next level and there are some kind of hints or commands that could help you, on the page of that particular level on the OTW Bandit website.

We use SSH to login in each level be it SSH password or an SSH Key.

ssh bandit<username>@bandit.labs.overthewire.org -p 2220

and if ssh key then

ssh -i <ssh key file> bandit<username>@localhost

and then the password you got.

Levels 0-33

Level 0

SSH commands to connect to host

Level 1

Read the file present on the current directory and use that as a password for next level.

Level 2

Read a file named ”-” cat ./-

Level 3

Read the file using cat ./.hidden

Level 4

Above commands and putting file name of each file to check each one of them.

Level 5

ls -laR the command for viewing permission for each and every file, hidden too. within every directory.

Level 6

ls -laR | grep “bandit7 bandit6” for searching if there’s a file present like that, after finding the file name, using find -name <file name> command to find its path

Level 7

grep <keyword> the keyword in the file

Level 8

Command to Sort the file and read the unique character in one command

Level 9

Command to print only human readable characters and grep the keyword, cat <filename> | strings | grep <keyword>

Level 10

Decode the file, base64 -d <filename>

Level 11

decode the file, rot13 is the encryption. tr is the command that translates. tr 'A-Za-z' 'N-ZA-Mn-za-m'

Level 12

Copy the file in tmp directory and continue since no permission to create new files in main directory. file command to see what type of file it is and decompress it accordingly to what file type it is. Copy the existing file and create new file with the extension to decompress.

hex - xxd,
tar: tar -xvf, 
gzip - .gz, 
bzip2 - .bz2, 
POSIX tar - .tar

Level 13

ssh -i <ssh key> username@localhost, localhost since we are working in the same machine.

Level 14

from the previous level hint, we can read the the password from “etc/bandit_pass/bandit14” from this logged in user.

Store that password in tmp directory nano /tmp/passwd.txt and netact it to localhost from port 30000, nc localhost 30000 < /tmp/passwd.txt

Level 15

same technique, but now we have to SSL encrypt our connection unlike netcat raw connection. so we use openssl tool. openssl s_client -connect localhost:30001 and provide the password of this level at the end.

Level 16

Same as previous level but we are given a range of ports to check which one is up and has SSL. nmap localhost -A -p 31000-32000. After getting the port, provide the password through openssl same way as previous level.

make a file in tmp directory and save the ssh key there and change its permission to only read for user. chmod 400 <file path>. ssh to bandit17 level using the key.

Level 17

difference between 2 files, diff file1 file2.

Level 18

.bashrc file is modified to logout instantly when logged in using ssh. There’s a hint that password is stored in readme in /home and we can pass another command in the same ssh command when logging in.

ssh <username>@<host> -p 2220 ‘cat readme’

Level 19

scanning the home directory for files and permission (ls -la) gives a binary setuid file that has permissions to run as bandit20 and is turned on. passwords are stored in /etc/bandit_pass directory. so we run the file as a command and simply read the password for its level.

./bandit20-do cat /etc/bandit_pass/bandit20

Level 20

Same as level 19, a setuid binary file but it requires a port number as input. From the hint given we setup a netcat listener in the shell and open another shell and log in as same user and pass the port we gave in the netcat listerner as the input in the setuid file. as per the hint we give the password for level 20 in the netcat shell and if correct then it gives the password for the next level.

Level 21

Level has a cron job running so we read the file and after examining it we get it runs a script file after every reboot and every minute. After reading the script file, it changes the permissions and redirects the output to /tmp directory . After reading that file from /tmp we get the password.

Level 22

Same as Level 21, we read the cron file then the script file. The script file has 2 variables. The first variable is the username and the second variable is a md5 value. After running the script the password level 22 get stored in /tmp directory. We run the second variable separately by passing the username of the next level and we get a new md5 value. we pass that md5 value in the /tmp directory and read it and we get the next password.

echo I am user bandit23 | md5sum | cut -d ' ' -f 1 > (md5 value) cat /tmp/(md5 value)

Level 23

Read the cron file and the script file. Create a directory in /tmp and in that directory make a script file. It should read the password for the next level and pass it to the created directory in /tmp in a new file

#!/bin/bash cat /etc/bandit_pass/bandit24 >> /tmp/<new directory>/level24

Level 24

A daemon is listening on port 30002 and it asks for the password of the current level and a 4 digit PIN. We create a directory in /tmp and create a script file that uses for loop for numbers 0000-9999 to check which is the right one.

#!/bin/bash passwd="YOUR_ACTUAL_PASSWORD_HERE" # Loop from 0000 to 9999
for i in {0000..9999}
do # Echo the base password and the current number into the output.txt file echo $passwd$i >> output.txt
done

give the script file 777 permissions and run it with nc

cat output.txt | nc localhost 30002

Level 25

ssh key on home directory but exits as soon as logged in with bandit26. After checking the /etc/passwd file it redirects to /usr/bin/showtext. After reading that file, ~more command is triggered and it exits when the text case is large. So minimized the shell and try with the ssh key. Can use vim here and show the password for level26 using these commands

:e /etc/bandit_pass/bandit26

Level 26

Will log out once if found the text case is large so minimize the terminal and log in with the password. Go to vim by pressing v and :set shell = /bin/bash and then next :shell in vim to enter a normal shell. There’s a setuid binary file with special permissions for bandit27. After running the file it runs as shell with bandit27 with an input in the command so

./bandit27-do cat /etc/bandit_pass/bandit27

Level 27

Hint tells us that we need to git clone and the password is in the repo. Make a directory in /tmp and give it 777 permissions and git clone the link the hint has.

Level 28

Same procedure as the previous level, mkdir>permissions>git clone>cat README.

The password text is hidden. So we review the git log by, git log to see the commit message and to see what was changed either git show <commit number> / git log -p.

Credentials in plain text were removed but it still got stored in the commit log.

Level 29

Same procedure, level 27. After reading the README it gives a hint that no passwords on production, means there are other branches and we can view all branches in a repo by git branch -a. The dev branch might have non production code and might have the password, so git checkout dev and cat README.

Level 30

Same procedure, file>permissions>git clone>cat README. Gits Logs has nothing too, Git saves some things from its history by giving them a tag if it deems it important. git tag

git show <tag name>

Level 31

Same procedure. This time the README gives hint that we need to create and push a file and the file’s content. Simple Git commands here.

Level 32

Every command get converted into uppercase here. We need to use escape character to bypass this uppercase shell. Like /bin/bash is used to invoke shell, $0 can also be used.

Level 33

DOES NOT EXISTS YET TIME OF WRITING

Embarking on a journey from academic life to the professional realm, I crafted a quick-reference arsenal of security related concepts to sharpen my skills for interviews. Now, it’s time to unlock these riches for your own exploration:

• OSI Model, DNS insights, and more.

• Skills in Web App and Subdomain Enumeration.

• A deep dive into Content Discovery.

• Decoding ‘How Internet Works’.

These pages are more than just notes; they’re milestones from my personal tech odyssey. Ready for a deep dive?

Check out the resources here: Link to Notion Notes

The folklore goes as follows…

All exercises in Advent of Cyber follow a fun Christmas story. This year, the elf McSkidy needs your help to hack back and undo the grinch’s malicious activities. Elf McSkidy had been promoted to CISO and has managed to build a world-class security team. Elf McSkidy founds that all the analysts and security personnel have been missing. She founds that all have booked a one way flight ticket away to a vaccation.

Before she had time to make any assumptions, a loud, grumpy voice was resonating across the security center from the internal announcement systems “Grinch Enterprises will never let Christmas succeed. It would be a shame if your world-class security team just suddenly disappeared”

Their intelligence team had prepared for this exact scenario but it didn’t help that the security center was completely empty! McSkidy sighed and dragged herself to the office to save Christmas.

I tried to catalog my notes for each day while solving those tasks.

🌓 DAY 1 - IDOR

🏛 DAY 2 - HTTP

🧩 DAY 3 - Content Discovery

🏦 DAY 4 - Authentication Bypass

🌧 DAY 5 - XSS

💄 DAY 6 - LFI

❤ DAY 7 - NoSQL

📃 DAY 8 - Investigating Logs

🕓 DAY 9 - WireShark

🚎 DAY 10 - NMAP

❤ DAY 11 - SQL

🕓 DAY 12 - NFS, SSH

🌡 DAY 13 - Privilege Escalation

⛵ DAY 14 - CI/CD

📭 DAY 15

📂 DAY 16 - OSINT

🎆 DAY 17 - Amazon S3 Buckets

🧩 DAY 18 - Docker

🏏 DAY 19 - Email Phishing

🌉 DAY 20 - Malware Analysis

🕯 DAY 21 - YARA

📨 DAY 22 - Digital Forensics

🏒 DAY 23 - PowerShell Logs

⛅ DAY 24 - Windows Password Hacking

🌧 DAY 25

PS: If anyone’s interested in seeing the certificate, here’s the LINK.

The link for THM’s Advent of Cyber 3 room.

The Top 10 here means Top 10 Vulnerablities, the greatest software risks for any Web Application. OWASP is just an online community/non profit foundation that helps to improve the security of software for free.

To combat said vulnerablities and protect your website, TryHackMe provides a room to pratice these vulnerabilities and teach you about each vulnerability. How it occurs and how to exploit it. Link for the room - THM OWASP Top 10 Room

I practiced this room a while back and wrote posts on Linkedin on how to solve each challenge. This is a culmination for all those posts in one place.

This is a mind map for all the things that are taught in that room.

(Mindmap much bigger than this. Click THIS)

Day 1 - Injection

Day 2 - Broken Authentication

Day 3 - Data Exposure

Day 4 - XML External Entity

Day 5 - Broken Access Control

Day 6 - Security Misconfiguration

Day 7 - Cross-Site Scripting

Day 8 - Insecure Deserialization

Day 9 - Components with Known Vulnerabilities

Day 10 - Insufficeint Logging and Monitoring

OWASP Top 10, this is just one of the concepts that one needs to learn in protecting thier application. There are many other vulnerabilites present and all of this can be learned through THM.

But their general idea of what hacking is often coming from seeing it done in a movie, television, or a video game. The problem is, they often show it wrongly. Hacking isn’t typing faster than the other person or solving a puzzle by rotating objects. It takes much longer than that and requires a lot of patience (Reading this article is also gonna require you a lot of patience 😛).

CTF players are often newbies and a CTF is meant for them as an introduction to the world of cybersecurity.

So what is a CTF?

A CTF stands for Capture The Flag¹. It’s like a puzzle to solve but instead of a puzzle we are given an IP address, an image, some code or a software or literally anything and you have to work your way around using Google as your best friend and your skills in Bash Scripting and Linux. It’s like when a little bird is pushed out of the nest and it has to learn to fly by itself, you are expected to use your skills and find the flag and then using what you have learned you have to apply them to defend your companies against hackers or in Layman’s terms you can call it a hacking competition.

CTF is somewhat held in high regard if you run in the cyber-security community. It tests your skills to outthink, outsmart, and most importantly outhack any situation given to you.

You have to apply real-world hacking tools to infiltrate a computer system, find intentionally placed vulnerabilities, and exploit them to capture a flag. You then submit this flag so that you get points.

Each challenge is usually oriented around a single concept. By solving challenges, you (hopefully!) learn about a new concept, vulnerability, tool, class of attack, etc. A CTF can be performed individually or in a team(it’s hard finding security nerds).

CTF Styles

There are three common types of CTFs: Jeopardy, Attack-Defence, and mixed.

Most CTFs are “jeopardy style”, meaning that there are a handful of categories, and each of the (typically standalone) challenges falls into one of those categories.

The categories vary from CTF to CTF, but typically include:

• RE (Reverse Engineering): get a binary and reverse engineer it to find a flag.

• PWN: get a binary and a link to a program running on a remote server. Cause a buffer overflow, etc. to bypass normal functionality and get the program to read the flag to you.

• Crypto: crypto means cryptography! Get an encrypted flag and figure out how to decrypt it (includes both classical and modern ciphers).

• Web: web-based challenges where you are directed to a website, and you have to find and exploit a vulnerability (SQL injection, XSS, etc.) to get a flag.

• Forensics/Steganography: given a file, image, audio, or other files, find a hidden message and get the flag.

• Other: this is a bit of a grab bag. Includes random puzzles, electronics-based things, OSINT², anything that doesn’t fit into the other categories.

The next task in the chain can be opened only after someone or a team solve the previous task.

Attack-defence is another interesting kind of CTF, can not be done by a single individual it needs a team. Here every team has its’s own network(or only one host) with vulnerable services. Your team has time for patching their own services and protecting it while also attacking other servers. You should protect your own services for defense points and hack opponents for attack points.

Possible formats in Mixed competitions may vary. It may be something like wargame with special time for task-based elements.

Logistics and How to Find CTFs

Wait! Now before you go any further

It’s definitely more fun to play with friends or even internet strangers. Playing with other people means that you can help each other, support each other when you make progress, get a new tool working, or find a flag… or when you don’t. Especially when you’re new, CTFs can feel like repeatedly banging your head against the wall (there’s so much to learn in this field!). Having others to play alongside can definitely help lift that emotional burden when things aren’t going well, and give you people to celebrate with when you make a breakthrough.

There are online groups that are open to beginners. A shortlist includes :

• OpenToAll

• Women Hackers

• CTF Circle

• Meetup

If there’s anybody interested in teaming up you can try Slack/Discord for local security meet-up groups. The same goes for university groups if you’re a student, as there are often other people looking for teammates. Use them to meet other hackers/coders who can mentor you.

Where to find CTFs?

There are in-person CTFs throughout the year, plus many at conferences. There are also online CTFs which run for 1-3 days, some go for a week. CTF Time provides you with a list of upcoming events. Some CTFs and CTF platforms are available online, year-round.

• OverTheWire “Bandit” is a good option if you want to learn Linux commands through a beginner-friendly game. It has a number of other great ‘wargames’ as well like Natas, Narnia, Maze. Each wargame has some levels, you pass one level to continue to the next.

• HTB, the most popular platform which includes both “Jeopardy” style challenges and network pentesting VMs³ for you to attack. You have to hack this site just to make an account on this platform (hint: find the login portal). After you do that, try solving the retired machines to gain confidence and then move on to the active ones.

You can try solving above machines from the 2 columns first as they are the easy ones. These boxes are all retired. While hacking these machines, keep in mind that you have to first connect to them using OpenVPN (I did not know this and it gave me a lot of headaches). Remember to visit the Starting Point page to understand everything on the platform.

• VulnHub’tis the same as HTB, it also has vulnerable machines for you to practice on. There are many blogs on how to start and how to solve such machines. I would suggest reading at least blogs for 5 machines and then try to understand the approach for starting on these machines.

This Google Sheet has VulnHub and HTB boxes, it is kept updated by the fellow InfoSec people.

• picoCTF is technically an event in the fall, but the challenges remain open year-round. This is probably my top recommendation for a beginner Jeopardy-style CTF.

Other multi-category platforms (paid and free) include Root Me, Escalate, Pen Tester Lab, 24/7 CTF, Hacker101, and CTFLearn. There are many more… if you’re a beginner, leverage these to get access to many different types of challenges in each category to determine what you like, and build up a knowledge base (Hacker101 has a few Android challenges).

Now before even trying to attend a CTF or hack a machine, you must have a basic knowledge in programming or know your way around a Linux machine. Learning Linux could be hard for some people, Learn Linux is a guided room designed to teach you all the basic fundamentals of Linux that you need to get started.

• Linux Fundamentals

• Learn Nmap

• Learn Metasploit

• Hack this Windows Machine

• Learn Web Security basics

• Solve some picoCTF web challenges

Do this and you are ahead of the curve (I have wasted a lot of time focusing on redundant things and getting stuck in these basic steps).

And now the Resource List for each category!

RE

In industry, RE skills are used for vulnerability research. You might be given a software program and asked to find vulnerabilities (without having source code). Similarly, malware research involves a lot of reverse engineering. It’s a bit more niche than its inclusion in CTFs would lead you to believe, but still a challenging/fun category.

It is daunting to get started in reverse engineering, if you have little or no experience in low-level programming languages like assembly. As you get started, try to find something in the code to orient yourself… a call to a standard library function (read, scanf, printf, etc.), comments, strings, etc.

This article covers most of the resources that you are going to need for RE, but here’s my shortlist.

• Learning by doing: Microcorruption is a game where you try to reverse engineer (fictitious) Bluetooth locks of increasing difficulty. It’s all in-browser (which means no-tool setup) and has a tutorial level that introduces you to some of the assembly and environment.

• Learning by reading: Hacking: The Art of Exploitation and then Practical Binary Analysis. Hacking: The Art of Exploitation takes you from a very basic level through C, assembly, program memory, exploits, and much more.

• Learning by watching: Live Overflow has a great series on binary exploitation.

PWN

You’ll be given a program to RE, a server and a port to connect to. The server is running that same program and has a file that contains the flag (usually called flag.txt). These challenges are a way to learn about secure coding (typically in C), as some sort of vulnerability will let you redirect the program flow to do something else (give you a flag). This category is probably what people think of when they think of (stereotypical) hacking.

The learning curve is a bit steep as these challenges are more multi-disciplinary.

• Learning by doing: Pwnable.kr, pwnable.xyz and pwnable.tw are all geared towards beginners.

• Learning by reading: Same as RE.

• Learning by watching: Same as RE.

Crptography

Encrypting (and decrypting) data in order to allow for its secure transmission and storage. Most challenges revolve around either decrypting a ciphertext using a classical cipher (Caesar, Vignere, etc.) or finding a flaw in the implementation of a modern cipher.

While jobs in cryptography are pretty niche (NSA?), knowing how cryptography works can be very beneficial to those developing software, or playing defense, as exploiting human error (in implementation) is far more likely than exploiting a flaw in a proven cryptographic system. That’s why you should “never roll your own crypto.” : )

• Learning by doing: If you have the patience to learn to program while also learning cryptography, visit CryptoPals. It’s a step-by-step set of exercises that “demonstrate attacks on real-world crypto.” Think Project Euler, but for cryptography.

• Learning by reading: The Code Book, it’s a cat-and-mouse type story about cryptography through the ages, it’s not super technical but really fun. For a more technical introduction, check out Crypto 101, a free PDF book. Then, if you still want more, check out No Starch Press Serious Cryptography.

• Learning by watching: Christof Paar’s Introduction to Cryptography videos, there’s also a Coursera Cryptography Series offered by Standford.

Web

This covers any sort of web-based vulnerabilities and exploits. This includes different forms of injection, cross-site scripting (XSS), cross-site request forgery (CSRF), insecure direct object references (IDOR), and so on.

In terms of the InfoSec industry, web hacking could get you a job in AppSec (application security) or web-based pen-testing. It might also be useful to those who want to do bug bounty, as several bounty programs focus on web targets. If you’re a web developer, developing web hacking skills could help you create a more secure codebase at your job.

• Learning by doing: OWASP has a number of intentionally vulnerable projects. One of them is JuiceShop, an intentionally vulnerable website that teaches you about many common web vulnerabilities. You can download the image from their website, and run it locally (or deploy it somewhere like Heroku).

• Learning by reading: Web Application Hacker’s Handbook

• Learning by watching: This introductory course on web hacking which covers (in varying extents) HTML/CSS/JS, the HTTP protocol, cross-site scripting and cross-site request forgery. Once you get past those, this has more advanced browser exploitation.

Forensics / Stego

Steganography (not to be confused with stenography) is the art of concealing a message (or file, image, etc.) within another message (or file, image, etc.). In CTFs, this category often contains other digital forensics challenges, and might be called either “Stego” or “Forensics”.

In the industry, stego and forensics skills can have a wide range of applications including digital forensics, incident response, data loss protection, and malware detection.

This image has a flag in it.

P.S - I wasn’t able to solve this problem in an in-person CTF. If anyone of you is able to, share how you did it 😝.

• Learning by doing: A multi-category site like PicoCTF and Hack The Box and try some stego challenges.

• Learning by reading: Trail of Bits has a fantastic CTF guide that will cover some basic stego concepts.

• Learning by watching: Welp I’m lacking ideas here. : ( Send me a link if you know of a good beginner stego/forensics series online!

TL;DR and thoughts

1. CTFs are competitions that teach you hacking skills through different types of challenges.

2. Jeopardy-style CTFs are the most common and typically cover five major categories: RE, Pwn, Crypto, Web, and Stego.

3. If you don’t know what category/categories interest you, try a bit of everything and then deep dive into your favorite areas.

4. Try to read past CTF’s writeups or watch videos of how it’s solved.

5. CTFs are more fun when you do them with friends!

Don’t bediscouraged if (when) you get stuck. Everyone starts somewhere, and even if you don’t solve a challenge, you can still learn something valuable and gain enough knowledge so that the next challenge is a bit easier. Infosec is a huge field that draws upon many different skills, and there’s a lot to learn. I’m just a undergrad student and I’ve got a long road ahead. And as always, Google ftw.

Happy CTFing!

Footnotes

1. flag - a string of code that proves you discovered the flaw. ↩

2. OSINT - the art of googling to find something useful about something or somebody ↩

3. VM - a virtual environment that functions as a virtual computer, VMs allow multiple different operating systems to run simultaneously on a single computer ↩

Unlike other hackathons this was a security hackathon where we had to create stuff that would be needed in the world of cybersecurity.

My first time ever attending a hackathon and that too a security hackathon the pressure, anxiety, nervousness, the excitement was REAL. My team comprised of 3 other members, 2 of whom I had never met. We met at the venue and talked about how we would tackle the problem statement. There were topics given by the people who were organizing this event. We chose our own, our problem statement was Automated Vulnerability Assessment Using a Remote Pi device. Those are some big words in the title, let me explain it to you word by word.

What is Vulnerability Assessment

Every organization is a target for hackers. The best thing a company can do is conduct an audit¹. Audits are a way to detect security vulnerabilities in the system or the network of the organization with various techniques, the same techniques as that of a real-life black hat hacker aka bad guys. It focuses on identifying vulnerabilities² in the network, server, and system infrastructure.

Adding Automated in front of it now means we are just doing it automatically by the push of a button or here in this case by the help of Pi device, Pi is just a dumbed-down version of a computer with Linux as its OS in it and it’s the size of a credit card, you plug it in devices and it works. All of this means that we were making something that was going to help companies do the security stuff faster and it’s cheap and the size of a credit card. FANTASTIC! right?

Presentation

We had to present it now in front of the judges what we were building as 3 hours had been already up. One of the judges in the panel was Venkata Satish, who has been awarded CISO³ of the year in India, so in my mind as my first impression, I had to present it as well as I could .

Break

After 5 hours or so, we had a break from our work station and in that time period, I got to interact with the remaining teams in the hackathon (I mean, you are basically stuck with everyone in the same area for the entirety of the event). There were 15 teams or so, and all of their projects were really innovative and it was inspiring to see how they were tackling their problem statements effectively. Even though everyone was busy perfecting their prototype and bringing their ideas to life throughout the event, we still managed to mingle around and meet new friends along the way.

Here’s a glimpse of what problems were given to us:

Projects made by people on Blockchain and OSINT were the most eye-catchy ones as not a lot of people use these technologies or get their hands dirty as for most of them it looks overkill.

After the break time, a couple of hours had passed our project’s hardware side had been finished, we were working on the front end side to make it more User Friendly for people to use and understand. Before the final round, professionals and experts in the fields related to hackathons and cybersecurity came as advisors. They inspected our work and asked us questions related to the same. Each of them asked us questions how it would help different scales of companies, on how a person not having a computer background can operate these devices, etc. They explained to us and cleared some of our doubts on how companies think and why they would need our product and how we need to sell it to a company and mostly to which type of companies. It was a really informative session with all of them. Not only were they able to see gaps within our idea, but they were also able to add on to what we already had.

Finals

After working for 12 hours on this project, we needed to show it to the judges, whether complete or not, we still had kinks we needed to sort in our project, it still wasn’t entirely User-Friendly. We showed the judges what we had been working on and we explained to them how they can start the Pi device remotely and conduct the VAPT audit.

After a while, all the teams were called for the announcement of winners, they gave us insight on how a team needs to perform in a hackathon such as this, what preparations should be made before and how we need to manage and gauge our time properly, how we need to present it more professionally in front of the panelists, what we can do with the product we’d made in the future and how we can work on it to make it more efficient. After this they called out the names of the teams to present them with what they had won– our team name was also called. We had secured the 1st place in the hackathon, 2 of my team members were offered Internships on the spot, and then we got a cash prize of 15K. We all agreed that the real prize was the pride and happiness we got out of winning the competition and defeating other teams.

Footnotes

1. audit - an official inspection ↩

2. Vulnerability - the possibility of being attacked ↩

3. CISO - Head honcho of Cyber Security, mostly reports to the CEO. ↩