ehsahil/recon-points.txt

## recon-points.txt
Tips from @jobertabma, co-founder of HackerOne -- https://twitter.com/jobertabma/status/998769037445230592

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 http://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 http://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.
I use a combination of @culturedcode and http://recon.sh ! I haven't used mind maps because of the lack of similarity between features across different assets. There's some process to be put in place there and it might help, I've just never done it myself.

Full disclosure: I rarely use them. The stuff that people find during recon, I find when I have a reason to look for it, so you could say I don’t do recon like the majority of the community does their recon. When I do, I’ve used https://gist.github.com/jhaddix .

Of course! Here are some Quora answers that I've written in the past that might help answer your question: https://www.quora.com/How-does-one-become-a-bug-bounty-hunter/answer/Jobert-Abma …, https://www.quora.com/How-much-time-did-you-take-from-completely-beginning-hacking-to-your-first-success-or-bug-bounty/answer/Jobert-Abma …, https://www.quora.com/How-do-bug-bounty-hunters-find-bugs/answer/Jobert-Abma …, https://www.quora.com/What-things-should-I-learn-to-become-a-bug-bounty-hunter-Should-I-start-by-learning-programming-languages-I-am-17-years-old/answer/Jobert-Abma …, and https://www.quora.com/What-can-I-do-as-a-high-school-student-to-get-into-bug-bounty-hunting/answer/Jobert-Abma …. Let me know if that helped!

Personal:

1. Follow security and engineering team members on twitter.
2. Read all engineering/dev blog posts available.
3. Use the Company services as a normal user if you can.
4. Reading commits and public issues conversations on Github.
5. Reading robots.txt files.
6. Be familiar with the companies dev stacks and use them if you can.
7. Watch target companies videos on youtube or on other platforms about new products, demo, conference etc.
8. Search for the information about the targets on Pastebin and trello etc.
9. Searching swf, txt, xml etc files using Search Engines dork.
10. Initially, I report only 2-3 issues with little recon.
11. Follow other security researchers on social networking sites.
12.
	Tips from @jobertabma, co-founder of HackerOne -- https://twitter.com/jobertabma/status/998769037445230592

	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 http://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 http://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.
	I use a combination of @culturedcode and http://recon.sh ! I haven't used mind maps because of the lack of similarity between features across different assets. There's some process to be put in place there and it might help, I've just never done it myself.

	Full disclosure: I rarely use them. The stuff that people find during recon, I find when I have a reason to look for it, so you could say I don’t do recon like the majority of the community does their recon. When I do, I’ve used https://gist.github.com/jhaddix .

	Of course! Here are some Quora answers that I've written in the past that might help answer your question: https://www.quora.com/How-does-one-become-a-bug-bounty-hunter/answer/Jobert-Abma …, https://www.quora.com/How-much-time-did-you-take-from-completely-beginning-hacking-to-your-first-success-or-bug-bounty/answer/Jobert-Abma …, https://www.quora.com/How-do-bug-bounty-hunters-find-bugs/answer/Jobert-Abma …, https://www.quora.com/What-things-should-I-learn-to-become-a-bug-bounty-hunter-Should-I-start-by-learning-programming-languages-I-am-17-years-old/answer/Jobert-Abma …, and https://www.quora.com/What-can-I-do-as-a-high-school-student-to-get-into-bug-bounty-hunting/answer/Jobert-Abma …. Let me know if that helped!

	Personal:

	1. Follow security and engineering team members on twitter.
	2. Read all engineering/dev blog posts available.
	3. Use the Company services as a normal user if you can.
	4. Reading commits and public issues conversations on Github.
	5. Reading robots.txt files.
	6. Be familiar with the companies dev stacks and use them if you can.
	7. Watch target companies videos on youtube or on other platforms about new products, demo, conference etc.
	8. Search for the information about the targets on Pastebin and trello etc.
	9. Searching swf, txt, xml etc files using Search Engines dork.
	10. Initially, I report only 2-3 issues with little recon.
	11. Follow other security researchers on social networking sites.
	12.