Have you considered looking into white hat hacking? You could essentially be paid by companies to hack their own product entirely legally for the purpose of better securing it against potentially malicious hackers.
In my observation, this is a branch of industry that is very hard to get into.
> You could essentially be paid by companies to hack their own product entirely legally for the purpose of better securing it against potentially malicious hackers.
For this purpose, one uses quite different techniques than for blackhat hacking. E.g. in the whitehat case, the source code is often available etc.. So brutal code reviews, which require rather different skills (e.g. knowing all the subtle details of the language standard (e.g. C/C++)), are much more effective to secure applications than using the typical "blackhat techniques" (reverse engineering, knowing subtle details of CPU behaviour etc.).
I used to work at a company that did pentests (although I never did any myself). This was never the case. Every single one was approached in the same way an unprivileged attacker would approach it, apart from, when testing a production instance of an application:
- dummy accounts are set up, so that if user data must be extracted it doesn't come from real users
- you're not allowed to do anything that risks taking the application offline, destroying data, etc.
brandonjm wrote above (emphasis by me): "You could essentially be paid by companies to hack their own product entirely legally".
It would be a massive waste of time and ressources not to give the internal whitehead team any internal information possible to secure the application. For this I stand by my point that the methods that I stated are usually much more effective.
Pentesting is typically applied in very different scenarios (not a company hacking their own product as in brandonjm's scenario).
You are absolutely right about the massive waste of resources that holding back info causes. It's way better to give consultants complete control of a working test system with the full build environment. And they might as well just let you do it remotely. But many companies don't do that. Instead they would rather eat your travel and accommodation costs, and then when you show up you're being paid to sit around for a week because they don't even have things ready, so you sit around reading bullshit documentation so you look busy and your contact doesn't look bad. And when you finally do get something you spend lots of billable hours figuring out how to get it up and running, which provides absolutely no value to them and wasted valuable time you could have been finding bugs. But that's just how it goes.
I know some people (myself included) who would work as consultant but have no idea how to even get hold of consulting jobs. Yes, I often ask people who are much much successful in getting those, how they got them. These successful consultants eventually admit that they themselves have no real idea. People just approached them etc. I (and lots of other people) are not the kind of people "that are simply approached".
TLDR: I would not even know how to start to get consulting jobs (and lots of people have a similar problem).
Disclaimer: I am talking about the situation in Germany. In the USA, it might be different.
First of all, forget about the "situation in Germany". Work is everywhere, so be willing to accept work anywhere. There's definitely a pecking order in consulting firms and you can get projects because the company gets a one off engagement with a new client who wants the work done on site. The company has some really awesome full time employees who could do it in their sleep, but they're busy on long term contracts with key clients. Be willing to go, as a subcontractor, to some unglamorous location for a week long project to pentest some shitty internal application that nobody has ever heard of. Get a few of those under your belt and you'll know how it works.
Second, understand that there's more to it than your technical skills. Make friends who work in the industry. Talk with them about what they're working on. Find any interesting bugs or behavior in what you're working on? Chat with them about that. Doesn't really matter if it's security related or not. The people who do the work in the industry are all generally interested in the details of software. If you're into that, then you belong.
Keep reminding your friends that you're hungry for work. Keeping in touch will keep you in mind when they need an extra guy to help out.
Once you start getting work be sure you contribute well. Everyone wants to have the most high severity findings, and obviously you will need to produce those if you wanna keep getting work, but also be that guy who goes the extra mile to help put the report together, write up extra recommendations that would be helpful.
Keep in touch with the people you work with. Be cool to the sales/project management/accounting people. It's simple things like getting your expenses/timesheets/invoices filed in a timely manner. There's more to the business than finding vulnerabilities. Everyone wants to close out the job, get paid, and move on. Show everyone that you know how to behave like a professional. Remember that the people responsible for staffing are asking themselves: Who do we know that we can send in there to take care of this work, so that we can bill them and collect this revenue, who will get the job done and be easy to work with?
Be that guy, and you will be approached too, and you can find full time work in the industry if you want.
There are some who work in reverse engineering, CPU interactions or static analysis but those are often more senior positions within a company, are more research focused or specifically marketed as such; my role as a pentester is focused on dynamic testing from a blackbox perspective. Sometimes we are lucky to have architecture diagrams, API docs, or source code but they only serve to benefit the test from an external perspective. I don't analyze the code and report vulnerabilities there, I report findings from a perspective of breaking the application in runtime; the code only makes that easier.
Anyone here wishing to break into security to "be a hacker" might find web app pentesting to be the most familiar for developers (it's not far from skills used for UAT, QA and debugging) and provides a pathway down the OSI model. There are companies that will take strongly motivated and technical people to train into pentesters, as the field is vastly understaffed and it's easier to train someone on your methodology from day 1. However, this normally starts as Web App (it's where the money and clients are) and one can move into other areas over time.
I'm more than happy to provide more details or resources to those interested. My knowledge is more in the attacker area, but its possible to start in either side and pivot into the other. Time, patience, and a willingness to learn.