Hackers, here's a brain dump to help you understand my general (post-recon) application security testing methodology and how I find high / critical vulnerabilities. This is how I demonstrate the value as a hacker. 💰 Ask me anything. #TogetherWeHitHarder
0x00: I visit the product and marketing pages and read up what the products do. I identify how the product it exposed to the end user. This will give me an idea what the initial attack surface looks like, what data they're protecting, how users interact with each other, ...
... and what the learning curve looks like. I sign up for any number of accounts that is required to test the features. This will give me insight into the individual features. I do some light fingerprinting of the frameworks they use.
I've even talked to engineers, product managers, and executives before even looking at something.
0x01: I prioritize based on features and then weakness type. I generally set a goal for myself to go after particular information, e.g. for an email provider I might ask myself: "I want to get access to someone's emails." Because I know what their features do, ...
... I can make an educated guess which features process emails. This is where I will look for vulnerabilities first and prioritize weaknesses that could give access (e.g. IDOR) before others (e.g. XSS). Some features contain more vulnerabilities than others.
Rule of thumb: the more complex the feature is, the more likely it is it contains vulnerabilities. I never check for two weakness types at the same time. I usually time box looking at a feature, often to avoid going down a rabbit hole and wasting time.
It's often better to pause, take notes on the behavior you observed, and move on. I've had multiple (shower) "aha" moments where I connected the dots later. I don't always find something. That's OK. Work through the system's features until you run out of endpoints.
0x02: Only then do I focus on expanding my attack surface. I use archive.org, their (minified) JavaScript files, documentation, schemas, and best guesses to find these. Personally, I hardly ever brute force files and directories. In this process, ...
... I place myself in the head of an engineer of the company and ask myself: "If I were to build feature x, what would I have to do?" This question helps me identify where technical debt is and how I can automate the detection of new features.
I'm not a mayfly: I pick a target and often stick with it for months instead of switching targets frequently. I actually think I'd do fine as a junior engineer at most of my targets. It allows me to build a relationship with the team.
0x03: I'm familiar with a wide range of vulnerability types. I've only gotten there by creating structure in my work and setting goals. I never start from a vulnerability type, always from an indication something may be vulnerable or a feature.
If I come across technology I haven't used yet, I often take a step back and use it outside of the application's context. This will increase my frame of reference and understand how the technology is used within the system.
I use bug bounties as a way to expand my knowledge, not to treat it as a race. It has helped me being an engineer first. Throughout the process I make extensive notes (with recon.sh, see my GitHub).
0x04: I write simple scripts and use available tools to help me in my process of expanding my attack surface. I've written tools who'd email me a weekly diff of endpoints found in a JavaScript file or code linters to point out dangerous functions or complex code patterns.
