Obligatory FAQ note: Sometimes I get asked questions, e.g. on my Discord/IRC, via e-mail, or during my livestreams. And sometimes I get asked the same question repeatedly. To save myself some time and be able to give the same answer instead of conflicting ones, I decided to write up selected answers in separate blog posts. Please remember that these answers aren't necessarily authoritative - they are limited by my experience, my knowledge, and my opinions on things. Do look in the comment section as well - a lot of smart people read my blog and might have a different, and likely better, answer to the same question. If you disagree or just have something to add - by all means, please do comment.

Q: I love low-level exploitation and exploit development! How can I make this my whole career?
A: So to not bury the lead, the problem is that low-level exploitation is rarely needed in cybersecurity, and jobs where one works mostly on low-level exploitation are few and far between. Furthermore, these jobs are even more rare if one wants to stay away from the gray area of hacking and away from the black market. It's more common for low-level exploitation to be a small occasional part of another role.

DISCLAIMER: The goal of this post is not to discourage anyone from pursuing a career in low-level hacking, nor do I think that it isn't an important area of cybersecurity. Rather than that, the goal is to give folks enough information to think things through and plan their approach instead of walking into this blindly.

Let's start with a bit of background...

Background

While the start of the path of learning hacking / cybersecurity changes from time to time, sooner or later it leads folks to try low-level security. This commonly starts with a bit of reverse code engineering – the one on binary / assembly level – paired up with getting to know how to use a debugger and learning the CPU architecture, and leads down the path to learning low-level vulnerability classes and eventually their successful exploitation. While a simple 1988-style stack-based buffer overflow is easy to learn, things get more and more complex as one progresses closer and closer to the newest developments. This is due to the neverending arms race between defensive and offensive sides, that results in new mitigations, as well as the inevitable new methods to bypass them or shifts in approaches.

As such, low-level exploitation is currently one of the most technically complex and challenging areas of cybersecurity. And given the pleasure one feels after successfully making a code execution exploit in a complicated and constrained scenario, it's also immensely gratifying and fulfilling.

Understandably a question like "how do I make this my job" is an obvious one.

Jobs in low-level exploitation

Let's start by stating something obvious, which I still believe must be stated (even though we don't like to hear it): companies prefer to pay for things which they believe are useful and/or beneficial for the company. Pursuing further this point, we can ask the question: how can low-level exploitation, exploit development, and low-level exploits be useful for a company? Let's go through these one by one.

Hacking into things

Starting with the obvious – fully "weaponized" exploits used for their natural purpose, i.e. to hack into things.

So who actually "hacks into things"? We have a couple of groups (in order from less to more... ethically complex if you will):

  • pentesters,
  • internal security teams (e.g. red teams, but also application security teams),
  • law enforcement,
  • military,
  • intelligence and espionage agencies,
  • and cybercriminals (and I'll skip this, since this isn't a legit career in the sense I'm using).

Let's consider pentesters first. And we have to be honest here: in the great majority of pentests folks use off-the-shelf exploits, ideally integrated into metasploit or readily available on exploit-db.com. There is just no time during a pentest to spend on making highly complex low-level exploits that operate in modern heavily-mitigated environments, which also commonly are in the prolonged "exploit superposition" state of "it may or may not work - we'll see" – especially that these can take even a week or more to make and require a lot of skill and obscure knowledge. Unless this truly was the goal of the pentest (not likely), no reasonable pentesting client would like to pay for this, given that the alternative cost is NOT spending this time on reviewing other parts of infrastructure, and also that the risk of a random attacker actually making this kind of exploit and using it to hack the company is minimal (we all know that realistically they will just phish a C-level exec).

"But wait!" you might say, "who is actually making these metasploit / exploit-db off-the-shelf exploits then?" And while what's a good question, I think a better one is "when are folks making these exploits". The common answer is: in their spare time, i.e. not at work. Also, it's pretty common for these integrated exploits to actually be the result of the original vulnerability researcher's Proof-of-Concept-exploit being adapted, integrated, or otherwise "weaponized". Admittedly this kind of adaptation is something that might be done during a pentest, as it's faster than developing everything from scratch – but also it takes out the most fun part of the process. For completeness let's add that at times the source of the initial exploit could be different – e.g. an attack observed (captured) in the wild or a leaked batch of tools from a three-letter agency.

The bottom line for a job in pentesting therefore is, that you don't really get to do much end-to-end low-level exploitation there. You might get to use a low-level exploit someone else made, and from time to time you might need to adapt some exploit or modify it a bit to actually work, but that's the extent of it.

Moving onward to internal security teams. In the case of red teams it's pretty much the same story, with the major difference being that there might be more internal custom systems written a decade or three ago in C or C++ viewed as a viable exercise vector. But there of course wouldn't be any specific long-term focus on these kinds of systems, as only some exercises would touch these. Furthermore, sooner or later the conclusion reached will be something along the lines of "oh, we know it's a weak spot; the blue team has it on their todo list, so let's ignore it for now and focus on other things." So again, rare occasional opportunities for low-level exploitation.

Beyond red-teaming or other-similar-color-teaming exercises there is rarely any need for exploits. For example, from an infrastructure or application security team's perspective, it's key for finding weak spots and vulnerabilities. This of course includes low-level vulnerabilities (a ha!). However... no exploit is usually needed, PoC or otherwise – this is because the end goal isn't to hack this or that, but rather to secure this or that. So in an ideal world, a discovered vulnerability (or even a potential vulnerability) is filed as a security bug with the appropriate dev team, which then fixes it regardless of whether someone actually proved exploitability. There is just no need for a highly skilled person to spend a week on proving exploitation if a fix is a one-liner, done, tested, and deployed in an hour of active work.

This of course points to the two cases, where making an exploit might actually come into play. The first case is when the dev team flat out denies a fix because they don't believe it's a problem, don't think it's an important enough problem, or have more important things to do. This of course is a clear signal of deeper organization problems both in communications and/or intra-team cooperation (yes, soft skills are important in tech, and even more so in IT security). Regardless, at times the decision might just be to prove the problem exists by proving exploitation (yes! we get to work on an exploit!), and therefore showcasing what potentially could happen if the problem is not addressed. I think it's fair to say that most people who are a decade or two in this area of security have or know of a story like this. These however are pretty rare occurrences and rarely more than one demonstration is ever needed.

The second case is when the root cause of a vulnerability is buried deep deep into the whole architecture and changing the offending design would be both costly and time consuming. A great example of this are e.g. Spectre/Meltdown vulnerabilities in the x86 CPUs, or the Row hammer DRAM problem. In such a case actually having a few people spend a few weeks on figuring out if exploitation is possible and how to do it is actually the cheaper option, than jumping straight from the get go to changing everything. These situations however are rare and limited to companies which actually work a lot with low-level products – maybe Microsoft, Intel, AMD, and a few others. And at times specialized vulnerability researchers are contracted to work on these instead – but we'll get to vulnerability research a bit later.

So again – yes, there is some low-level exploitation here, but it's rare and there's hardly enough of it to make a full time long term low-level exploitation career of it.

Next on the list is law enforcement. And the short answer is that no, nobody makes exploits here (UPDATE: though I'm told there are minor exceptions within at least US' FBI / Canada's RCMP; see e.g. this wiki entry; kudos Erik Cabetas!). Law enforcement does buy certain solutions, which under the hood use exploits, e.g. to hack into a suspect's smartphone, but that's it.

Situation in the military is a mix of the pentesting and law enforcement approach, with the added twist that if your country is in an active conflict, you're treated as a combatant with all the dangers that come with that.

And then we get to intelligence and espionage agencies and their suppliers – and this is where a lot of actual low-level exploitation and end-to-end exploit development happens. And at the same time this is pretty much a legal gray area – what's legal or otherwise sanctioned by the employing country, is hardly welcomed by the the target countries – so from the get go one has to make some moral and ethical decisions, and know they won't be allowed to talk too much about their work, like ever (i.e. until it's leaked).

So to summarize this section, the groups that use exploits fall into two categories: the "basically not making exploit" and the "your country's three letter agency" one.

Making, but not using

As already signaled above, making and using exploits isn't necessarily tied up, as both areas are pretty specialized and require certain unique skills and knowledge. So when is ever working on low-level exploits useful for a company enough to make it a job role? Here's a new list for us to go through:

  • vulnerability research,
  • cybersecurity marketing,
  • bug bounties.

Vulnerability research is a bit of a loose term, since it's understood as – depending on the context – looking for vulnerabilities, looking for new ways to look for vulnerabilities, looking for new types of vulnerabilities, looking for new ways to bypass protections, mitigations, and so on, and either exploiting or looking for new ways to exploit vulnerabilities. While admittedly there is some vulnerability research in e.g. pentesting or red teaming, this is often thought as a separate area one can specialize in. And for this or that reason when someone says "vulnerability research" they usually do mean "low-level".

Sounds great, right? "There must be a lot of low-level exploitation there! So, where can I get employed as a vulnerability researcher?"

Good news is that there are legit security research companies that employ vulnerability researchers that do not focus on selling 0-days (we'll get to these in a moment)! Such security research companies get contracted or called in when e.g. an OS developer or a a CPU manufacturer wants to verify the design or implementation of a new security feature, or to assess how hard is to exploit a bug vulnerable before committing to redesign a large piece of a system to address it (in case an internal team doesn't handle that as mentioned before). Furthermore there are other companies which might have an external-facing vulnerability research team for other reasons – probably the best known example being Google Project Zero which mission is to "make the discovery and exploitation of security vulnerabilities more difficult, and to significantly improve the safety and security of the Internet for everyone" (source).

Bad news is that these are really rare, rarely have openings, and have a very high bar to get hired into them.

Since the example above talks about "external-facing" research teams, there must also exist internal-facing vulnerability research teams, right? Correct, though these are more restricted in terms of targets one can choose. E.g. in a web-first company there might not be any low-level internal targets to choose from or they might be rare and quickly swiped by other interested folks.

It must also be added that in some companies there might be roles where vulnerability research is a small part of a larger role. For example, if a company implements specialized compilers or works on an operating system, there should be someone on the team to work on mitigations – both as in development and as in testing. And what's a better way to test a mitigation than to attempt to write an exploit which bypasses it?

Vulnerability research might also be a perk attached to another security role. For example, cybersecurity companies which offer various security services or security products might welcome some time spent on finding vulnerabilities and writing PoC exploits. Successful research gives the company a chance to get its name out there, demonstrate technical prowess, and do some good at the same time – this is why cybersecurity marketing is on the list above. Admittedly a consequence of this is the controversial topic of named vulnerabilities with logos, but let's not get into that discussion here.

And then again we get into the gray area of three-letter agencies, or rather their suppliers/contractors. Probably the biggest job market for low-level exploitation lies in the 0-day industry and exploit "factories" that sell their work to... only sanctioned allied governments and entities, of course. What must be said, is that there is little transparency and little control for an exploit author over what said exploit is later used for and by whom. This of course leads to some complex questions from both the legal and ethical side. And there can be times where one later would learn that their work has been used by a drug cartel or this or that government to hunt down some journalists (if this sounds grim, that's the intention – these are tough questions one should be aware of, esp. if the person is considering this kind of role).

Same considerations apply to indirect suppliers, e.g. folks working on 0-days as freelancers and selling them to brokers or the highest bidder on a black market – there's the same amount of transparency and control of how an exploit is used in this case, that is to say: none at all. And it's also something one will think ten times about putting in their resume, as it might attract legal trouble.

Last on my list are bug bounties and I've included them since there are some folks who actually made it their whole career. It has to be noted, that the great majority of bug bounties are pretty high on the abstraction stack (i.e. web), but at the same time low-level vulnerabilities with exploits have at times pretty high rewards (e.g. for some time Google offered $133k for whole Linux kernel exploits under certain additional conditions). At the same time there are some issues with bug bounties as well, mostly related to randomness of chaotic systems (i.e. our world). First of all, one has to actually find a vulnerability, which is actually exploitable – and there might be weeks or months in-between good findings. But also one has to submit it as the first person – receiving a "duplicate / reported before" response after three weeks of work can be heartbreaking. So while this is an option, it's not smooth sailing by any means.

(UPDATE: I totally missed academia in my considerations! Please see Aurélien Francillon's comment below this post.)

Summary

The whole cybersecurity job market is huge and it seems to be still growing. However, low-level exploitation is a very very small niche in the whole industry. It's cool and awesome, but sadly rarely required. While jobs focusing fully on low-level exploitation do exist, there are very few of them, and even fewer if one doesn't want to answer any hard ethical questions. Furthermore, due to the scarcity of jobs in this segment, the hiring bar is pretty high. It's a bit easier to find a job where low-level exploitation is a small part of the role – there one gets to work on low-level stuff from time to time, even if not as often as one would like. And then we have the whole bug bounty thing, which is where high skill requirements meet the lottery.

Furthermore, the reason there are so many exploits readily available is mostly hobbyists working on this in their spare time. And it's a similar story with a good chunk of vulnerability, or more generally – security, research, which is done after work pro bono by hackers and open-source enthusiasts. This work is important for both the defensive community and pentesters, but hardly a directly paying job (there are resume-level benefits of course).

So should you pursue your dream of being a full time low-level vulnerability researcher and exploit dev? And how should you approach this? Well, these are the questions for you to answer yourself, but I do hope you're a bit more equipped with knowledge to make that choice.

--
Gynvael Coldwind

By the way...
If you'd like to learn SSH in depth, in the second half of January'25 we're running a 6h course - you can find the details at hexarcana.ch/workshops/ssh-course

Comments:

2024-08-04 02:05:11 = Olivia Gallucci
{
Really awesome and thorough post. Thank you for documenting all of this - sent to a few friends :)
}
2024-08-04 05:31:21 = Aurélien Francillon
{
Nice post. This makes a lot of sense.
There are also jobs in academia (PhD student, post-doc or faculty), where the focus is more on discovering new techniques and publishing papers about this. This can involve a lot of low level and to develop exploits.

This often needs more POCs than full weaponized exploits, and may be competitive jobs and require the full academic track record. Also a big part of the job may include other things (teaching...).
}
2024-08-04 08:08:42 = buddy
{
I would like to know more about intelligence and espionage agencies and their suppliers, it would be nice to have some real names of such agencies, companies?
}
2024-08-04 08:21:11 = Gynvael Coldwind
{
@Olivia Gallucci
Thanks!

@Aurélien Francillon
Good catch – I totally forgot to mention academia. I've included a note in the post redirecting to your comment :)

@buddy
Oh there are a lot of stories to tell. If you're interested in this topic check out these books:
"This Is How They Tell Me the World Ends: The Cyberweapons Arms Race" by Nicole Perlroth, and afterwards its critique by Halvar Flake (https://addxorrol.blogspot.com/2021/02/book-review-this-is-how-they-tell-me.html)
"The Hacker and the State" by Ben Buchanan
but also e.g.
"Permanent Record" by Edward Snowden

The story of HackingTeam (https://en.wikipedia.org/wiki/HackingTeam) or the maker of Pegasus software is also pretty interesting.

}
2024-08-04 08:59:15 = Merve Sahin
{
Interesting blog post! Indeed academia is a valid career, however the salary expectation has to be much lower compared to industry (for several years), and the person needs to be willing to relocate few times until landing a tenured position.
}
2024-08-04 22:23:21 = Markus
{
Thanks for sharing. I'm just curious, for someone in a completely different programming field (think high level), what are the "positive" engineering experience I should pursue before diving into Windows low level exploitation? Would recreating say sysinternals or other popular system programming tools useful in this case? I feel lacking exp in low level programming makes it pretty hard to reverse and exploit them.
}
2024-08-06 03:40:20 = T. Ballo
{
Agreed. Low-level exploitation's "mindshare" (headlines, talks, papers, etc) certainly isn't proportional to available opportunities. This post resonated with me because I was unaware of that disparity early in my career, and prioritized accordingly ;)

That said, vulnerability research teaches at least three transferable skills:

1. Comfort with extreme ambiguity. Invaluable for more senior or leadership-oriented roles, where scoping and direction-setting become core responsibilities.

2. Debugging under time constraints. Production incidents require time-bound results, much like CTFs or red team engagements.

3. Performance reasoning. Understanding computer architecture really helps find and fix performance bottlenecks in complex systems (assuming the correct algorithm was chosen).

So for those readers that are already specialized: sometimes a narrow niche can be a surprisingly broad foundation! Good luck.
}
2024-08-06 12:52:48 = 0x4ndy
{
Very good read. Unfortunately, I agree with everything you have written, based on what I've observed out there myself. It feels like, if one wants to pursue this type of career, they will be required to invest a significant amount of their free time to build a portfolio (there are hardly any jobs, let alone junior-level ones). I wonder if, instead of trying to jump straight into low-level 0-day hunting, one might try something in-between, i.e. get an already existing, but not weaponized CVE, try to reproduce it, and then develop an exploit for it. Would you consider this a valid entry in one's resume?
}
2024-08-06 17:52:02 = anon
{
Cool post!
}
2024-08-08 14:51:06 = Radoslaw Madej
{
Hi, very good read, thanks for sharing. As I've had the opportunity to do some of this work myself and I've also had the privilege of leading some amazing low-level offensive teams, I'd like to chip in with a few thoughts:

You're spot on about pentesting and the fact that it normally requires putting in some extra unpaid time to learn and hone low-level skills. There are, however, companies (usually smaller ones) that like to use their low-level research publications to demonstrate capabilities and, in turn, sell them to their customers as consultancy offerings. I know a few people who started as pentesters and used such opportunities to become very successful low-level vulndev/exploitdev professionals. After some time, they are doing really cool research, paid for by their employers (or their clients).

Regarding internal security teams: from my experience, you want product security teams that are part of R&D, as the Red Teams will be busier with operational stuff and, like you've said, have no time for real research. In my teams, we always had the rule of "PoC || GTFO," and we've exploited issues across the entire technology stack, from 'high-level' web APIs to very low-level components, almost always with fully weaponized exploits. Although indeed, sometimes we stopped at PC being equal to 0x41414141 or 0xdeadbeef to prove the point :)

Cybersecurity marketing, when done the right way (one could say: "tastefully"), is not a bad thing, in my opinion. It needs good grounding in reality when it comes to stating the impact, no FUD, and a pinch of good technical journalism (which is a story to tell in itself). After all, what we all get from it is a better product/service/software that we all use in one way or another, thus benefiting the good guys.

All in all, in my humble opinion, the overall picture is not so dark :) My piece of advice for people willing to go for a 'low-level hacking career' would be to find a product company that sells something where they have to care about security: a renowned consumer electronics brand, security product vendor, automotive or airplane industry, etc. These are the most likely companies that will, in fact, encourage you to hone and develop your low-level skills. If you can accept that it won't always be 100% exploitdev, but at least 100% vulndev, you can find pretty interesting opportunities. And while it's true that often the bar for entry is set quite high, from time to time they will be looking for juniors who can demonstrate their passion for low-level stuff and willingness to learn.
}
2024-09-03 19:01:48 = Lachunas Berme
{
I look at exploit development today on par with studying Philosophy or something in and of the Liberal Arts. They are both subjected to the same questions and amount of scrutiny with regard to their relevance in the job market. They're both intellectually demanding and require a level of mastery effective for application in their respective domains. And they both change one's perspective on the abstractions (reality/virtuality) in which they exist. With this, the pursuit of a credential (in a degree) or certificate ( in offsec, sans, corelan, etc.) in both endeavors can prove challenging, rewarding, and even life-changing, but it may only equate to a specialized and unique way of thinking that is only valuable through the journey, not the destination. All of this is to say, devote the time, effort, sweat, and energy if what one is after is insight and perspective, but understand that what is acquired through study is beneficial almost only through adjacency not direct applicability.
}
2024-09-03 20:09:50 = Lachunas Berme
{
btw, I remember watching one of your vids on YT about fuzzing with Python like 6-7 years ago that was the best intro to the topic I'd come across. Kudos to you and everything you've contributed to the community. Cheers!
}

Add a comment:

Nick:
URL (optional):
Math captcha: 7 ∗ 3 + 9 =