Cybersecurity Mentors Podcast

A Day in the Life of a Penetration Tester with Carson Sallis

• Cybersecurity Mentors • Season 3 • Episode 6

Share episode

In this episode, we chat with Carson Sallis, Senior Offensive Security Engineer and Vulnerability Researcher at NVIDIA. Carson walks us through a day in the life of a pentester and shares actionable advice for anyone looking to break into offensive security. He also gives a live demo of fuzzing with AFL (American Fuzzy Lop) and explains how tools like this are used in real-world vulnerability research.
Whether you're just starting out or looking to sharpen your red team skills, this episode is full of insights you won’t want to miss.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Episode Resources:

GitHub: https://github.com/cybersecmentors/season_3_ep_6

Guest: Carson Sallis 

Follow Carson and connect for updates, demos, and career insights.

LinkedIn:  https://www.linkedin.com/in/carson-sallis/

Fuzzing Tools & Resources

· AFL (American Fuzzy Lop)
The fuzzing tool featured in Carson's demo.
Link: https://lcamtuf.coredump.cx/afl/

· AFL++
An advanced fork of AFL with modern features.
Link: https://github.com/AFLplusplus/AFLplusplus

· Fuzzing: Brute Force Vulnerability Discovery (Book)
A foundational guide for learning fuzzing.
Link: https://nostarch.com/fuzzing

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Connect with us and leave us feedback:

  1. Cybersecurity Mentors Podcast Swag: https://the-cybersecurity-mentors-pod.myspreadshop.com 
  2. Mentorship - Sign up for a FREE session: https://www.cyberprofessionalservices.com/scheduling-free-consultation
  3. Sign up for our Newsletter: https://sendfox.com/lp/m2vx85 
  4. Join us on Discord: https://discord.com/invite/g4yRKjnD78
  5. Follow our LinkedIn page: https://www.linkedin.com/company/cybersecurity-mentors-podcast
  6. Check out our YouTube channel for more content: https://www.youtube.com/@CybersecurityMentorsPodcast
  7. TCM Affiliate Link: https://certifications.tcm-sec.com/?ref=1

Send us fan mail via text

Steve:

Could you teach me First learn stand, then learn fly. Nature ruled on your son, not mine.

Carson:

I know what you're trying to do.

John:

I'm trying to free your mind, neo, but I can only show you the door. You're the one that has to walk through it.

Steve:

What is the most inspiring thing I ever said to you don't be an idiot changed my life. Welcome back to the cyber security mentors podcast. You've all been asking for it. Today we're talking about offensive security and to help us break it down, we have our number one still number one guest so far from all the episodes we've done Carson Salas, an offensive security engineer at NVIDIA.

Carson:

Hey, it's great to be back.

John:

Welcome, welcome, glad you're back. It's good to have you.

Carson:

Good to be here.

John:

Yeah, yeah. I keep tracking Carson's stats and I think he's got bots out there that are just slowly inching up the numbers. How is he the number one? Not that you're not amazing, but I do not recall.

John:

I uh, but I did not recall. But like I look, I'm like we're not advertising, we're not putting it out there like, oh, this is the one, this is the one. But hey, people, they see your name, they think this person must be very intriguing and they stick in, dig in and check it out. So it's, it's the number one episode, so congratulations thanks, that means a lot.

Carson:

I've heard I've got a name made for show business, so that's, that's probably what it is yeah, no, um, so we, we wanted to have you back.

John:

Thank you for coming back. Thank you for the last episode. Um, we were brainstorming ideas to talk about that. We thought people would find interesting, um, and some of the things you're doing now that are very cool and and your day day life, day-to-day life, and just kind of what things you're doing now that are very cool and your day-to-day life and just kind of what you've got going on. So let's talk about that. What is a day in a life like for Carson? What does that look like?

Carson:

Sure. So, like Steve said, I'm basically an offensive security engineer and that's sort of almost, almost an umbrella or catch-all title for you know, it could be red teaming, it could be pin testing. There's really a lot of things that fall under offensive security engineering. But specifically what I do is vulnerability research or bug hunting, and this varies a little bit from sort of like a bug bounty hunter Usually that's more focused on web application pin testing. Bounty hunter Usually that's more focused on web application pentesting, whereas what I'm doing is more focused on something like finding zero days. So, you know, maybe I'm looking at source code, I'm reviewing it, looking for bugs, maybe I'm doing fuzzing. At the end of the day, my job is just finding bugs, typically in source code that I have access to.

John:

Yeah, very cool. And yeah, I think that is maybe a little different than people think of as like oh, he's offensive security, he must just be doing pen tests all the time, and it is that mindset and that's where you've built your skill set. We'll talk about those skills too, but it's a focus on, you know, application focused, source code focused, digging in finding things before bad guys find those as well. Um, and how did, yeah, I know, with your job in this role, but how did that trans? How was that transition for you from maybe more pen tests, offensive security tests, to bug hunting?

Carson:

Sure. So pen testing is a. It's a nice foundation for a lot of different aspects of offensive security, because really there's a lot of different aspects of pen testing. You know you have network pen testing, you have web app pen testing, you have IoT cloud. You know there's really just lots of different types of penetration testing that you can do. No-transcript. It comes to vulnerability research. You want to have some background in fuzzing, you want to have some background in programming or at least source code review, and if you have all of that and you really excel at those things, then you can also excel at vulnerability research.

Steve:

So question for those listeners who might just be getting started what is fuzzing?

Carson:

Sure. So fuzzing is basically you can almost kind of figure out what it is just from the word, but it's basically you just take a program and you take some input and you make it fuzzy and you just send it to that program. So imagine you have a program that accepts, you know you type into it, you basically write a string or some text or anything like that and you type into it, you press enter. Basically that's input that goes into that program. So fuzzing would just be taking input such as that and sort of continuously transforming it. Maybe you're making it bigger, maybe you're making it smaller, maybe you're changing different bytes here and there, but basically you're continuously transforming the input and you're trying to find edge cases. You know you're trying to find basically edge cases that developers didn't account for and something that can result in a bug or a crash. And that's really the whole purpose of fuzzing is you're just taking input, you're doing things to it, you're sending it and you're hoping something bad happens.

Steve:

Okay, so not that something breaks, or is that also something you're looking for?

Carson:

Sure, if something breaks, if the whole program breaks, really you want to see any sort of malformed activity. If the program is doing something that it's not supposed to be doing, then there's a chance that there's a bug there and there's a chance that you can exploit that bug to do something later on.

Steve:

Okay, awesome.

John:

Yeah, I think about my closest activity that I've done just more like SQL injection. Right, you've got an input form. You've got it should accept specific types of characters or numbers and you are able to manipulate that to get it to do something that it shouldn't. You know either append a query or you know something else, get it to error in some way. But more, not just SQL injection but any input, and I think that's part of it. It's just like what you're doing. Carson is like more application focused than web focused, right, and more program focused, but still it's the same, would you say. That's the same concept.

Carson:

Right, definitely. I would say that you could almost use fuzzing to even find a SQL injection, whereas SQL injection is typically more of a sort of specific form of fuzzing, where you are sending SQL parameters into something as input. You know, potentially you could discover a SQL injection, because if you are just sending tons and tons of malformed input to a program that accepts basically SQL commands, then you will see that the server or whatever is handling that SQL is performing not as it's supposed to perform. So again, sql injection a little more specific, but fuzzing can definitely find SQL injection vulnerabilities and you could even say that you know SQL injection a little more specific, but fuzzing can definitely find SQL injection vulnerabilities and you could even say that you know SQL injection is sort of a form of fuzzing.

Steve:

Cool. So how did you find your way in this position? Like, how were you doing some bug bounty stuff before? Like, is that kind of what sparked your interest? Because it is kind of a I mean, I would even say a little niche area right now. Right, it's not what you always hear about when you talk about pen testing or even offensive security. So how did you find your way into this position, into this role?

Carson:

So I would say people naturally find their way into this position as they want to go deeper sort of into their offensive security career. So you know, for instance, you can start out basically doing basic network penetration tests and a lot of times with that you're looking for misconfigurations, you know. You're looking at ports that are open, that aren't supposed to be open, services that are running that people don't know about it, maybe vulnerabilities that exist because of outdated versions and things like that. But typically what you're finding is, you know it's not reinventing the wheel, it's sort of finding things that people already know about.

Carson:

But you know, sort of when I was at that point, I wanted to go one step further. I wanted to say you know, I can find the vulnerabilities that people already know about, but I want to find vulnerabilities that people don't know about as well. And typically when you do that, that's when you really take the dive into vulnerability research, because you're not just looking at you know work that other people have done. You're trying to say you know, how did they find these vulnerabilities, how can I find these vulnerabilities now? And that's sort of how that transition happens. Is you just go really another layer deeper?

John:

Yeah, and could you talk about and we're going to do a demo here soon and maybe this will do that but well, I was going to say, could you talk through kind of the general workflow, Like what does that look like when you've been given an application or source code?

Carson:

Sure, so let's say I'm given a application and all the source code for it and we'll say that the application is coded in C or C++. Basically, I would start with source code review. That's where I'm doing manual review or I'm doing sort of a hybrid approach where I'm maybe using a tool like grep or waggly that searches for very specific strings in code that I know sort of result in vulnerabilities. So it's again it could be me looking at it from, you know, top to bottom of the code. It depends how really you know the size of the code base. If it's a small code base, great, let's look at it by hand because you know I can then have the peace of mind to know that I looked at every line of this code.

Carson:

But unfortunately that's not always the case. Oftentimes you have code bases that are huge and it's not feasible to look at all of it by hand. And that's where it's good to sort of bring in automated tooling. That's where it's good to bring in you know, fuzzing harnesses and things like that. That way, you know, you can still do your due diligence. You can find vulnerabilities in the code even if you're not looking at every single line of that code.

John:

So just to for education purposes. You mentioned Waggly. I think you said it's Waggly, it's.

Carson:

W-E-G-G-L-I I believe, but it think you said it's a, it's it's waggly, it's w-e-g-g-l -i I believe, but uh, it's basically it's sort of like a supercharged grep for finding vulnerabilities and and I use it for finding vulnerabilities in c code.

Carson:

So it's again sort of uses, uh, regex or regular expressions which are sort of like a, a way to. It's a pattern that basically can identify multiple different patterns going forward. So you know, if I'm looking, if I have a string that's a sentence, and I make a regular expression that says you know, show me a line that has only, you know, alpha numeric characters, I can make a regular expression which is basically just sort of like a simplified version, almost like a code word or code name for that string, and it'll return all sort of strings that fit that rule. So basically I can make rules that will return basically potentially vulnerable lines of code to me and it at least points me in the right direction. It doesn't always find vulnerable lines of code, but it's a way that I can find common mistakes that people make when they're coding and that sort of can lead me down that path.

John:

Okay.

Steve:

What are some if you can share? Have you found any cool things while you've been working? I mean anything that you can share or talk about, kind of what you found and what that meant right, what you finding that meant for the application organization your career yeah.

Carson:

So I can't really share any of the you know any findings or vulnerabilities or anything like that from my day job. But I definitely can share past examples of me finding vulnerabilities. And a lot of this is through source code review where, you know, basically I'm looking at open source products and the nice thing is with open source products is you have access to all the source code. It also means everybody on the planet also has access to the source code, so you're less likely to sort of find vulnerabilities at that point. But that doesn't mean they're not there. So there definitely been times in my past where, you know, I've done some source code review. I have used tools like grep and Weggly to find vulnerable lines of code and I basically have been able to patch those lines of code. You know, in an open source project where I say this is a vulnerability, I discovered it, here's how you fix this vulnerability and it's good to go.

Carson:

And I know you specifically asked you know, career wise, how does that help? And it really helps in a couple of ways. I would say the first way is it helps from a technical perspective because you know you're getting real world experience. This is what I do in my day-to-day job is I find bugs. So if you can do that in the wild and basically learn how to do it, then you're setting yourself up for a position like this in the future. And then the other way it helps is if you get any sort of you know CVs or basically you know you have this sort of public work that's attributed to your name, then that definitely really helps when you're trying to land a position in offensive security Very cool Awesome.

John:

Yeah, thank you. Yeah, is there is there. I'm just curious, before we go to the demo, is there one of those things that you, if you were reviewing code and you're like, oh, this is the thing, oh, they messed up here? Is there like a favorite find or a favorite weakness that maybe not favorite, but something that is a common weakness that people will still use and maybe they use it in source code and open source code that it's like Ooh, this is, this is what I was looking for. Are there any of those that stand out or am I way off base? Maybe I'm off base.

Carson:

Yeah, I would say the ones I really like to see is when people aren't balance checking, because oftentimes that can be missed where people are looking through the code and the code works perfectly fine as long as you're putting in the data that's supposed to be in there.

Carson:

But if someone's not balance checking and making sure that the data is in there is precisely the data that is supposed to be in there, then that can sort of result in overflows and things like that and potentially even result in RCEs or critical vulnerabilities in the future, just due to the fact that you can sort of write data outside of where you're supposed to write it. So a lot of these they're less common nowadays because we have more modern programming languages that do a lot of these things by default. We've got a lot of sort of defenses against it now as well, so it's less common. But you know, if you're looking at C or C++ code, it's definitely something that you want to look for and even if it is a open source project, you know there is a chance that vulnerabilities like that still exist and can still result in, you know, a buffer overflow or something like that.

Steve:

Great. Did you do like bug bounty hunting before this position, and is that kind of how you you progressed and kind of build your, your arsenal, your, your skills?

Carson:

Yeah. So I actually did do bug bounty hunting before this position. It was more of a web application penetration testing type role and it's really not a clear way to progress to this line of work. It's kind of like you go down one road, you take a U-turn, you go one road over and then you get there. You're moving in the right direction, but you're definitely not going straight there. You know you're moving in the right direction, but you're definitely not going straight there.

Carson:

But a lot of the fundamentals that I learned for instance, there is fuzzing in web application pin testing. It's not the same type of fuzzing really. You know there's some pretty stark differences, but it's got the same premise, which is that you are just supplying lots and lots of input in hopes of finding something in a web application pin test perspective of input in hopes of finding something in a web application pen tests perspective that's typically a directory or a domain or something like that that basically other people don't know about. So, even though that's really a pretty stark difference from this line of work, the fundamentals are the same and if you think like a hacker, you're really going to be able to apply that mindset. You know, no matter if you're doing web app pentesting or vulnerability research or even something else.

John:

Well, that's. I think that's good, good transition. Are you ready to show us a demo for those listening? We'll try to add some just audio. Only We'll try to add some color to it if you want to narrate it a bit as you walk through it.

Carson:

Sure.

John:

This is also our first screen share for the podcast, so don't screw it up, all right? No?

Carson:

pressure. I'm excited, yeah. So basically what I want to do is I have a Vulnerable C program and it's really as simple as it gets and I want to show sort of how a vulnerability exists in there and how I would find it using a fuzzer such as AFL. This is a industry standard open source fuzzer that anybody can use if they want to use it, and I'm just using it with this very simple C code that I wrote up that is obviously vulnerable. Just to show you how I would do it, because if you know the fundamentals then you can apply that to anything you know, not just extremely simple C code. So that's, that's basically the demo. So I'll go ahead and pull that up. Just give me one second, all right.

Carson:

So basically, as of right here, I have phone c, so really all you need to know about this, if you don't know c, then this may look like gibberish, and if you do know c, it still may look like gibberish because it's not the best code. But basically what it does is we have input where we're receiving basically a char buffer and then we are just receiving that input, piping it to our vulnerable function here, and basically we're just receiving that input, piping it to our vulnerable function here and basically we're just echoing it back out. So obviously this program doesn't do anything special Takes input, prints input back out. But the issue here is that we have a tiny buffer for that input to stay in and we're using a stir copy without any bounds check and that can result in a buffer overflow. So now that you kind of know the gist of it, I'm going to show you how I do it and I use a tool, basically it's afl. There's lots of different fuzzers that you can use. I prefer afl. There's afl plus, plus there's tons of other ones.

Carson:

But basically what I'm going to do now is I'm using the compiler, because c is a compiled language. So you can't just take the program and then run it like you could with python. Basically, you have to take the C code, you compile it, so we have a binary and then we're specifically using a compiler that comes with our fuzzer. That's really the secret here is, you know, we can't just well, we technically could fuzz it like black box fuzzing, where we're just supplying basically you know whatever input we want and seeing what happens. But when we compile it with our fuzzer, then it gives us sort of a look under the hood of the program and that's sort of where the secret is.

Carson:

So, as you can see, I'm using Clang, which is supplied with AFL, and we are creating the binary vuln from our vulnc file. And then this is just a flag that I'll explain later. It's a address sanitizer flag. It makes it easier for us to figure out where the vulnerability is. So I set that to one or true, and it just works. So I'm going to go ahead and compile that.

John:

And Clang is the compiler.

Carson:

Yes, that's correct. So there's also just Clang by itself. You can use GCC, you can use Clang, but specifically we want to use the version that's included with AFL because that gives us the look under the hood. So there's also AFL, gcc and we could use that, but I prefer Clang because we can use an address sanitizer which lets us look under the hood, which I'll show basically at the end once we find our bug. So let's see, now we have our vuln right right there.

Carson:

That's our binary, and if I just did a simple hello and I piped it to our binary, which is our code that we just compiled, it just pipes it back out. So we say hello and the program says hello right back. It's a very polite program and now we basically need input because, like I said, with fuzzing you can't just sort of have nothing and expect it to work. You need to give it at least one sort of not malformed input. So, for instance, hello, I said hello to the program, the program worked and it said hello back. So for this one hello would be our input. That we know works. So I have our ctxt, all it is is hello and we're going to use that as our basis for fuzzing. So basically, afl is going to take hello, it's going to pipe it in to our phone and it's going to continuously mutate and expand that until it finds any crashes or bugs or anything like that.

Carson:

So what we can do now is actually kick off the fuzzer. So if I'll fuzz and then we give it our input folder and then we give it an output folder, which I'll just call output, and then we give it our binary, so this is our fuzzer, aflfuzz. This is where our seedtxt is, this is where we're storing all of our results and this is the program we're fuzzing. So we kick it off. Oh, let's see, we may need one quick. I'm doing this on Windows. This is not recommended, but for those of you who are really brave, you can do it on Windows and you just have to make sure that the crashes are piped to your sort of Windows subsystem for Linux and not standard Windows. So I can just do that and it should work.

John:

Fingers crossed, there we go let me ask you this right quick is the seed text? Is that a standard formatted file? Like you didn't't tell it to use seedtxt, you created it, but is it noted? You can make it anything, okay, okay.

Carson:

You can make it as long as it's in that input folder. You could have seedtxt, you could have crashmetxt, you could have tons of things, you could have multiple files. It's just going to take whatever basically you give it and try its best to expand from there. So the important things we're just giving it that input folder and it's smart enough to look in the text file in the input folder and pick that first string and just use that. And if there were multiple things it would go through multiple, but we only need one because it's a very small program.

John:

Yeah, I see what AFL stands for. I did not know.

Carson:

Yep American Fuzzy Lop.

John:

Lop, not loop. First, when I first saw it, I thought loop, but no.

Carson:

I believe it's a bunny.

Carson:

I'm not 100% positive on that, but I believe it's bunny related, but yeah, that's what AFL stands for and, as you can see, it's running right here. It's been running for one minute and four seconds, five seconds, and what we really care about is this. So, as you can see, we have quite a few crashes here. Normally, if you're doing this, you would have zero, maybe one, two, three, you know a handful if you're doing a really good job. We've got a lot because, basically, the buffer is so small that if you give almost any input to this program, it crashes. So small that if you give almost any input to this program, it crashes. The good thing about AFL is that it recognizes that this is one specific, distinct crash. So it's identified really one specific, distinct vulnerability in the program and we can look into that right now. So we'll just control C and kill it and then we can just have friendly.

John:

It says have a nice day.

Carson:

So it's a very friendly program, unless it's April Fool's Day. If it's April Fool's Day, it is indiscernible. It talks about creating pizzas. You should look into that. It's really funny. They got me on April Fool's Day.

John:

So I don't want to talk about it. Nice, what is happening.

Carson:

Yes, it was a fun time, but yeah. So here is where crashes are. This is just the default output folder. So we have output default crashes and, as you can see, we have one distinct crash here. And you may look at this and be like I have no idea what any of this is, and that's okay, because you don't have to know what it is, you could. All that it matters is it's really a crash and the important thing is we used our address sanitizer that I showed you earlier, so we can just take our binary and run it like normal and then just pipe this crash into it. So output default crashes, id, that and boom.

Carson:

All right, so let's zoom out just a little bit so we can get a better idea. And, as you can see, we, with the address sanitizer, we get all this info, which is it's really really nice if you're looking for bugs, because if we don't have our address sanitizer, we don't get any of this. We basically just get a crash. But with our address sanitizer, we see specifically there's a stack buffer overflow on this address in memory. Again, unless you know you know the memory region of your computer like the back of your hand this probably means nothing, and if you do know that then you should probably seek help. But if you don't know it then we can just go through this little path here and see that stir copy is the issue and it's located in vulnerable function on line six. So let's just go back to our vulnerable function and if we see line six, boom, stir copy. And we have a stir copy with no bounce check, which is basically resulting in the buffer overflow. If this was checking for basically the eight bytes that are allowed right here, then it wouldn't be possible Basically. You'd put in more and it would either drop whatever's extra or say you know, like we can't copy that you know there may be other errors, but it wouldn't be a vulnerability. Specifically with this is a stack buffer overflow due to no bounce check that's located on this specific line.

Carson:

So basically what we started with is you know we had a vulnerable C program, we compiled it with AFL with our address sanitizer and we found a crash and we specifically know that the crash is due to a buffer overflow at this line. So you know, just in a few minutes we did a little bit of fuzzing and we have a buffer overflow. Obviously, in the in the real world. It's not always going to be that simple or that fast, but this is you know the fundamentals that help you find this. If you know how to do this, then you can take that and you can find vulnerabilities anywhere and you can build on that. And it's the same premise. It doesn't get substantially more complicated or convoluted than this. If you know this, then you can really start just finding bugs anywhere. If you really know how to do it and you know the fundamentals of fuzzing.

John:

And let me ask you this Do you think a good way to practice I mean, obviously you could go through a bunch of source code and find source code that's open source and try to find these and it's good practice to do that anyways, because you've got more code that you've got to review but do you think it would be useful to have generative AI, say, hey, can you create some example code for me that's going to have a bug, that I won't know what the bug is, and have it? Then go tackle it with AFL and see if you can find that vulnerability, things like that, just to get reps. We'll talk about skills and things, but is that a good approach?

Carson:

potentially, yeah, I think that's a really good approach. I think that if you're just getting started, then AI is really good at creating very small programs that work perfectly and they can walk you every step of the way. So if you do it like that, then it's a great way to start out. And if you build on that and you're like, you know I can handle anything that this AI is throwing at me and you want to complicate things.

Carson:

You can look at other CVEs, look at open source projects where CVEs have been found in the past, find the vulnerable code, take that specific version of the project and see if you can find that code. Now you probably don't do manual review because it's pretty easy to find vulnerable code if you know what the vulnerable code is. But you could try throwing your fuzzer at it and saying you know, would my fuzzer find this vulnerability? How long would it take? What could I do to improve it? You know how could I find this faster? What could I do to find other vulnerabilities like that? And that's really how you improve and build in this field is you say, this is how people have done it before me. How can I go one step further? You know how can I find the bugs that may be just out of reach?

John:

Yeah.

Carson:

Very cool.

John:

And what does that look like for a report or something back? I mean, you know, I think of a pen test report, right, but is it? Is that what you're doing is giving them? Hey, here's my assessment. Here's a report of what I found. What does that look like?

Carson:

So typically the way I do it is I fix the code as well, and that's not always the case, but oftentimes, if it's a simple vulnerability like this, where there's just no bounds checking, I add bounds checking. That will take me one minute to do, basically, and then I can go to the developer, who is probably you know, a lot of these developers are already doing a lot of work and they may be working at a different section of code, they may not be even in the same mind space of working on this code, and I can go forward and say I've looked at this code, I've found this vulnerability, here's how you fix the vulnerability and here's the exact code to do it. And then at that point they can just sort of review the code, they can push the changes and things are good to go. Now, this isn't always the case.

Carson:

Where it's an extremely simple area of code where a vulnerability exists, sometimes the vulnerability can be integral to the entire code base and things get a little tricky that time and maybe you don't really know the best solution. And again, the best thing to do at that point is just report the vulnerability, have a proof of concept or something like that, showing how it is a vulnerability and just leave it to the developer at that point, because vulnerability researchers, they don't always have the same depth and expertise that a developer has, where sometimes you just have to do your part, hand it off to the developer and maybe help them retest. If they fix it, they say, hey, I fixed it, can you look at it again? You look at it, you prove that it is fixed and everybody wins Very, very cool.

Steve:

So what are maybe some other skills or just foundational knowledge that you would recommend someone who might be thinking about taking their career into this side of offensive security, things that have helped you.

Carson:

Yeah, so are we talking specifically vulnerability research or just offensive security as a whole?

Steve:

Well, I would like to ask just for vulnerability research first, and then we can ask the same question for just offensive security overall.

Carson:

Gotcha.

Carson:

So, just starting with vulnerability research as a whole, the best way to do it is just start digging through code, you know, find a program Sometimes you can find some you know esoteric program online that nobody uses but it's open source and start looking for bugs.

Carson:

Or if there's a program that you use in your day-to-day life and you notice some maybe weird activity when you do a certain thing and you can replicate it, maybe you can look into that. And there's really a handful of different ways to go about it. But the best way to do it is really just to dive in. As long as you have the programming expertise to know what the code is doing, then really all there's left to do is look at the code and try to find bugs. And if you're not quite at that level, then the next thing to do is really just get that code expertise, work on programming, work on understanding the code as a whole, to where, if someone does throw some code at you, you can basically handle anything they throw at you because you're familiar with C or C++ or you know just object oriented programming as a whole.

Steve:

Okay, perfect, thank you. So now let's talk about offensive security as a whole. If someone is thinking about starting a career or transitioning over, what is some advice that you'd like to share on just how to get started?

Carson:

Sure. So there's sort of some pros and cons with offensive security, and I'll start with the cons. But the cons is a lot of times you can't really get a degree in offensive security. There's not a lot of universities out there that are comfortable teaching people how to hack computers and cause mayhem and all of that, and that's sort of a con just because there's no formal education path. But it is also a pro, depending on how you look at it. And the pro means that you sort of are dependent on your skillset. You're not dependent on a certificate or certification.

Carson:

There are certificates and certifications, but a lot of times if you're starting out, you can do just fine just by having that skillset. And there's very few industries where that's actually the case, where if you know how to do the job, they'll let you do the job. But offensive security is one of them where if you know how to hack computers properly, they will let you hack computers, as long as you can show to them that you know how to do it. So that's really one of the main benefits to me. And then one of the other benefits is that we have a lot of resources out there to learn offensive security.

Carson:

You know, there's Hack the Box, there's Portswayer Academy, there's different certifications. If you're just getting started, resources exist. If you're wanting to sort of level up your skill set, the resources exist. Even if you want to learn how to do some of the most advanced vulnerability research in the world, certifications and trainings exist. So there's lots of resources online, most of them free, and really all that you have to do is just go do it. If you put in the time, you put in the work, you learn how to do offensive security, then a lot of times you can sort of land these positions without any sort of formal education or anything like that.

John:

Yeah, you just got to put the work in and be disciplined to do it. You know, go after it, but you can work on it. That is a great advantage, I agree, and being able to prove it right. Hey, go prove it to me. And I was curious. One thing too is when you did your interview, did they give you, did they do, a hands-on type part of that? And hey, here's a bunch of code, show us what you can do. Was there anything like that? I know you've been through some. That's like a CTF style for those kind of interviews as well. Hey, here's a CTF, go solve it. But have you also done that for the vulnerability side?

Carson:

So less so for the vulnerability side. I can't really talk about the interview process too much, but I at least, can talk about getting into offensive security and what those interviews look like. And most of the time they do look like CTFs. They look like exactly what you would be doing on Hack the Box or Vulnerable VM or something like that, and most of the time that is the bar. If you start with Hack the Box and you actually learn the fundamentals and you're doing Hack the Box without tutorials or without write ups or things like that, because you have that skill set, then you canlevel penetration testing positions.

Carson:

That is how they sort of weed people out, as they say great, anyone can apply. And here's your CTF, good luck. And we'll talk to you in a week. And you have a week to hack multiple systems, find flags, and if you do it you've got the job. Congratulations, that's all there was to it. And if you don't, you just go back to you know these same platforms where you were learning and you get better. You know you increase your skill set and then you try again because you know there's lots of positions out there like these. And again, most of the time you really just need the skills, you just need to know how to do it think about the focus versus general skills too.

John:

Right, because you could focus on web app for the offensive general security right, not the vulnerability, maybe the vulnerability too. But okay, I'm going to be the best web app focused offensive security person. Or I'm going to be the windows side. I'm going to focus on Linux. Right, and I'm going to focus on Linux right. And I see that and I think there's definitely value to those two Like, hey, maybe we need just a Windows offensive security person and that's what you know, back and forth. I don't know what do you think if you were given guidance, would you say, hey, just be more general first, or pick something and dive deep?

Carson:

Yeah, I would say do what works for you. You know, if you tried network pin testing, you try hack the box and you're doing some network pin testing simulations and you really hate it, or it's just not clicking and you try web app pin testing and you're like this is for me, I love it. Then do web app pin testing. Don't force yourself to do something that you don't enjoy. So really, I think it's just best to do what works for you.

Carson:

I've done sort of a broad generalization of a lot of different things in offensive security and there were some things that I really enjoyed. There's some things that I enjoyed less, but I'm glad that I at least gave all these different aspects a try, because you don't really know. Until you try it out, you try to increase your skill set when it comes to these different aspects of offensive security. So I would definitely say there's no right answer for that. If you love everything about offensive security and you're good at web app pentesting and network pentesting, iot and cloud and vulnerability research, then good job, good for you, really happy for you.

Carson:

Not all of us are as gifted, but you know, if you want to do general, then that's perfectly fine and you will probably succeed, and then if you want to do specific, you definitely sort of narrow your career field options. But it's just as viable a path. And there's not to say that you can't pivot later on. I was a primarily web application penetration tester in the past and I pivoted to vulnerability research because there is a lot of overlap so it's very rare that you actually get locked into one specific field.

John:

Very cool.

Steve:

Did you have any help or assistance along the way, any mentorship, or just did you have someone that you look up to that was kind of helping you get your skills along the way?

Carson:

Is this a loaded question, Steve? Yeah, there was these two guys named steve and john no, no, not at all.

John:

We know we're cool, but after you left us right and you moved on, anybody, that that was, like you know, just guidance, like hey, you know, as you were learning and getting better at this, was was that? Did you have that?

Carson:

yeah, I don't want to make you guys sound too cool, but you guys were pretty integral in at least my foundational knowledge of offensive security and just moving on. So you guys, you get the mention at least once for me, Honorable honorable mention.

Steve:

Thank you. Thank you, that's not where I was going, but thank you. He's fishing, that's okay. No, I got it.

Carson:

I think it was the wink there.

Carson:

But yeah just if we're talking after the facts. There were multiple people who really helped me succeed in my offensive security career path as I moved from position to position to position, and I think that really not to say that these people aren't great, but I think it almost speaks more to the field as well. It's an extremely collaborative field. When I landed my first penetration testing role, I had a buddy, joel, there, and we started on the same day, so naturally there was a little bit of competition. I was like we need to yeah, we need to see who the real penetration tester is here.

Carson:

Unfortunately it was Joel, but the good thing is that he taught me really a lot of the, a lot of the fundamentals, a lot of the skillset, a lot of the things that he knew, and I was able to incorporate that in my skillset and I was able to teach him a couple things as well.

Carson:

So it was really mutually beneficial because we got to share our knowledge, we got to build it, as we were both reading about new research, we were finding out new techniques and it sort of is almost like a force multiplier, because if you're just working by yourself, you're working in a vacuum. Then you can only do as well as you can do, but if you're working with others, then you can do a lot better than that, because you have sort of multiple people working and providing knowledge and skill set and advice, and you definitely can't do that by yourself. So there's been multiple people along the way and, I would say, every single position I've had luckily I haven't been the smartest person there or anywhere close to it, so I have been able to, you know, pick up a lot of different skill sets and build, just because everyone's so willing to collaborate in cybersecurity.

Steve:

That's great to hear because I think people have an idea like you find. You know you see on TV movies, whatever a penetration tester, hacker. You're in a dark room by yourself taking over the world, and you know it's not really always like that. So that's good to hear, yeah.

Carson:

Yeah, I wish. It's rarely a dark room, rarely by yourself. It's usually a well-lit office, sometimes a cafe outside a corporation. You know, with the yagi antenna you just, you just never know well, let's, let's wrap it, let's wrap it up.

John:

It's good. All right, steve, why don't you? Why don't you wrap us?

Steve:

yeah, awesome. Well, carson, thank you so much, man. Just you know, quickly, any final advice for anybody trying to, you know, just take their career to the next level, whether it's offensive security or either just you, you know, trying to dabble in some research, anything at all that you haven't shared already?

Carson:

Yeah. So what I would say is you know the offensive security career path can sometimes be a bit more frightening than you know a standard formal education or something like that, because oftentimes it doesn't require it. But if you're willing to put the effort in, the resources are out there and you know you can make a career out of it. It's. It can be very scary because you know, I know I wouldn't be super comfortable saying I'm going to work really hard on this for a year and then try to get a job. You know that. You know it's a big investment to say that you're going to work on this skill set and you're not really guaranteed anything at the end of it. But you know the resources are out there and if you're willing to put in the efforts, then I think most people will be rewarded.

Steve:

Awesome, great, that's awesome. That's good to hear. I know I have some people ask me all the time, how do I get into pen testing, how do I get into Red Team, and I think this would be a great episode for those individuals to listen to and just hear some of the advice and experience that you have and went through. So appreciate that. But yeah, with that I think we're good, john, anything else for you?

John:

No, thanks again, Carson, thanks for coming back. Thanks for the demo. We will, um, we're going to stand up a uh cybersecurity mentors GitHub page so we can put the code out there, so you can go download the code, follow through with Carson and rewind and watch it again. Right, um and uh, and we'll share his, his information, as we did last time, and you know. Thanks for everybody for checking us out.

Carson:

Great. Thank you, guys.

Steve:

See ya. Thank you for tuning in to today's episode of the Cybersecurity Mentors podcast.

John:

Remember to subscribe to our podcast on your favorite platform so you get all the episodes. Join us next time as we continue to unlock the secrets of cybersecurity mentorship.

Steve:

Do you have questions or topics you'd like us to cover, or do you want to share your journey? Join us on Discord at Cybersecurity Mentors Podcast, and follow us on LinkedIn. We'd love to hear from you. Until next time. I'm John Hoyt and I'm Steve Higuretta.

John:

Thank, you for listening.