How to become a bug-bounty hunter and do penetration testing.          Please send any comments to me.

This page updated: January 2019

Becoming a Bug-Bounty Hunter
Big Tools / Frameworks
Tools / Methodology
Attacks And Vulnerabilities

Becoming a Bug-Bounty Hunter

Ceos3c's "The different Phases of a Penetration Test"
PTES's "Penetration Testing Execution Standard"
OccupyTheWeb's "Become a Hacker"
Sebastian Vargas's "Different Angles of Cybersecurity"
djadmin / awesome-bug-bounty / Getting Started (huge; don't get lost in here)

The usual model is "pay for results": hacker gets paid if they find a problem. Bugcrowd also is rolling out "pay for effort": person gets paid like a contractor/consultant for running tests with a defined coverage and skill level.

Is "pay for results" a fair deal ? Can a bounty-hunter make a living ?
Depends on the competence and intentions of the bounty-hunter (and the following is written from a US perspective): Some grim reading:
Trail of Bits' "On Bounties and Boffins"
Jon Martindale's "Meet the bug bounty hunters making cash by finding flaws before bad guys"
Shaun Waterman's "The bug bounty market has some flaws of its own"
Sean (zseano)'s "Are you submitting bugs for free when others are being paid? Welcome to BugBounties!"

Some good news for bug bounty-hunters:

You can't learn or know everything, so you'll have to focus on some areas and mostly ignore others, for now.

OccupyTheWeb's "The Essential Skills to Becoming a Master Hacker"

About pentesting as a career-path, from /u/unvivid on reddit 12/2018:

Learn IT Operations/Engineering. Pen testing is about using operations/dev tools in creative ways, about abusing trust relationships. Most people I know that are good/great have background in IT ops and know how to manuever in those environments. They understand the challenges that operations has and don't beat on them. I'm not saying that people fresh out of school can't become great pentesters, they definitely can -- I know several. But shore up your lack of operational knowledge by building/testing/developing/engineering/Architecting. Don't focus solely on security. Deep dive IT Operations, know how to troubleshoot, know how to sysadmin and engineer networks. Know why things are built wrong/right -- understand what social/political/financial pressures drive companies. Build social skills, learn to communicate and think objectively. That's what gets people into cool jobs. ...


... Learn the Windows side, in passing at least. At the highest levels nearly everyone I know is OS agnostic. Yes we all love to sh*t talk MS, but nearly every environment I pentest is 90% Windows. Cloud has changed that somewhat and the winds are shifting. But knowledge of both stacks is good to have. I started my career as a Windows Sysadmin and I'd say that experience was a huge part of what got me into my first security gig. Tons of people love to sh*t on Windows, but it pays the bills and the days of the admin that couldn't script or just clicked through things is coming to an end.

What are your strengths ?

Understand the legalities and rules of engagement:

To me, the "money" and "security and correctness are important" items generally spell "corporate or govt apps" these days. There aren't going to be big bounties for finding some text-formatting bug in MS Office, or a play-flaw in some game, or bugs in open-source software such as Linux or Node packages. (Except see Julia Reda's "In January, the EU starts running Bug Bounties on Free and Open Source Software".)

The trick probably is to find a target small enough that it hasn't been picked over by a lot of hunters, but big enough to have a bounty program.

Fisher's "[HackerOne] - Prioritizing and choosing a program to focus on"

"Want an easy way to find new bug bounties? Search for the term 'bug bounty' on Indeed or LinkedIn Jobs. You will see public AND private bounty programs."
from tweet by Paul Seekamp.

From /u/cym13 on reddit:

The advice with bug bounties is always the same: look for things nobody else thought of in places nobody else thought of.

It is good practice for websites setting up a bug bounty program to first perform a security assessment of the platform, or at the very least launch automatic detection tools.

Furthermore you're in competition with thousands of other researchers, so finding the obvious is not something you should strive for: if it's obvious, someone else will have found it before you. Maybe you'll be the lucky one but that's a game where there's not always a winner and always thousands of losers.

This means your efforts are best spent:

Success stories including some strategy:
Maycon Vitali's "Talk is cheap. Show me the money!"

Figure out resources for the given target:
Ceos3c's "The different Phases of a Penetration Test"
Luke Rixson's "Hacking how-to's: Developing your process"
Barrow's "How to Organize Your Tools by Pentest Stages"
Occupy4eles's "Use Magic Tree to Organize Your Projects"
OccupyTheWeb's "The Hacker Methodology"

More about this later.

How to report effectively:
More about this later.

After reporting:

Your bug will have to be:
  1. triaged,
  2. validated,
  3. evaluated,
  4. fixed,
  5. fix tested,
  6. fix deployed,
  7. then maybe publicized.
Payment may come at any stage. Third parties and Legal may be involved. Be patient. Don't disclose to anyone else without written approval.

What to expect from bug-bounty hunting:
kongwenbin's "A Review of my Bug Hunting Journey"
Marcin Szydlowski's "Inter-application vulnerabilities and HTTP header issues. My summary of 2018 in Bug Bounty programs."
Trail of Bits' "On Bounties and Boffins"
Erin Winick's "Life as a bug bounty hunter: a struggle every day, just to get paid"

More about competition:
I see several Facebook groups full of guys in India, Pakistan, Bangladesh who are running tools and pushing buttons and trying to figure out what they're doing. Probably there are a lot more on Twitter and other places, and from China and Nigeria and Philippines etc. They have access to the same internet and same tools that you do. If all you learn how to do is run scans and catch very simple bugs, you will be competing with those guys.

Companies are moving to application frameworks instead of lots of custom code. Those frameworks probably do the basics (authentication, input sanitizing, URL-checking, permissions, database access, etc) fairly safely. If all you learn is how to catch simple bugs, you will be pursuing a dwindling pool of bugs.


I'm going to mostly ignore some target areas:

What I'll focus on:

[From this point, everything assumes Web app / database as the focus.]

My personal situation:


There are so many sites and tools that you can go crazy trying to know about all of them. Find some that work well for you and get started, don't worry about the rest.

Learn from:

reddit's /r/HowToHack
reddit's /r/bugbounty

Some people say: learn from the bottom up, learn the details of protocols and languages and do exploits manually, or else you're just a script-kiddie pushing buttons on tools you don't understand. I say: there's nothing wrong with knowing only some basics and using existing tools. Then iterate up and down, figure out what's really happening when you execute some script, learn more about the language the web app is using, learn more about features of the tool you're using. Push forward your learning on all levels, bit by bit.


Programs listed in Thuvarakan Nakarajah's "Bug Bounty Guide"
Programs listed in EdOverflow / bugbounty-cheatsheet /

Smaller programs may have less competition.


Ceos3c's "What are Payloads in Hacking Lingo?"

If you run into unfamiliar tech, maybe get an intro at:
tutorialspoint's "Tutorials Library"


amanhardikar's "Penetration Testing Practice Lab - Vulnerable Apps / Systems" (ignore big image, see lists of sites; huge, don't get lost in here)
EdOverflow / bugbounty-cheatsheet /

OWASP Vulnerable Web Applications Directory Project (click on tabs across the top of page)
bitvijays's "CTF Series : Vulnerable Machines" (lots of techniques)

Big Tools / Frameworks

I'd like to use free tools. Many of the best tools have huge price-tags. The following tools are free unless indicated otherwise.

[From this point, everything assumes Linux as your test-driver machine.]

The main choices for web app testing (I think):

Big tools/frameworks that straddle many phases and target types:

Be careful about just running "try everything" in some big tool, or some script that calls lots of tools. You may hammer your target with lots of port-scanning and attack traffic and brute-forcing, causing alerts to go off at target and your ISP, maybe cause DOS at target, get yourself in trouble.

Distros and tool bundles:

My opinion at the moment:
"Number of things installed" does not equal "power". Better to install each tool yourself, so you know something about how it works and what it's doing. And you're probably not going to test all the areas covered by the Kali tools; maybe you'll test web apps, so the tools for Wi-Fi cracking and password brute-forcing and malware reverse-engineering and smartphone-exploitation and such are just distractions.



Recording your work:

See the Recording Desktop Activity section of my Linux page.

KeepNote ?

Managing the project:

I want something that will:
A lot to ask. Haven't found it yet.

Ceos3c's "The different Phases of a Penetration Test"
Luke Rixson's "Hacking how-to's: Developing your process"
Barrow's "How to Organize Your Tools by Pentest Stages"
Occupy4eles's "Use Magic Tree to Organize Your Projects"
OccupyTheWeb's "The Hacker Methodology"

Your own OPSEC:

You may create new vulnerabilities in the target. You may create a tunnel that violates all of their security policies. You may see trade secret or proprietary or PII data. Your report is confidential, unless and until the client approves release of it. How are you going to protect those things from someone else coming in and trying to exploit/grab them ?

Assume someone smarter than you is trying to get into the same target that you are, and may be targeting YOU, trying to piggyback on you. Is some new plug-in or exploit that you grab from somewhere really safe, does what it says it does, can you trust it ? Are your tools updating themselves over unencrypted connections ?

Have you changed default passwords on Kali, the big tools, etc ? Are you using 2FA on your important online accounts ? Are you storing data in encrypted containers, that are open only when you're using them ?

DEF CON 23 - Wesley McGrew - I Hunt Penetration Testers: More Weaknesses in Tools and Procedures (video)

Tools / Methodology

Barrow's "How to Organize Your Tools by Pentest Stages"
WAHH's "Tools"
Bugcrowd's "Researcher Resources - Tools"

These are loosely organized into the phases where you'd use them. But many tools straddle several phases. And the exact names and definitions of the phases differ from source to source.

The organization I've chosen:

  1. Learn the application: log in as user, do normal things, understand the application.

  2. Domain/server Discovery: OSINT and DNS work to get lists of domains and servers.

  3. Port scanning those domains/servers: scanning to verify domains and servers and ports exist.

  4. Verifying domains/servers/services: scanning to get banner pages etc to show what services are running.

  5. [Analysis]

  6. Site/server Analysis: get software versions and patch levels etc.

  7. Content Discovery: find files on servers.

  8. [Attack]

  9. Probe pages/scripts with bad parameters: attack bad input-handling.

  10. Attack application code and logic: more complicated attacks (XSS, SQLi, etc).

  11. [Cleanup and Reporting]

  12. Remove anything you've installed or modified.

  13. Report what was done and results.

  14. Post-Reporting.

Apparently, some tools are forbidden in some bounty-hunting programs, because they generate so much network traffic or tie up the servers.

Use a VPN (unless you're doing custom traffic inside a LAN). Some clients may have automatic software that bans IP addresses that produce suspicious traffic, even if you're authorized to do testing. And it may add your IP to a blacklist that many companies use, not just the target. [This begs the question: are you going to get your VPN company blacklisted ?]

Don't just push the "scan" button on some huge framework and hope the right thing happens. Set the scope and configuration for the scanning, know what it's going to be doing.

From "Penetration Testing" by Georgia Weidman:
"Be forewarned: Not all public exploit code does what it claims to do. Some exploit code may destroy the target system or even attack your system instead of the target. You should always be vigilant when running anything you find online and read through the code carefully before trusting it."

"Scanning for vulns" is not the same as "penetration testing". Scanners make mistakes or give false positives. Follow up each hit with manual testing, and make sure you know what is happening, and try to broaden the scope of the problem. Don't just report scanner results and expect a bounty. Clients often have contracted with expensive pentesting companies that produce huge lists of scanner-hits, but then the client finds only 3 of them are worth fixing.


  1. Learn the application:

    • RTFM.

    • Log in to the app, do normal things, understand the application.

    • Maybe diagram the flow and reach of the application. What are the roles, the data, the operations/transactions, the states of the application ? Make a matrix of roles and permissions ?

    • What is the most valuable information in the application ?
      How important is availability/uptime of the application ?
      Are some parts critical to regulations such as PCI, HIPAA, GDPR ?
      Where is there money, where is there PII ?

    • Try different roles in the application, different transactions, maybe create multiple users, try deep features that may be less-tested, try unusual features such as password reset, change username, delete account, cancel order. Try desktop and mobile, different human languages, different browsers.

    • What are the default or standard accounts and passwords ? Are there demo or example accounts ? Suppose the installer blindly followed the examples in the manual, what accounts and passwords and server names would be created ?

    • Does the application require that users modify their computers, installing a certificate or app or applet or browser extension ? What behavior do those things have ?

    • Can you install the application locally, on your own machine(s) ? This will make it much easier and safer to learn it, brute-force it, create privileged users, dig into internals and source code, examine log files, etc. Where are the log files ? Is there a master config file ? Is there a debug mode ? Where and how are credentials stored ? How does it update or get patched ? How is it backed up and restored ? How are patches applied ? Are there cron jobs or daemons ? Can you extract version numbers of internal modules, packages or libraries ? Does the app depend on any other services ? Can you install those locally too ?

    This is a lot of work. Maybe if you're very good, or very specialized, or feeling reckless, or just looking for a quick score, you can skip much of this learning, and just plunge into the app and see what the pages look like.

    But learning the app may give you a big edge over other hunters, and you may be able to test features they can't get to. If the same app is used by other targets, maybe learning it well is worthwhile. What company wrote this app ? Maybe look at other apps they've written.

    You could always alternate both styles: take a quick shot at the app, read the manual a bit, take another shot, learn more about the app, do some more poking, etc.

  2. Domain/server Discovery:

  3. Port scanning those domains/servers:

  4. Verifying domains/servers/services:
    Scanning to get banner pages etc to show what services are running.

  5. [Analysis]

  6. Site/server Analysis:
    Get software versions and patch levels etc.

    Also see Web Apps section.

  7. Content Discovery:
    Find files on servers.

  8. [Attack]

  9. Probe pages/scripts with bad parameters:
    Attack bad input-handling.

    Generally, by now (or in earlier phases), you're using a special "intercepting proxy" between you (browser or app) and the network. The proxy supports recording the outgoing requests and the incoming results, and then analyzing them, repeating them, altering them.

  10. Attack application code and logic:
    More complicated attacks (XSS, SQLi, etc).

    See Specific Attacks And Vulnerabilities section.

    OWASP's Xenotix: XSS tester.

    Try to find the biggest scope for the bug. Multiple browsers, multiple OS's, desktop and mobile, multiple versions, multiple countries, multiple users, etc.

    Tools for specific targets:

  11. [Cleanup And Reporting]

  12. Cleanup of the target system(s):
    Keep good notes, so you can clean up at the end of the testing, or tell the target what was modified.

    If there's something you can't clean up, notify the client/target so they can clean it up.

  13. Reporting:
    • Target may have a standard form for reporting bugs.
    • Document clearly, with exact URLs and with pictures and video.
    • Explain exactly how to reproduce, with exact URLs etc, for developer audience.
    • Explain the severity and effects, for both developer and non-technical audiences.
    • Emphasize any financial or regulatory or legal impacts.
    • Maybe suggest fixes.
    • Don't editorialize or be harsh; let the facts speak for themselves.
    ZephrFish / BugBountyTemplates
    Nicholas Handy's "Bug Reporting for Bug Bounties"
    tolo7010's "Writing a good and detailed vulnerability report"
    Bugcrowd University - How to Make a Good Bug Submission (video)
    Pentester Land's "List of bug bounty writeups" (very uneven, more articles than reports, but ...)

  14. Post-Reporting:
    It's possible the target may want to make a fix and then have you re-test.

    Do you have a lot of the target's data saved on your systems ? That is a legal liability to you; you are responsible for protecting it, perhaps to standards dictated by GDPR or some other regulations. Probably best to delete all of it.

    At some point, after ALL is done, you may even want to delete your report, or at least redact it to remove the target's sensitive data from it. What could happen if someone steals it from your system ? What could happen if the data is published (not because of a breach of your system), and there is an investigation of everyone (including you) who possessed that information ?

SecTools.Org (a bit stale)
Pentesting Tutorials' "Pentesting Methodology Tutorial"
EdOverflow / bugbounty-cheatsheet /

TunnelsUp's "Hash Analyzer"

Attacks And Vulnerabilities

It's confusing that tools and attacks and exploits often don't make the required context clear. Does a tool / attack / exploit operate:

Some apps, tools, attacks, or exploits may require that you have specific resources:

Common Terms/Techniques:

[Not sure about the rest of this; still working on it !!!]

Attack Targets/Patterns:
It's confusing, because: For example, SQLi:

WAHH's "Task Checklist"
Marcin Szydlowski's "Inter-application vulnerabilities and HTTP header issues. My summary of 2018 in Bug Bounty programs."
bitvijays's "CTF Series : Vulnerable Machines" (lots of techniques)

Detectify's "OWASP Top 10 Vulnerabilities Explained"

You can look at OWASP Top 10 for most common types of vulnerabilities. But look back into the previous years of this list, for some items that have been pushed off the list but still are worth testing.

Sakurity Network's "Why OWASP Top 10 is no longer relevant"

Unsafe Input Handling

Code Injection:
An umbrella term that includes SQLi, command injection, more ?
Wikipedia's "Code injection"

Submit a script into a Comment field, it gets stored in the database ("stored cross-site scripting"), and later other users can view your "comment".

Script Injection:
Give Web/App server a request with scripting in parameters or form fields, and get it to return a page containing that scripting.

This is "reflected scripting", and not really valuable in that it's running with your creds and in your browser. But it reveals that the pages or Web/App Server are handling input unsafely.
Attacker --req with script in params or fields--> Web/App Server
Attacker <--page with script active-- Web/App Server

SQL Injection (SQLi):
Give Web/App server a request with SQL or SQL fragments in parameters or form fields, and see if it sends your SQL to the database.
Attacker --req with malicious SQL--> Web/App Server --malicious SQL--> Database Server
Attacker <--page with secret data-- Web/App Server <--secret data-- Database Server

The SQL sent to the database could:
Series of 5 articles starting with DRD_'s "Database & SQL Basics Every Hacker Needs to Know"
DRD_'s "Attack Web Applications with Burp Suite & SQL Injection"
Allen Freeman's "The Essential Newbie's Guide to SQL Injections and Manipulating Data in a MySQL Database"
DRD_'s "Use SQL Injection to Run OS Commands & Get a Shell"
Wikipedia's "SQL injection"
EdOverflow / bugbounty-cheatsheet /
Polyglot injection strings.
Maybe most likely on pages that are sorting data or showing tables of data.
pentestmonkey's "SQL Injection" cheat sheets
Reiner's "SQLi filter evasion cheat sheet (MySQL)"
SLEEP(1) /*‘ or SLEEP(1) or ‘“ or SLEEP(1) or “*/
For username and password fields:
1′ or ‘1’=’1

Server-Side Template Injection (SSTI):
For sites using a template engine such as Flask, Jinja2, Mako, Jade, Ruby, Slim, Velocity, Smarty. Usual telltale is construct like "{{title}}" in the URL or HTML.

Give Web/App Server a request with template code in parameters or form fields, and see if the Template Engine executes the code.
Attacker --req with malicious template code in param--> Web/App Server + Template Engine
Attacker   <--page with template code executed-- Web/App Server + Template Engine

This is "reflected templating", and it's running with your creds. But it reveals that the pages or Web/App Server or Template Engine are handling input unsafely.

Maybe this can be used to get the Template Engine to run code you give it. Depending on how and where the Template Engine is running, this could give access to files or commands on the Web/App Server or Template Engine Server, or enable requests to other servers. If you can modify files on the servers, maybe you can modify pages that are served to other users.

From James Kettle's "Server-Side Template Injection":
"The 'Server-Side' qualifier is used to distinguish this from vulnerabilities in client-side templating libraries such as those provided by jQuery and KnockoutJS."

Sven Morgenroth's "Server-Side Template Injection Introduction & Example"
EdOverflow / bugbounty-cheatsheet / Template Injection

CSHPP (Client-side HTTP Parameter Pollution):
Web/App Server expects an HTTP request with parameters, forms request to Back-End Server. But you give it a request with extra or duplicate or malformed parameters, so the request to Back-End Server is malicious.
Attacker --req with malicious params--> Web/App Server --malicious req--> Back-End Server

SSHPP (Server-side HTTP Parameter Pollution):
Back-End Server expects an HTTP request from Web/App Server. But you give it a malicious request directly from your browser with extra or duplicate or malformed parameters, and Back-End Server executes the request.
Attacker --req with malicious params--> Back-End Server

Unsafe API Input Handling

XXE (XML External Entities):
Server expects an XML object that contains data, but send it an object that will cause execution of code.
Also send XSLT that generates HTML.
Attacker --XML with malicious content--> API Server

klose's "XXE Attacks - Part 1: XML Basics"
EdOverflow / bugbounty-cheatsheet / XXE
EdOverflow / bugbounty-cheatsheet / XSLT Injection

Insecure Deserialization:
Find where an app accepts a serialized object over RPC or out of database or something, and give it a modified or malicious object. The object could have a forged data state, or cause code execution.
Attacker --serialized object with malicious content--> API Server

Linus Sarud's "OWASP TOP 10: Insecure Deserialization"

Insecure API:
Many mobile and web-app APIs (RESTful APIs, SOAP) involve sending a data or command object (encoded as XML, JSON, HTML, etc) over an HTTP connection.
Attacker --object with malicious content--> API Server

Viacheslav Dontsov's "API testing: useful tools, Postman tutorial and hints"
Mike Yockey's "API Testing with Postman"
Rushyendra Reddy Induri's "Getting Started with Postman for API Security Testing: Part 1"
James Messinger's "API testing tips from a Postman professional"
Get Postman for Linux
REST test test ...


Directory Traversal:
If you can get access to the filesystem of a server, either via modification of a page, or via unexpected URLs or URL parameters, you can try many different filenames to see if they exist and can be read. And you can add "../" to the filenames to go up and down in the directory tree.
Attacker --req for file X--> Web/App Server
Attacker <--contents of file X-- Web/App Server

DRD_'s "Perform Directory Traversal & Extract Sensitive Information"
DRD_'s "How to Find Directories in Websites Using DirBuster"
Look in robots.txt for stuff that's not supposed to be exposed.

Request Forgery (RF):
Give a user a malicious page or frame from the application, while they're logged into the Web/App Server. Then the malicious code can do application operations using their credentials/authentication.
Attacker --req with malicious script--> Web/App Server --SQL to store malicious script--> Database Server
User --request--> Web/App Server --SQL--> Database Server
User <--page with malicious script-- Web/App Server <--data containing malicious script-- Database Server
User --request by attacker's script--> Web/App Server
This is attacking the other users, not the underlying application, really. Your script will be executing with their credentials. Of course, if one of them is an admin user, then your script can do more.

Modified from "Penetration Testing" by Georgia Weidman:
"RF exploits a website's trust in the user's browser".

Cross-Site Request Forgery (CSRF):
User is logged into the Web/App Server. Get them to open a page from Attacker's Server, and that page does application operations using their credentials/authentication.
User --request--> Attacker's Server
User <--page with malicious script-- Attacker's Server
User --request by attacker's script--> Web/App Server
This is attacking the other users, not the underlying application, really. Your script will be executing with their credentials. Of course, if one of them is an admin user, then your script can do more.

From "Penetration Testing" by Georgia Weidman:
"CSRF exploits a website's trust in the user's browser".

Sjoerd Langkemper's "Cross site request forgery (CSRF)"
DRD_'s "Manipulate User Credentials with a CSRF Attack"
Trust Foundry's "Cross-Site Request Forgery Cheat Sheet"
debasishm89 / burpy runs on Burp log file, it reports places where CSRF bypass (avoid defenses) might be viable.
Common critical functions to try CSRF: add/upload file, email change, delete file, password change, tranfer money, profile edit.

Server-Side Request Forgery (SSRF):
Usually shown as something like "redirect.php?url="
Browser requests to Web/App Server, which normally turns around and requests to Back-End Server. Try to modify parameters so Web/App Server requests to some other server, not the Back-End Server.
Attacker --req with malicious params--> Web/App Server --malicious req--> File Server

Detectify's "What is server side request forgery (SSRF)?"
EdOverflow / bugbounty-cheatsheet /
Wallarm / SSRF bible
SaN ThosH's "SSRF - Server Side Request Forgery (Types and ways to exploit it) Part-1"

Command Injection:
When there is some way for pages to cause the Web/App Server to run OS commands on its OS, there may be a fault that allows unexpected commands to be run.
Attacker --req to run "cat /etc/passwd"--> Web/App Server
Attacker <--contents of /etc/passwd-- Web/App Server

DRD_'s "Use Command Injection to Pop a Reverse Shell on a Web Server"
EdOverflow / bugbounty-cheatsheet / RCE

Privilege Escalation:
If you can get access to the OS level of a server, either via Command Injection from a page, or via Shell Access, maybe you can escalate access from normal user to more powerful user.

TokyoNeon's "How to Perform Privilege Escalation, Part 1 (File Permissions Abuse)"
TokyoNeon's "How to Perform Privilege Escalation, Part 2 (Password Phishing)"
DRD_'s "Perform Local Privilege Escalation Using a Linux Kernel Exploit"
Barrow's "Use a Misconfigured SUID Bit to Escalate Privileges & Get Root"
OccupyTheWeb's "Finding Potential SUID/SGID Vulnerabilities on Linux & Unix Systems"
Bill Tsapalos's "Hack Metasploitable 2 Including Privilege Escalation"


Cross-Site Scripting (XSS):
A very confusing mega-term that has grown over the years, and often in ways that don't match the name at all. Many forms of it are not "cross-site", and many forms don't involve scripting. And it mixes two steps: input and exploitation.

Some forms of XSS: So each of these involves a first step to get bad data in (bad parameters, SQLi, Script Injection, Template Injection, etc) and then a second step to do exploitation (Request Forgery or redirection or other).

A key factor is that the link or page-URL the user sees is that of the (trusted) Web/App Server. The link may come to the user in a cross-site manner (via email or by seeing it on Attacker's Server somehow), or from a page or message in the application, but user trusts it because it points to the real application.

From "Penetration Testing" by Georgia Weidman:
"Cross-site scripting exploits the trust a user has in a website".

Wikipedia's "Cross-site scripting"
DRD_'s "Discover XSS Security Flaws by Fuzzing with Burp Suite, Wfuzz & XSStrike"
DRD_'s "Advanced Techniques to Bypass & Defeat XSS Filters, Part 1"
DRD_'s "Advanced Techniques to Bypass & Defeat XSS Filters, Part 2"
EvilToddler's "Find XSS Vulnerable Sites with the Big List of Naughty Strings"
Joe Smith's "Cross Site Scripting (XSS) Basics"
Alex Long's "Use JavaScript Injections to Locally Manipulate the Websites You Visit"
Alex Long's "How Cross-Site Scripting (XSS) Attacks Sneak into Unprotected Websites (Plus: How to Block Them)"
CrackerHacker's "Exploiting XSS with BEEF (Part 1)"
Bugcrowd University - Cross Site Scripting (XSS) (video) (stale)
XSS.Cx (a Crawler and Injection Reporting Tool)
reddit's /r/xss might have some bugs posted but the bounty not claimed
EdOverflow / bugbounty-cheatsheet /
Brute's "XSS 101"
Brute's "The 7 Main XSS Cases Everyone Should Know"
Brute's "File Upload XSS"
Sites that often are vulnerable: sites that allow users to edit themes, or add CSS, or set event/meeting name, or show your Facebook page in a frame, or specify filename for uploading, or set a custom Error page.
"Multi-context polyglot payload": String that tries to work in many different contexts, so you don't spend a lot of times trying many approaches.
OWASP's "XSS Filter Evasion Cheat Sheet"
“ onclick=alert(1)//<button ‘ onclick=alert(1)//> */ alert(1)//
Fake URL params:
0xSobky / HackVault
Jackmasa's XSS Mindmap

File Includes:
This really should be called "File Execution". Some languages let the server-side scripting do an "include" of a file's contents into the executable of the script. Trick the code into using your file, or rewrite the contents of the file it already uses.

There are several different ways to accomplish this: If you can change the filename used, you can change it to name of a:
Wikipedia's "File inclusion vulnerability"
EdOverflow / bugbounty-cheatsheet / LFI
Jean Fleury's "Finally, My First Bug Bounty Write Up (LFI)"
George Mauer's "The Absurdly Underestimated Dangers of CSV Injection"

Insecure CORS (Cross Origin Resource Sharing):
wikipedia's "Cross-origin resource sharing"
James Kettle's "Exploiting CORS misconfigurations for Bitcoins and bounties"
Geekboy's "Exploiting Misconfigured CORS (Cross Origin Resource Sharing)"
Muhammad Khizer Javed's "Exploiting Insecure Cross Origin Resource Sharing (CORS)"

Ceos3c's "How to hack a WordPress Website"
Sebastian Vargas's "Hardening WordPress Like a Boss"
See WordPress tools section.

OccupyTheWeb's "Linux Basics for the Aspiring Hacker, Part 11 (Apache Web Servers)"
OccupyTheWeb's "Linux Basics for the Aspiring Hacker: Configuring Apache"

Macro Mosaic's "Hack SAML Single Sign-on with Burp Suite"

Barrow's "Use Remote Port Forwarding to Slip Past Firewall Restrictions Unnoticed"

CrackerHacker's "Upload a Shell to a Web Server and Get Root (RFI): Part 1"
CrackerHacker's "Upload a Shell to a Web Server and Get Root (RFI): Part 2"

Ceos3c's "Obtaining Domain Credentials through a Printer with Netcat"

Weird forms of IP address (overflows, different bases, etc) or domain name, to get past a blacklist or filter. Called "URL obfuscation" ?

Cache poisoning: if there is a cache between clients and server, set HTML request headers such as X-Host, X-Forwarded-Host, X-Original-Url, X-Rewrite-URL, and cache returns malicious data. Need to know which headers and parameters are used in cache matching (which are in the cache key). Use Param Miner extension for Burp.

Some ways of transferring a file to a target: FTP, SFTP, TFTP, SCP, WebDAV, shell (run netcat or ncat or something), file-share (NFS, Samba, etc), web app's Upload/Attachment features, object API (SOAP, REST) over HTTP.

Some ways of connecting to a target: HTTP, Telnet, RDP, SSH, VNC, TeamViewer.

EdOverflow / bugbounty-cheatsheet / CRLF Injection || HTTP Response Splitting

EdOverflow / bugbounty-cheatsheet / Open Redirect

When you think you've found a bug:
Gather as much sensitive data as you can. Can you list all users ? Get passwords for user accounts or for accounts on other systems or services ? Get log files ? Get configuration files that show other network devices ? Get PII for users ? Get version numbers of OS and software ? Get encrypted files to try to crack later ?

Can you use this to do another exploit, a better one ?

Kunal Pandey's "Avoid rookie mistakes and progress positively in bug bounty"

Tips / Tactics:

Quick try at a site, from Jason Haddix's "How To Shot Web" (PDF):
  1. Visit the search, registration, contact, password reset, and comment forms and hit them with your polyglot (XSS) strings.

  2. Scan those specific functions with Burp’s built-in scanner.

  3. Check your cookie, log out, check cookie, log in, check cookie. Submit old cookie, see if access.

  4. Perform user enumeration checks on login, registration, and password reset.

  5. Do a reset and see if: the password comes plaintext, uses a URL based token, is predictable, can be used multiple times, or logs you in automatically.

  6. Find numeric account identifiers anywhere in URLs and rotate them for context change.

  7. Find the security-sensitive function(s) or files and see if vulnerable to non-auth browsing (IDORs), lower-auth browsing, CSRF, CSRF protection bypass, and see if they can be done over HTTP.

  8. Directory brute for top short list on SecLists.

  9. Check upload functions for alternate file types that can execute code (XSS or PHP etc).

From /u/Metasploit-Ninja on reddit 1/2019:

Re: misconfigurations:

For pentesting, the vast majority of findings you come across are misconfigurations. Could be screw ups in group policy or bad password policies, etc but I see a lot of things like default creds for web instances like Apache Tomcat (tomcat:tomcat or admin:admin), etc.

I also see a lot of misconfigurations in Vmware Enterprise setups where a customer will have a PCI-DSS/CDE network that is supposed to be segmented from the regular enterprise/production network but isn't fully. For example, there might be a vSphere/vCenter instance that connects to all the VMware Hosts and the customer might have a host for just PCI and others for their regular production network but the vCenter/vSphere can connect to all of them. So if you compromised credentials like a VMware admin in the regular production network, you can just use vCenter/vSphere to jump into a PCI/CDE host then compromise the VMs or even take a snapshot of the VMs you want and download them from the datastore. I see this in a LOT of different places and people don't even think about it. They just see how info flows physically and logically but not how it flows virtually.

Also, I'll see two-factor setups with things like 2FA Duo where they have it set to "open" if the user getting the 2FA request doesn't press anything. This is because Duo communicates via cloud and if something happens to the connection, you can't login to critical systems so by default it fails open. If you have a fairly stable connection, you wouldn't want it that way. If an attacker gets creds and tries to login lets say at 3am and you are sleeping, it would time out and they would then get in without you pressing anything. Oops.

I also see a lot of OWA instances where you can enumerate users because of timing attack vulnerabilities associated with their instance. For example, if you gather a list of users from LinkedIn, social media sites, Google, etc, you can create a list and throw it against the OWA server and if the user is actually present, it will usually respond back with a valid/invalid error after 0.2 seconds. If the user doesn't exist in Active Directory, it will respond back after ~13-15 seconds. See Metasploit module auxiliary/scanner/http/owa_login for info on that and options.

I could go on but those are common ones I see all the time.

Craig Hays' "Bug Bounty Hunting Tips #1 - Always read the source code"
EdOverflow / bugbounty-cheatsheet /


Lots of hackers and bounty-hunters are on Twitter; that seems to be the standard way to communicate. But I don't like Twitter, and I have no need to get the latest news right away. Better to read articles and books and documentation, learn tools and techniques, try challenges.


Done so far:
  1. Tons of reading.

  2. Made a live-session Kali image on USB flash drive:

    1. Downloaded Kali 2018.4 ISO and used Mint "Disks" app to write to flash drive.

    2. Added persistence by doing in CLI (per Kali Linux Live USB Persistence):
      read start _ < <(du -bcm kali-linux-2018.4-amd64.iso | tail -1); echo $start
      sudo parted /dev/sdc mkpart primary $start $end
      sudo mkfs.ext3 -L persistence /dev/sdc3
      sudo e2label /dev/sdc3 persistence
      sudo mkdir -p /mnt/my_usb
      sudo mount /dev/sdc3 /mnt/my_usb
      cd /mnt/my_usb
      # had to do   sudo chmod 777 .   to make next line work
      sudo echo "/ union" >persistence.conf
      # sudo chmod 755 .   to restore permissions to original
      cd ~
      sudo umount /dev/sdc3

  3. Booted from Kali live session USB, selecting "Live (forensic mode)", which means hard disk will not be touched. Booting got stuck for a couple of minutes waiting for "LSB - thin initscript". Login password is "toor", but I wasn't asked for it.

    Distro has lots of tools installed; doesn't have OpenVAS. Has Burp Community Edition.

  4. Tested, and "Live (forensic mode)" doesn't have persistence. "Live with persistence" mode does have persistence. Both modes usually spend minutes waiting for "LSB - thin initscript" at boot time.

  5. Was going to install OpenVAS on Kali, but the live session is just too slow at everything.

  6. Tried to install OpenVAS on my normal Mint desktop; see OpenVAS section. Finally gave up.

  7. Joined HackerOne and Bugcrowd.

  8. Installed Burp Suite CE and got the basics working.

  9. More tons of reading.

  10. Ordered RAM to upgrade my laptop from 3 GB to 8 GB, so I can run VMs etc. And just have a faster machine in general.

Bookmark and Share

Home     Site Map

Privacy policy