I’m psaux. I work as a full-time pentester/red-teamer in Australia and have been working in the field for about 10 years. I started my career as a network admin/engineer and soon realised security was my area of interest. I took up an internship at a security firm and that’s how it all started for me. I forayed into bug bounties about 3 years ago. I got hooked after I reported my first bug (RCE) to a public program (Giftcards) and was awarded an eye-watering amount.
I bug bounty as a hobby now, for fun and to improve my skills mostly - the extra cash doesn’t hurt though :) I have a full-time job so I don’t spend a lot of time on BB. I’ll participate in BBs for a few hours if there isn’t much on at work or home. I average about 10 hours a week.
Although, when I first started out in BB it was quite different. I was trying to manage both work (8-10 hours a day) as well as 5-6 hours a day of BB hunting. I would dive straight into BB after work, wake up at odd hours to participate in new programs that my phone notified me about, barely went out, etc. As you may have guessed, it wasn’t sustainable and it didn’t take long before I burned out.
I took a long break from BBs at that point and one of the best decisions I made was switching off notifications. I now have a better handle over BBs, and participate when I feel like it. I’m a lot more laid back. I’ll come back from work, chill with the wife, go out for movies/dinner or to the gym. I quickly realised that although I could make a lot of dough doing BBs, I was killing myself as a result of it and that it was impacting both my work + personal life.
I spend about 5 - 10 hours a week on BBs on average. I’ll probably report on average 10 bugs a months. Sometimes less, sometimes more. Last month for example, I reported 17 bugs. Woohoo :)
My first bug was an RCE on a public program. It took me about half a day to find. Since I had never participated in BBs prior to that, I wasn’t expecting a whole lot. I woke up to an email with the reward - the best kind of emails - and was hooked at that point.
I don’t have a favourite bug per se, but the one that is the most memorable was identified on a pentest. We were given a scope that covered a few assets which were fairly locked down. I managed to get access to a low privileged account that landed me in a restricted citrix shell. From there I broke out of the shell and got access to a local admin account. And eventually using these privileges managed to get domain administrator privileges. So basically, achieved full control of the domain as an external user. Goes without saying that the client was pretty chuffed.
Other notable bugs include, RCEs on public/private programs; Account takeover bugs; and on one program in particular where I managed to disclose 50 million records.
I always knew I wanted to work with computers. From the very beginning, other than sports, computers was the only thing that interested me really. I did my bachelors in information security, then got a job as a network admin/engineer. Realised I wasn’t happy and made the switch to security by taking up an internship role.
I didn’t run into any problems when I first started participating on BB programs. One of my mates participated a lot on Google and asked me to give it a shot and so I did.
I should mention that when I started out, I did report a lot of stupid bugs that I’m quite embarrassed about now.
Twitter, and a few slack/irc channels. I read a lot too.
Not on bug bounties no. But since I work as a red-teamer/pentester, I do collaborate with my team. I don’t think they would be too happy if I called them out without asking for permission ;) I’d be more than happy to collaborate with any BB member.
I’ll talk about my methodology when hunting for bugs on BB programs as opposed to pentesting/red-teaming.
The first thing I do is to go over the scope. After than point, I’ll perform reconnaissance to discover as much information as I possibly can about the target. This typically includes information such as IPs, domains, applications, employee information, social media accounts or accounts hosted on third-parties. From that point onwards, I’ll test the in-scope targets in the BB brief and leverage the information I identified through reconnaissance. I don’t typically go out of scope, unless I find a severe bug as a result of recon. Although, I’m always hesitant to report it. Reporting an out of scope bug can not only reduce your signal/reputation (if marked as NA), but can also have legal implications. On the flip side, I don’t want the program to get pwned by it.
As for how I test the targets, if it’s an old program that includes applications , I’ll usually go for bugs that are severe in nature and ignore stuff like XSS. With older programs, I’ll explore avenues that others may not have explored or explored properly. For me, anything that is hard to exploit or requires reading documentation is an avenue that has either not been explored or has not been explored properly as exploitation requires additional effort. On multiple occasions, I have identified severe flaws in features that could only be enabled by reading and following the steps in the documentation. You would not have any way of knowing the feature or vulnerability existed without fully reading and understanding the documentation.
On a fairly new program, it’s fairly straightforward: I’ll look for everything and anything and report any medium - critical bugs. I try and avoid sending crappy issues, unless they can be chained together.
Nah, I usually focus on medium - critical issues. I don’t report low risk issues unless they can be chained together to cause a higher impact. If I find something that is low risk and can’t chain it with another bug, I’ll sometimes still report it.
Since I use a lot of tools on pentesting engagements to deliver them under time constraints, I try and do things manually when I’m participating on BBs. On BBs, I have all the time in the world to hack the target so I take my time and see if I can find bugs manually rather than having to rely on tools. I used to automate a lot of things before, and have them send out notifications, but I don’t do that anymore.
I typically only use subbrute, burp, nmap. For recon, it’s mostly manual + grep: google dorking, scans.io, github, linkedin, etc. etc. I will script things up quickly if I have to automate a mundane task though.
I tend to find them manually. I have sets of payloads for each vulnerability class which I’ll test against any page/parameter that I think is worth testing. App traffic is proxied through burp so I just go over the history and pick and choose targets that are interesting. Although, I wouldn’t recommend this approach to anyone coz you can miss stuff that automated tools/scanners can easily identify. But what’s the fun in that ;) Also, you are unlikely to find a “new” bug and be rewarded for it by running automated scans that everyone else is also running. It will more likely be a duplicate, unless of course you are one of the first people to be invited to the program.
It depends on how much time I invest in the program. If I spend enough time then I’m sure to find something on it. If I don’t, then I probably wouldn’t find anything. Size, scope and complexity also play a huge factor. If the scope is limited to say a single application which is bare, it would be hard to find anything.
Yes definitely. But it’s not a requirement. At the end of the day, if your core foundations are strong whether that be in web/mobile development, networking, hardware, reversing, etc. it’s relatively easy to switch to security. If you have a good foundation, you already have the knowledge to build or configure something, you just need to learn how to do it securely. And once you know how to build or configure something securely, you can easily identify when other’s don’t and where bugs/weaknesses could potentially be.
Music from the 2000s: Rock, pop, rap, alternative. Anything from that decade.
Travel, play sports, gym. I’m a big foodie too.
A huge impact. They have helped me improve and hone my skills, meet and connect with smart folks. And allowed me to participate in experiences on a personal front that wouldn’t otherwise be possible.
Not in my BB career. I was already a pentester/red-teamer when I started BB so I knew what to do and look for.
Reverse engineering / exploit dev / hardware hacking. I’m prepping for OSCE at the moment.
The only advice that I would give is to read, and then read some more. The only way to improve is to read and challenge yourself. Pick a topic that interests you and read about it, then go deeper. As an example, if someone wanted to get into application security, you would start off by learning the basics (web application hacker’s handbook is a good resource) and applying that knowledge by participating in CTFs or BBs or downloading vulnerable VMs. Once you are comfortable with certain topics, challenge yourself to get out of your comfort zone and learn new ones. You can’t find what you didn’t or don’t know about so challenge yourself and research hard.
On simple days, cheese, vegemite or peanut butter. On special days, poached eggs on lime infused avocado with smoked salmon ;)
I don’t think I have had a bad experience, at least none that have bothered me enough. But then again, that could also be because I choose to ignore “bad” experiences. I find it easier to move on to other targets and ignore programs that don’t respond or pay well.
I’d work with anyone to be honest. I hear these folks can haxx good ;) - mongo, jstnkndy, frans, avlidienbrunn , bored-engineer, filedescriptor, mlitchfield, bbuerhaus ,arneswinnen, albinowax, garethheyes, iamandatory, meals, etc.
The ability to collaborate; the ability to get in touch with programs directly via chat or other means to ask questions when required; pay on triage
Nano / sublime - yes I’m aware that I’m not a l33t h4x0r :)