[Pranit Garud] (0:00 - 0:31)

Once you are away from the steep learning curve and once you're starting to get the hand of it, then you'll definitely enjoy the output that you get. So that's why it's also the most rewarding and also the most challenging part. There are just two categories in Bug Bounty.

One is first come first serve and second is just focusing on one target, going into the depths, doing some research and end of the day you're finding a zero day in a product. If you want to be someone who is really quick at hunting bugs, you can be someone who can automate a lot of recon process.

[Kyser Clark] (0:31 - 1:47)

Hi, I'm Kyser Clark and welcome to The Hacker's Cache, the show that decrypts the secrets of offensive security one bite at a time. Every week I invite you into the world of ethical hacking by interviewing leading offensive security practitioners. If you are a penetration tester, bug bounty hunter, red teamer, or blue teamer who wants to better understand the modern hacker mindset, whether you are new or experienced, this show is for you.

Thank you for stopping in. My name is Kyser Clark. I have over six years experience in cybersecurity and I currently work as a full time penetration tester, also known as an ethical hacker.

And I'm here to help you grow your cybersecurity and hacking knowledge. Today, I have Pranit Garud, also known as Rootsploit. He has been a security consultant for four years.

He did independent bug bounty for just under seven and a half years and is in the Hall of Fame and 20 plus programs. He was a security engineer for under a half year and has been an offensive security engineer for almost a year now. Last but not least, he is a volunteer at CRIC Learning where he is a security research lead.

So Pranit, thank you so much for stopping in and doing this episode with me. Really do appreciate you taking your time. Go ahead and unpack some of your experience and introduce yourself to the audience.

[Pranit Garud] (1:48 - 2:24)

Hey, firstly, thanks Kyser for inviting me to the podcast. It's an honor. And yeah, I would like to start with my introduction.

So my name is Pranit. I also go by the name Rootsploit. And I have over seven years of experience in offensive security.

I've been doing pen testing, bug bounty, red teaming, and even hardware security for quite some time. And yeah, I also do volunteering work at CRAC, which is a learning platform, which is a non-profit organization. And we try to teach a lot of upcoming students about cybersecurity, teach them about CV, and so on.

[Kyser Clark] (2:24 - 3:07)

Nice. Thank you for introducing yourself. And I'm so excited to talk to you.

I actually forgot to unpack your education certification. It's something I like to do for every guest, so I don't want to skip out on you. So education, Pranit, he has a master's of engineering in cybersecurity and a bachelor's of engineering in computer engineering.

For certifications, he has the Offense Security Certified Professional, that's the OSCP, the CRESS Registered Penetration Tester, that's the CRT. He has completed Dante, which is a Hack the Box Pro Lab. He has AWS Security Fundamentals and the EC Council Certified Ethical Hacker, that's the CEH.

I'm a huge fan of certification, so I got to know more about the CRESS Registered Penetration Tester. So what can you tell me about that and how it compares to maybe like an OSCP?

[Pranit Garud] (3:08 - 3:59)

Yeah, so for CREST, I've only gone through the CPSA route. So CREST is a certification which is mandated in UK. So if you're working as a pen tester for UK, so in my previous organization, I was told to get this certification and I was too lazy to get it at that time.

But yeah, since I had the voucher, I went ahead and did the exam. So if you have OSCP, which is less than three years old, you can directly do the OSCP and CPSA, which is an MCQ-based questionnaire. If you do that, you are granted a CRT equivalence.

So you don't have to go through the practical OSCP type of exam with the CREST. But yeah, if you are working with a lot of UK-based customers or UK-based company, you have to do CREST, especially for government projects or even some private companies require it.

[Kyser Clark] (3:59 - 4:51)

Interesting. Well, thanks for unpacking that because yeah, I never heard of that one. Hey, I wanted to tell you about my new cybersecurity insider list, where you get raw, unfiltered cybersecurity advice, tips, and hot takes, plus exclusive first looks at my content delivered directly to your inbox every single week.

No flow for spam, just valuable content. Head over to Kyserclark.com slash newsletter and level up your cybersecurity knowledge today. Once again, that's Kyserclark.com slash newsletter. There's also a link in the description. All right, now back to the show. So let's go ahead and get a rapid fire questions for those new to the show.

Pranit will have 30 seconds to answer five questions. And if he answers all five questions in 30 seconds, he'll get a bonus six question that's unrelated cybersecurity. So Pranit, are you ready?

[Pranit Garud] (4:52 - 4:54)

Yeah, I'm a bit nervous, but yeah.

[Kyser Clark] (4:55 - 5:06)

Don't be nervous. These are real low threat, low threat here. Your time will start after I finish asking the first question.

So here we go. Do you think cyber insurance is worth it?

[Pranit Garud] (5:07 - 5:08)

Yeah, definitely.

[Kyser Clark] (5:08 - 6:03)

Most challenging part of your job? Learning new things. What operating system is your everyday PC?

Right now it's Mac. Security through obscurity, yay or nay? Sorry, can you repeat?

Security through obscurity, yay or nay? Yay. Most exciting part of your job?

Learning new things. Perfect. That was 29.73 seconds. So you're just there. So congratulations. We're going to go to the bonus question.

So like I said, this is unrelated to cybersecurity. And feel free to explain your response as little or as much as you can. So here is the question.

Who would win in a fight inside a UFC octagon? A silverback gorilla or a polar bear?

[Pranit Garud] (6:06 - 6:15)

I think I would go with a silverback gorilla since I read a lot of core stuff, tiger versus lion and a lot of different animals. I would go with the gorilla.

[Kyser Clark] (6:18 - 7:06)

That's interesting you say that. When I was in the military, we had this debate all the time. And this one guy would always, he was like pro polar bear all day, every day.

And he would be like, the polar bear has like 20 inch knives on each hand, he would destroy the silverback gorilla. And then, yeah, it was a hot topic when he's in the military. That's what we did for fun.

So well, thanks for explaining your explanation on or explaining your response on that one. So yeah, it's just a fun question. So for the regular questions, I think, well, we'll just ask, I asked, what was the most exciting part of your job?

And what was the most challenging part of your job? So let's go ahead and wrap up both. Why is it the most exciting?

And why is learning the most challenging part of your job at the same time?

[Pranit Garud] (7:07 - 8:53)

Yeah, so, like my journey in cybersecurity has been like unique, like as everybody else. So I've been trying to learn a lot of new things, be it blockchain, be it red teaming, be it hardware. So I started in an organization as a security consultant.

And every time there was a new requirement for from customer used to do a lot of research have a lot of freedom allocated, like, you know, a couple of weeks, go through it. So whenever you are trying to learn something in which you had no idea at all, for example, let's say you don't have any formal degree in electronics and telecommunication, but you want to learn about hardware. So your learning curve would be much more steep compared to someone who has already dealing with hardware.

So that is the most challenging part of my job that I think. And let's say even if you're doing a hardware security appendix, you are dealing with a developer or a hardware engineer who knows a lot about the hardware. So a lot of the times when I used to do consulting with, you know, developers, so they was the one who used to point me with, you know, different chips.

For example, if I want to get a UART, I have to find out TX, RX. But at the time, if you don't have a network diagram, a pin diagram for the hardware, it's difficult for you to identify those pins. So at the time, if you have a developer handy with you, it's really, you know, easy to point or, you know, guide you through the hardware.

So, yeah, that's the reason I call it one of the difficult things in my job and also one of the most rewarding. Once you are, you know, away from the steep learning curve and once you're starting to get the hand of it, then you'll definitely enjoy the, you know, output that you get. So that's why it's also the most rewarding and also the most challenging part.

[Kyser Clark] (8:55 - 9:20)

Yeah, I 100% agree. Yeah, same here. You know, everything is fun to learn and it's not easy and it's very challenging to learn at the pace that we have to learn as office security professionals.

So I couldn't agree more with you. So I want to ask about your CRAC learning. You're a volunteer, you're a security reacher there.

So can you explain what the CRAC learning is?

[Pranit Garud] (9:21 - 9:21)

Yeah.

[Kyser Clark] (9:21 - 9:22)

And what your role is?

[Pranit Garud] (9:23 - 10:40)

Yeah, so I'm currently working as a resource lead and also advisor for CRAC learning. So CRAC learning was started by one of my seniors from UMD. Her name is Swati and she basically started this in order to teach all the young people in India and around the globe about cybersecurity.

So people who are just out of high school or just started their engineering, if they want to learn or get a career, will guide them throughout the path. And in this, we also try to give them some practical demos. So during my resource lead, what I did is I picked out some CVs in 2023-2024 and I just went through the POCs, went through the write-ups and I simulated the same environment and I recreated the POCs and then I explained it to each and every student and I asked them to create their own version of the POCs to express certain CVs.

And this way, they get a lot of practical hands-on experience compared to doing a course on Udemy. So yeah, that was our USP, that instead of just going through the course, if an experienced person explains you and guides you throughout the course, it would be definitely helpful.

[Kyser Clark] (10:40 - 10:48)

So is it like a community that other people can join? Like if someone was listening to this podcast, would they be able to join in on that pretty easily and how would they do that?

[Pranit Garud] (10:49 - 11:43)

So they can just go to the CRAC website and on the website, there would be some forms. We also have a Discord channel. I can provide links to that.

If you join it, usually there's a certain time in which we start with, let's say, 20 students at a time and those 20 students would be going through a lot of tracks. So one track is CV analysis, in which I used to lead and I used to go through each CVs. There is also a bug bounty track wherein some students can learn how to do bug bounty hunting, just the basics of recon, and they can report findings on their own on VDP or paid programs.

But that would be like, it won't be like handheld, but it would teach you the basic approach of picking a target, how to do recon on a target, and what are the different OOPS top 10 issues that you can quickly find out on a target.

[Kyser Clark] (11:43 - 12:15)

So one of the things that you are really good at is bug bounty and that 20 plus hall of fame is a very interesting stat to me. And I want to know, so what are some bug bounty tips you can give to people who might have hacking skills but have never participated in a bug bounty program? For example, like myself, I'm a penetration tester full time, but I've never done bug bounty.

So what kind of advice would you give me or someone like me who works full time penetration testing, but also wants to do bug bounty aside and has never done before? What advice could you give for someone just starting out?

[Pranit Garud] (12:16 - 15:18)

Okay, so if you already know a little bit about pen testing, like even someone like you who is a seasoned pen tester, I would recommend that there are just two categories in bug bounty. One is first come first serve, and second is just focusing on one target, going into the depths, doing some research and you know, it's like end of the day, you're finding a zero day in a product. So you have to pick your mindset.

So if you want to be someone who is really quick at, you know, hunting bugs, you can be someone who can automate a lot of recon process or a lot of CV issues. And you can just identify a lot of low hanging issues or maybe even some RCs using that. So you can focus on automation.

But if you're someone who wants to do research and who thoroughly enjoys it, I would recommend that you pick one program, just go through the entire recon data for the program, understand what type of technologies they're using. So a lot of times when I'm hunting on a program, I might have done recon for like weeks, you know, two weeks, I'm running recon, I'm doing, you know, third level, fourth level of subdomain emulation, getting, you know, fresh data from different sources. I've built a lot of automated scripts that I use, which is private.

And I usually, once I get the recon data, I try to map out what actually the organization is using. So let's say if they're using the TO, or if they're using Confluence, based on that, I can get an idea, okay, if their Confluence is vulnerable or not, and so on. So even if, for example, if you pick out a big target, like maybe Yahoo, Mail.ru, so a lot of the times, even if it's saturated, there is high chance that this company has a child company, and they might also have the same stack of softwares. So if you want to go to the automation route, you can do that. And if you are going into the research route, I can recommend that if a company has a GitHub repo, you can go through the code, understand what type of technologies they're using. And a lot of the times, like, I'm not a huge fan of XSS, but just by going through the different technologies they are using, I was able to identify a lot of XSS in, let's say, some rich text editor, or some prototype collisions, just by going through the technologies they're using.

So I would recommend that if you map the target quite effectively, you will find out issues that no other hunters have found. And third most important thing I think is identifying the business logic issues. So if you understand the business logic of a company, it's not just a target, it's not just a domain that you want to do recon.

And so if you just start doing bug bounty, you might get too tired of just running some recon automation, but you actually have no knowledge base about the company. So first identify, let's say, if it is a streaming service, what type of streaming does it does, what type of projects they have on their GitHub, you know, what type of stack they use, do they use Node.js, do they use Django based applications, and so on. So yeah.

[Kyser Clark] (15:20 - 15:38)

Wow, that's a lot of good information there. So what I want to know, so you've done, you know, bug bounty for multiple programs. And so you said stick with one program.

But how do you know how to select a program? And how do you know when it's the right time to switch programs?

[Pranit Garud] (15:40 - 17:57)

So it depends on the interest. So for me, personally, my approach might differ with other hunters. But what I like to do is I first select a program that is responsive.

And if I'm not looking for any cash rewards, I'll straight away jump into the VDP just for practice. Or let's say it's been three months, I've not hunted on anything. I'll just go to some, you know, VDB programs.

But if you're looking for bounties, I'll go for programs that are pretty responsive, maybe managed by the bug bounty platform like HackerOne, BugCrowd. And after that, I'll go through, you know, what are the different findings that are being, you know, published on Hacktivity. So even based on the Hacktivity, I regularly read out Hacktivity is like at least once a day or, you know, once in two days.

So from Hacktivity, even if I don't know a program, but I see, hey, somebody identified XSS using this, I can use that knowledge on some other program. So, you know, that is one tip I can use. And about leaving the program.

So if I am doing recon for like more than two weeks and I still don't understand the company or I understand the company, but I am not too familiar with that stack. Let's say if a company is using AngularJS and I see that input is getting reflected. But if I'm not really good at AngularJS or if there is a WAF, which I'm not too familiar with, bypasses, I might skip it.

Or if I have an event in my collaborators list, I can check out with them. But most of the time, if I'm stuck somewhere, which I feel that it's a dead end, or maybe I have reported some bugs and the company is not responding well, I generally tend to, you know, move to the next target. One more thing that I did as a newbie in bug bounties, I usually went to the security.txt file, identified some VDP programs or just approached the companies without any middlemen, like no bug bounty platform. So that was one thing that I did to get started. I identified a lot of good issues, but the response was not that good. And also, you don't know, they might just ghost you by reading your reports or something.

So that was one mistake I've done. And I would recommend everybody, you know, not to go down that route.

[Kyser Clark] (17:59 - 18:21)

That's good to know. That's good to know. When you say you do, you know, bug bounty, like recon for like two weeks, is that like, are you doing that on the side?

Or is that like your full focus? Because I know you work, you work as a full time office security engineer. So are you still doing bug bounty on the side?

Or like, what's your bug bounty looking like right now?

[Pranit Garud] (18:22 - 18:59)

So right now, I'm not doing anything because of my work. But as soon as I get time, if there are not many challenging areas in my work, if I'm not learning anything new, or even if I'm bored, I might just jump into bug bounty programs. So usually, it's like I might do my full time job.

And once I'm home, I'm relaxed and have some spare time, I'll start hunting. And even if I'm not hunting during my work hours, I might still have some scripts running on my, you know, servers, which would do the recon and end of the day when it's done, I can just review those.

[Kyser Clark] (19:01 - 19:10)

Okay, nice. So what what made you want to go from like being like a full time bug bounty hunter to an office security engineer? Like what made you make that switch?

[Pranit Garud] (19:11 - 19:43)

So initially, it is just because for the stability of the job. And secondly, I had more experience as a security consultant or security engineer compared to bug bounty hunter, I used to do a lot of bug bounty hunting. But I had more passion for learning different things.

So as a bug bounty hunter, my scope might be limited, maybe I can do hardware hacking for, you know, very limited clients. But if I want to do it as a job, I might be more motivated.

[Kyser Clark] (19:45 - 20:34)

I see. Yeah. Yeah, that's that's me for, like, that's why I'm hesitant to get into bug bounty because of the stability aspect of it.

Like you said, that's why I went the full time pen tester route, because bug bounty, it's like you don't get paid unless you actually find something. And like, that's kind of scary to me. You know, I'm so fond of vulnerabilities.

And you know, as a full time pen tester, and I haven't matter of fact, I've haven't had a single pen test where I haven't found something, you know, I mean, I always find something with bug bounty, I feel like it's pretty difficult because there's a lot of other people, you know, submitting, you know, I always hear the dreaded duplicate finding, you know, it's like, that's kind of scary to me, like, you find you think you find something you write up about you send in, they're like, duplicate.

So how do you deal with that? Like, when you when you get back, like, hey, it's a duplicate. Mm hmm.

[Pranit Garud] (20:34 - 21:07)

So if it is duplicate, I'm genuinely happy that at least I was able to, you know, hit the right spot. And end of the day, if you just detach yourself from the, you know, mindset that, hey, I'm a failure, I was not able to find a valid bug, or, hey, this is a duplicate. But if you just detach yourself from that, and just be happy that you know, you were at least able to find something that other top hackers in the world are finding, at least you won't go through the burnout, or you won't suffer much.

So I try to minimize the suffering part, most of it.

[Kyser Clark] (21:08 - 21:25)

That's good advice. Yeah, you're right. Because, you know, you did find something that, you know, like you said, another top hacker found, so you're on the right track.

Is there anything you could do to like mitigate duplicates? Or is it kind of is it is it kind of like a luck thing? Is that a speed thing?

Like, how do you mitigate like the chance of getting a duplicate?

[Pranit Garud] (21:26 - 22:31)

So in case of duplicates, like if I identify something which is pretty obvious, and the program has been on for like long time, like, for example, I don't hunt for like CSRF issues. So that straight away, you know, easy duplicate issue for me. So I personally don't hack for those issues.

But if you're someone who just likes to get some, you know, want to try the luck out, you can do that. Other thing is that even if you're identifying any duplicate issues, I would still identify it on a different module. So even if I found a duplicate issue on a module, I'll try to chain it with some other attacks.

For example, if I found some privesque from low, maybe it's a horizontal privilege escalation. So I'm able to move from one user of same privilege to user B. So I might try to chain that with some self accesses, so that I can, you know, exploit that attack and chain it.

So that is one way to, you know, change the duplicate into something little more impactful.

[Kyser Clark] (22:33 - 24:46)

Nice. Yeah, so I was on a pen test one time. And actually, it was my first web app pen test that I did at my current company.

And I'm getting it, I'm on this web app, right. And I guess they didn't clear the data when they gave us their stage environment. And their stage environment, you could, it was obviously like tested in a bug bounty program, you know, because I didn't see, you know, bug bounty type stuff in there.

And I was thinking, I was like, Oh, my gosh, like, how am I gonna find any vulnerabilities here? This has already been a bug bounty program. Like, I don't know how I'm gonna find something.

And my co worker, you know, I was telling him this stuff. Because we was both because I was helping him with it. Because I guess it was my first pen test.

And I wasn't even already in the company all the way. So I wasn't the main guy for that. And I was like, man, I don't know how we're gonna find anything.

It's already been beat up by the bug bounty program. He was like, Yeah, he's like, Well, I haven't tested it yet. He's like, I'm probably gonna find something to be it may get better if I find something.

And sure enough, he found a high vulnerability to in this app that they didn't know about. I was like, wow, that's really cool. And he changed my whole mentality.

Like just because he got hit with a bug bounty program doesn't mean it's you know, it's been thoroughly tested. So there's always probably something you can find. And yeah, that was really cool to see.

From a full time pen tester perspective. Another thing that happened to me when it came to bug bounty, there was another web app that I did. And I found tons of not tons.

It was I found a good amount of findings, handful of medium findings and a lot of lows, you know, I give them the report. And then during the wrap up call, he was like, he was like, Oh, the bug bounty program, I already knew about all these. And I was like, Oh, my gosh, like, it was like the biggest.

I felt like I was like, Oh, man, I didn't find anything new. I thought I was like, you know, find all this cool stuff. And he's like, Yeah, we already knew about these.

Oh, man. So yeah, that was that was unfortunate. But uh, yeah, it's it's good to talk to some of us on bug bounties.

Because you know, that's a I'd like to get in bug bounties one day. I just haven't had the time. Myself, maybe one day I can find time I'm still a full time cost.

You know, I think once I get down to school, I'm going to spend my time I would spend on school on bug bounty. I think that's one thing I might do. Nice.

[Pranit Garud] (24:47 - 24:51)

Are you doing your master's program or any undergrad? Yeah.

[Kyser Clark] (24:52 - 25:05)

Yeah, I'm currently going for my master's degree in cybersecurity. I'm about about a little over halfway done now. So I graduate in February.

And then we'll see what I do after that. But yeah, I'm always always trying to learn and grow.

[Pranit Garud] (25:06 - 25:07)

Nice.

[Kyser Clark] (25:07 - 25:26)

Good luck for that. Thank you. So as an office security engineer, what are what are you doing day to day?

Like, like, do you do like network stuff? Are you doing like web app stuff? Or is that kind of like a mix of both?

So you're doing social engineering? Tell me about like, you know, everything you're doing as office security engineer right now.

[Pranit Garud] (25:27 - 25:54)

Yeah. So right now I'm doing like a lot of different things like doing some hardware pen testing, and also some red teaming, also some web application testing. And also most of the time, it's like most basic security engineering stuff, like guiding the developers with some security queries or guiding them through the secure HTLC process, doing the code review, pen testing, cloud security, and so on.

[Kyser Clark] (25:55 - 26:13)

Nice. So you are at a fortune 500 company. And I want to know, like, when it comes to, you know, doing your testing and your learning, do you get a lot of say in what you're testing?

Or is it kind of like assigned to you? Like, how much freedom and flexibility do you get to like, choose your projects? So it depends.

[Pranit Garud] (26:13 - 26:57)

Like, I can speak about my org, or maybe like, in general, in any fortune 500 companies, there might be a proactive security team. And there might be a security team who just does tasks on the queue, wherein you have some upcoming queue of projects, and you can work on it just like any consulting firm, or you can just be proactive and pick out some stuff all by yourself, and then identify some issues. And even for like, red teaming, there can be a case in which you have the flexibility to propose a new red teaming on a specific on a specific path that you have, and then you know, work on that path.

[Kyser Clark] (27:00 - 27:10)

Nice. And so are you doing like, are you working only on like your company's technology stack? Or are you doing like consulting stuff as well?

[Pranit Garud] (27:11 - 28:54)

I'm not doing consulting stuff. So for red teaming at fortune 500, it's really different compared to doing it as a consultant. So I have worked as a consultant in the past, and I've done a lot of internal red teaming, external red teaming.

So you do a lot of stuff like doing some phishing attacks, or doing some social engineering attacks. And even for like, onsite attacks, you are permitted to do a lot of things as a vendor. But when you're working in a fortune 500 companies, the process and everything is different.

So you are only allowed to work on a specific areas. But more or less, even if you learn anything that is outside, it might not apply to the company, it always depends on the technologies that they are using internally. So one fortune 500 company might not even be using a technology that you're trying to attack.

For example, if there is a AD based attack, and you're trying to simulate that attack in company A, it might not even be vulnerable, because they are not using a specific service in AD. So you know, and anything that you learn outside, it might not be transferable. But the overall mindset, the process of red teaming, it stays the same that you do some recon, then you identify the high value target in the particular org, it might be external or internal, and you find a path in which you can simulate the external adversaries.

And if you say if the path is achievable or not. So the overall process for red teaming is seen, but the technicalities in which we perform the actual red team, it might differ from you know, all the fortune 500s, they have different you know, network stack. So it might differ.

[Kyser Clark] (28:56 - 29:10)

Okay, so it kind of sounds like there's like a lot of like, limitations on what you can do kind of like a lot of red tape, right? You don't get a lot of like, you got it, you got to purchase things like in a structured way, compared to consulting? Is that is that accurate?

[Pranit Garud] (29:10 - 29:55)

Yeah, yeah, it's it's a lot structured compared to consulting. In consulting, you are just, you know, held by held back by your manager. But if your manager says, hey, go ahead and you know, hack everything, you can do anything.

But it's not the same in fortune 500. Since the stakes are, you know, pretty high. So the approval process and everything differs in fortune 500.

And also that you yourself are aware that if anything goes wrong, as a red teamer, if one server goes down, I know, I'm going to be blamed on Twitter, you know, it's going to be a big mess. It's not going to be just org level, you know, issue, it would be a worldwide issue. So that's the reason I don't want to mess around.

[Kyser Clark] (29:56 - 30:30)

Yeah, yeah, worldwide issue. That makes that makes a lot of sense. Yeah.

Could you imagine it like the CrowdStrike thing, you know, like, you really mess with the whole world. One guy pushed the wrong patch. And it's like, you know, world's biggest outage.

So yeah, yeah, I never thought of it that way. It's like working for a huge company like that. But that absolutely makes sense.

So would you say since since you got to be more careful, you know, working for a fortune 500 company, compared to consulting, would you say that the pace at which at which you work is slower than consulting?

[Pranit Garud] (30:32 - 32:12)

Yeah, more or less, it's slower. So whenever you're working as a vendor for any company, you have to do certain tasks, let's say one pen test might be just for one week, second week would be for reporting. But since you are an employee, you have a lot of different things you can check, you know, as a vendor, you might not be able to go through the source code or, you know, different things.

But it's really about having a close tight relationship with the developer. Because if you don't understand what the developer is doing on his day to day job on a specific product, you won't be able to secure it completely. So even if, for example, if you go in any fortune 500 company and you assess the work done by vendors, you might think, hey, I could have done a better job.

But if you are being really fair to yourself, you can think, hey, vendor might have limited access. He doesn't know the entire application. Since I'm an internal user, I know how the app works in real life internally.

So that's the difference. When you're a security engineer, you have to think from a different mindset, you have to shift left, wherein you have to go through the developer's mindset, understand why they're not able to fix it. And, you know, as a vendor, you just send out the report and you say, yeah, fix it.

But as a security engineer, you have to think, hey, how can I help them fix it? Sometimes there might be genuine issues that, hey, they are not able to turn on certain service because of policy. They can't use this tool.

Now you have to find an alternative library, which the org approves and so on. So it's a tedious process. But, yeah, in the long run, you might create more impact than just a pen test as a security engineer.

[Kyser Clark] (32:14 - 33:33)

That's nice to know. Yeah. As a consultant penetration tester, I definitely don't work with developers closely.

I'll talk to a developer maybe, sometimes I don't even do that during a kickoff call and then maybe during a wrap call. But like you said, yeah, it's exactly like that. I find a vulnerability, I put in a report, and I'm like, here, fix this.

And then that's it, you know? And it's like, I don't really, you know, I'm only going to write like, you know, a page worth of stuff on that one finding. You know, it's not like it's like super in depth.

Like, I'll do my best to explain how to fix it and, you know, what the problem is. But at the end of the day, like, it's just like a one page, maybe two, depending on what it is. And then if they have any questions about during a wrap up call, I'll dive deeper.

But typically, they don't even ask for, you know, to go dive deeper on it, mostly because I feel like, you know, I feel like if they don't ask me questions, and I did a good job writing about it. So that's always good to know. But yeah, like you said, I don't work with developers that closely.

So that's interesting, though, because I've never been into, you know, working as an office security engineer slash internal penetration tester like you're doing now. What are the biggest pros from switching over from consulting to what you're doing now? And what are some of the biggest cons?

[Pranit Garud] (33:33 - 35:08)

Yeah, so for benefit, I would like to say that you get to see what's behind the curtains, you just don't see the play, you actually know how it works, who runs the play, how are the approvals going on in development and how you can create a maximum impact. So from career growth point of view, like if you think from a CISOs or people who are in much technical position, or much higher position, a security engineer is able to create more impact than a pen tester. So that is one pro I can think of, I think.

And one con that I can think of is as a pen tester, you can just go all in like, you know, do your offensive stuff. As a security engineer, even though you can hack into something and destroy something, you have to hold back. And it's not that you're holding back.

For example, if you can just exploit RCE and, you know, gain some cookies, do some stuff, you know, gains escalated into the cloud, you know, you can do it. But as a security engineer, I won't be wasting my time on chaining the attack, I would rather show the impact. Or maybe I can just ask the developer to, hey, can you show the files on the server?

Hey, is there this file on the server? If yes, then I can go ahead and raise some issues and see how we can fix it rather than, hey, how I can exploit it and go deeper. Because that is pretty much irrelevant at this point.

Because I'm working as an internal security engineer. So I want to secure it rather than, hey, look, I found this particular attack. So yeah.

[Kyser Clark] (35:09 - 35:32)

Interesting. Yeah. I didn't really think about that, how you would be focusing less on exploiting findings.

So that's good to know. That's really good information to know. I didn't know that.

We are running out of time. So let's go ahead and go to our final question. And this is the question everyone gets asked.

So do you have any additional cybersecurity hot takes or hidden wisdom you would like to share to the audience?

[Pranit Garud] (35:33 - 36:22)

I think hot takes, I would like to think that whether you are working on any of the subcategories of the cybersecurity, I would like to see that you should be more about going into the mindset rather than learning the technicalities. So if I want to dive deep onto this point is, for example, if I'm doing pen testing versus if I'm doing bug bounty hunting, the type of issues that I report as a pen tester is, you know, it's a world apart from what I report as a bug bounty hunter. I can't report something related to cookie session in a bug bounty hacking.

Right. So that is the mindset you create. And right from the start of your engagement, if you know what type of mindset is required for this engagement, you will definitely succeed in that.

[Kyser Clark] (36:23 - 36:32)

Thank you for the advice and the wisdom. I really do appreciate that. So Pranit, where can the audience get a hold of you if they want to connect with you?

What's the best place?

[Pranit Garud] (36:32 - 36:40)

So you can connect with me on Twitter. My username is Rootsploit. And also you can find me on LinkedIn.

My name is Pranit Karur.

[Kyser Clark] (36:41 - 37:18)

Perfect. And I will put links to your LinkedIn on in the show notes. And the audience, the best place to get a hold of me is also LinkedIn and my website Kyserclark.com.

Audience, if you enjoyed this episode, if you want to support the show, the best way to support the show is to leave a five star review. If you're on Apple Podcasts or Spotify, if you're on YouTube, hit the like button, hit the subscribe button if you haven't already and drop a comment. Thank you so much for watching.

Thanks for listening. And I will see you in the next episode. Until then, peace out.

Take care. Have a good one. Kyser out.