Bug Hunting from the Beach with Brad Schlintz

Nic Fillingham: Since 2005, BlueHat has been where the security research community and Microsoft come together as peers.

Wendy Zenone: To debate and discuss, share and challenge, celebrate and learn.

Nic Fillingham: On the BlueHat podcast, join me, Nic Fillingham.

Wendy Zenone: And me, Wendy Zenone, for conversations with researchers, responders, and industry leaders, both inside and outside of Microsoft.

Nic Fillingham: Working to secure the planet's technology and create a safer world for all.

Wendy Zenone: And now, on with the BlueHat Podcast. [ Music ] Welcome to the BlueHat Podcast. We have Brad Schlintz with us today, where we're going to discuss his research and also how he qualified for the upcoming Zero Day Quest that is happening on April 1st through the 3rd. Brad, go ahead and introduce yourself.

Brad Schlintz: Hello, everybody. Thanks for having me on. Yeah, so, my name is Brad Schlintz. I'm an Independent Security Researcher and Bug Bounty Hunter. For the last three years, I've been traveling with my wife around the world. I started doing bug bounty about two years ago as a means to fund our adventures. Before traveling, I was a software engineer for about a decade and today, I'm primarily focused on hacking Microsoft products and services and talking to you from a beautiful island in Brazil.

Wendy Zenone: Oh, man, I want to be there.

Nic Fillingham: Tell us more about that.

Wendy Zenone: Yeah.

Nic Fillingham: Beautiful island in Brazil, like, you know, don't -- you don't have to dox yourself, but what do you see out the window right now? Where -- what's this beautiful part of the world you're in?

Brad Schlintz: So, there are -- there are dozens of beautiful beaches here. We picked this place because it has lots of hiking trails and lots of nature. So, we -- my wife and I love this stuff and so this was a perfect place to base ourselves for a few months.

Nic Fillingham: It sounds like you're living a lifestyle that many people would dream of, being able to sort of, you know, hike during the day or at night, I guess, and your submissions are earning bounties and you're using that to travel the world and visit beautiful places.

Brad Schlintz: Yeah, it's been amazing. It started two years ago, kind of working on public programs on HackerOne and Bugcrowd, and eventually kind of transitioned to working on the Microsoft platform. It was sort of a natural fit for me because I have worked within the Microsoft ecosystem for about a decade before this and so it was just the perfect kind of fit. And bug bounty was always one of those things I heard of a few years ago and it just sounded incredible. It just sounded like, you know, companies just open their door up for security researchers to show up and try to hack their systems and if you find something, report it, and you can earn a bounty for it. So, it just, it sounded awesome. And, you know, as we started traveling, it just seemed like the perfect fit. It's something I could do from anywhere in the world at any time of the day, and if I wanted to take a week or a month off, I could. I could just disappear and go travel. So, it's -- it really seemed like the right fit for me.

Wendy Zenone: Man, I need to learn how to do this. This sounds way better [Brief laughter]. Just -- so, your background as a software engineer, you know how the whole thing works from back end to front end. What was your first foray into hacking? Like, there was just a day you're, like, "Hey, I've heard of HackerOne, you know, let me just look at this platform. Oh, this is cool, this scope looks good." I mean, what did that look like to get to where you're at now?

Brad Schlintz: Yeah. I mean, I'll take a kind of a step back. I think it -- my kind of spark in this started as a teenager. I convinced my parents to buy my first computer for me off of Craigslist so I could do homework. It was a Windows 95 Dell desktop machine, and I didn't really use it for homework.

Wendy Zenone: I was going to say, is that like air quotes, "homework?"

Brad Schlintz: Yeah, definitely. I definitely used it more to play video games.

Wendy Zenone: Right.

Brad Schlintz: That's kind of also where my first experience with hacking started. So, I started playing a video game called the RuneScape, and I noticed that other players in the game were kind of in autopilot or what seemed to be autopilot, and repetitive calculated movements, and they wouldn't really talk or engage. And so, this got me curious what they were doing and how they were doing it. So, I ended up finding the game client they were using and sort of reverse engineered what they were doing and realized that they were running certain scripts to automate their game for them. And so, they would create these bot farms basically to harvest resources and whatnot. And so reverse engineering this, I was able to rebuild it for my own use and had my own little army of bots to play the game for me on our dial up connection, and eventually got banned from the game, rightfully so. And, but I later realized that those scripts were actually Java. They were written in Java programming language. And so, this was actually my first time kind of coding and seeing how technology worked.

Wendy Zenone: Wow. It always starts with the video games. That seems to be a common origin story. It starts with begging parents for a computer and then the video game.

Brad Schlintz: Yes, definitely. Yeah, so, it kind of continued from there. It kind of started there and that kind of sparked the interest, so I went to school for computer science and then got my first job as a web developer intern. This was -- I showed up the first day on the job and my boss put down a SharePoint Server 2007 development book on my desk and said, "You're going to be a SharePoint developer." So, I kind of grew into that role. It was a lot of like C sharp and ASP.NET development. I eventually moved into more of a SysAdmin role there and began managing the SharePoint server farms, learning things like databases, networking, DNS, Active Directory, PowerShell. Eventually kind of stuck with SharePoint and moved on to an IT consulting firm. In that place, I did a lot of like Office 365 type of development projects and really started focusing on client side development using JavaScript. Also in that job, I kind of really focused in on customer service and communication skills. Just being a consultant, I had to work and go on-site with clients a lot, and so that really kind of boosted my confidence and ability to speak to business professionals.

Wendy Zenone: That's huge.

Brad Schlintz: Yeah, definitely. It was -- it has come in handy many times later in my career. So, yeah, after that, I ended up joining Microsoft back in 2018 as a Premier Field Engineer and continued with SharePoint development. A big part of my job there was helping customers fix their slower broken intranets. So, I was the guy that was brought in when everything was on fire, and they needed to figure out, you know, why their intranet was crashing. And so typically, it was diagnosing the code that was running on the page, figuring out why it was slow or causing their tenant to be throttled, and helping their engineering teams get it fixed so that way they could get back online. And so sometimes this was very tense moments, as you can imagine, with some of Microsoft's biggest customers. After that, I would say I moved off to join Azure.com, the engineering team, and worked on the Azure pricing calculator, which is a very front end heavy development app. That was interesting and ultimately quit that in December of 2021 to start traveling in January of '22.

Wendy Zenone: I'm so jealous about the traveling part [Brief laughter].

Brad Schlintz: Yeah.

Nic Fillingham: So, Brad, was there a moment there when you sort of got your first little whiff, hint of this idea of sort of security vulnerabilities or maybe, you know, broken business logic or things when maybe you're -- when you're in the consulting space or being sort of a field engineer, were you starting to see not just opportunities to increase sort of performance and maybe efficiency, but were you also seeing like, this may actually not be secure, or this thing's leaking credentials, or I can -- I can this thing that I, you know, I shouldn't be able to from the public? Like, was there an "aha" moment or little breadcrumbs that sort of come to mind for how you started to think maybe a bit more like a hacker? Security researcher, I should say.

Brad Schlintz: Sure. The first cybersecurity incident that comes to mind was actually from my first job a couple years into my career. I was called late on a Friday night. I was out to dinner with my girlfriend at the time. My boss had asked me to jump on the computer and help something. So, the public internet or the public website for the company had been defaced by a hacker and malware was attached to it. And so, anybody who visited the public website homepage would be affected by this. And so, at the time, I had no background in security. I was a web developer, but that was it. And basically, what they had me do was we needed to get rid of the vulnerable system. And so, the backend system was built in ColdFusion, which is a really old technology, but the attackers actually got in through a SQL injection vulnerability. And so, we didn't know exactly where the server was hosted at the time. It was sort of there's lots of transition and things like that, so it was just kind of a, you know, nobody really knew what was going on. So, I took it upon myself to just turn the system into a static website and, you know, eliminated the malware and just -- so it's just a basic HTML, CSS, JavaScript website, no backend server side component to it and that ended up staying that way for a couple years. So, that was really my -- kind of my first introduction to cybersecurity.

Nic Fillingham: You're an EMT, it's like, "Oh, my gosh, the site's been defaced. We need to, you know, obviously get the site un-defaced, get it back to normal and remove this malware." Your solution there was to, as you say, turn it to a static page and sort of remove some of the more active elements to it. Is that correct?

Brad Schlintz: That's correct. Yeah, the website was fairly basic, it only had maybe 20 or 30 pages on it to begin with, so it was fairly small already. The only dynamic components were maybe news and events and so it was fairly easy to turn it into a static website and just maintain those events and news ourselves for a while.

Nic Fillingham: Got it. So, that was one of your first, as you say, sort of first little forays into the world of cybersecurity. How do you then jump into being an independent security researcher? You know, you talked about taking some time off to travel after leaving Microsoft, what was the sequence of events that got you into the security research space more full time?

Brad Schlintz: Yeah, so after the first trip that we took, that was about thirteen months, where we backpacked from Mexico to Panama. After that trip, we came back home, and we didn't want to stop traveling. We were just hooked. We weren't sure how we were going to pull it off, but we were hooked and so, we needed to kind of find a way to keep going. And I always had an interest in cybersecurity. I listened to the Darknet Diaries podcast by Jack Rhysider and just loved hearing the stories of these various incidents and hacks, as they would unfold and so, I always had a curiosity about this. When I was working as a software engineer, it didn't really make sense at the time to look into bug bounty. It just, that was sort of, it was my job, but after traveling, I had a lot of time to think on the road and I decided, you know, when we were trying to figure out what to do next, hey, this is something I want to give a try. I want to try bug bounty. And so, at that point, I kind of shifted my focus from being a software engineer to being more of a hacker and security researcher.

Wendy Zenone: I want to know a little bit more about the travel? I mean, yes, we'll go back to hacking, but you came back, decided -- I mean, I can see that, you know, you take that much time off, you guys are -- you're all traveling for eighteen months. Like, coming back is probably just the most depressing thing ever, you know? Then you decided just, let's do it again. Where have you been?

Brad Schlintz: Yeah, so, that first trip, we focused kind of in Central America. We came home and we decided to do Turkey next, so we spent a few months in Turkey. And then from there, we were going to explore more of Eastern Europe, but we ended up totally changing and we flew to Bangkok from there and traveled around Southeast Asia for about seven months and hit every country over there, for the most part. And then from there, we came back home, spent a few months with family, and now we're traveling around South America. And so, we're about halfway through the continent and currently in Brazil.

Wendy Zenone: Amazing. What has been your favorite country so far, to date? You probably have more to do.

Brad Schlintz: Favorite country, definitely Thailand.

Wendy Zenone: Really?

Brad Schlintz: Thailand is at the top of my list because of the friendly people, delicious food, the cultural traditions are beautiful, the nature and the scuba diving and beaches are beautiful, so we just fell in love with that place. We spent two months there and it wasn't enough.

Wendy Zenone: Oh, man, that sounds amazing. So, while you're traveling, you know, there's different time zones, there's Wi-Fi connection issues, there's all those things. How hard or easy has it been for you to maintain your hacking cadence while dealing with some of these maybe hiccups, maybe not? I'm sure there are some areas you've been to, you're, like, hey, that country, amazing Wi-Fi, amazing amenities and maybe others not so much, so how are you balancing that?

Brad Schlintz: Yeah, I think surprisingly we've had good internet almost everywhere we've been. There has been a few cases where the internet was less than ideal, but for the most part, it's been pretty stable. I think a bigger issue usually is noise. So, we're renting apartments in local neighborhoods for one, two, or three months at a time and so oftentimes, we're there long enough where there's construction projects that happen. And so, the floor above us will have, you know, hammering and stuff all day long and so sometimes we have to escape and go to a cafe or something. But for the most part, we usually try to get apartments, so that way we can kind of set up base and then from there, you know, nights and weekends, and we take a few days, go do the touristy things in the location that we're at, but and then I try to hack in between. So, I usually try to hack for at least three to five days in a row to kind of build some momentum and to really get into something.

Wendy Zenone: Man, you be -- you'd be writing a book. This is a great adventure.

Brad Schlintz: Some days it feels like it's a story and it doesn't feel real. I have to pinch myself a lot in this. It's been a very humbling and beautiful thing that bug bounty is even a thing that we can travel the way we can with today's modern technology. It's I really feel lucky to be able to do this.

Wendy Zenone: Yeah, I bet.

Nic Fillingham: What areas do you find yourself focusing on right now? Whether it's products and platforms and technologies or specific sort of classes of bugs, have you found yourself sort of narrowing down into little subsets or little avenues that are really now sort of your wheelhouse, you're really comfortable and you're able to go and find stuff sort of, I won't say easily, but you've got some processes and some motions, and you can just jump straight in?

Brad Schlintz: Yes. I would say, you know, the first six months of bug bounty, I kind of tried everything, right? I learned about every sort of bug class and was trying everything all the time everywhere. And I learned quickly that wasn't a recipe of success for me. So, for me, what I realized is that I'd stopped at around the six month mark and took a pause to evaluate what has worked for me and what hasn't. And what I realized is that the bugs that I was having the most fun trying to find and trying to exploit, aligned with my existing skill set. So, previously, I was a software engineer and so I focused a lot on building websites, building APIs, working with Windows environments, that sort of thing. And so, most of the bugs I had found to date were XSS, you know, Cross-Site Scripting bugs, or Server-Side Request Forgery bugs, SSRFs and I decided to kind of really focus on that. And so that kind of aligned about when I started hacking on the Microsoft system as well and I really focused primarily on XSS and SSRFs. And now I feel like when I show up at an app, I can kind of get a sixth sense almost and kind of just, you know, get a sense of whether or not the app might be vulnerable based on its integrations or based on the behavior of the pages. And so that's kind of what I've leaned into now and I would say over the past two years of doing bug bounty, I would say at least 90 or 95% of my submissions have been either XSS or SSRFs.

Wendy Zenone: And it doesn't sound like it's, you know, from hearing your history and I mean, I don't think AI is anyone's specialty. It's so new. It's so green. It's a wide open space that everyone's just trying to figure out at this point. So, being that you've dabbled in it a little bit, what are your thoughts on that? Just for folks that are listening that are just, like, I don't even know where to even begin with looking into AI, you know. In your small amount of looking into it, what are your thoughts around hacking AI?

Brad Schlintz: I think it's very fascinating. It sort of feels like when, you know, like the dot com era, right, when things were changing so quickly, it feels like another paradigm shift with the advent of AI. So, you know, I'm not sure where it's going to go from here, and I don't think anybody does, but it's interesting that there's some very, very glaring vulnerabilities like prompt injection, you know, that we still have a hard time solving from a security perspective. And so, you know, I think over time, guardrails will get built and put in place that'll make that easier to eliminate that vulnerability class. So, you know, I'm not sure. I think also companies are going to be using AI more on the defensive side and offensive side to kind of help with this as well. And not just for AI related vulnerabilities, but to just secure their systems, I think we're going to see more of that in the future.

Nic Fillingham: Yeah. So, Brad, you are going to be pausing your global travels and your remote island based hacking adventures to come and visit us in Redmond in April for the Zero Day Quest challenge, which is very exciting.

Wendy Zenone: Tropical Redmond [Brief laughter].

Nic Fillingham: Yeah, tropical Redmond. Exciting for us. Hopefully exciting for you as well. Did you specifically go and look for some bugs to submit in order to be a part of the Zero Day Quest challenge? Or were you just doing your thing and it just so happened that your submissions that you were -- that you submitted into MSRC sort of fell within that Zero Day Quest window of qualification? And in relation to that question, what can you tell us about the cases that you have submitted that were a part of the Zero Day Quest?

Brad Schlintz: Absolutely. I was very excited. I had received an e-mail back in November saying that I had been invited to this live hacking event, the Zero Day Quest up in Redmond and I couldn't believe it. I didn't ever expect that Microsoft was going to put on a live hacking event. This would be my first time ever attending one and so, it was very exciting to receive that e-mail. I guess I'm most looking forward to kind of meeting some other researchers and engaging with MSRC, seeing potentially what new bounty scope opens up for the event and racking up some bounties.

Nic Fillingham: Awesome. And then what can you tell us about some of those cases that sort of fell within the qualification period? Even though you got that e-mail back in November, but, yeah.

Brad Schlintz: Yeah, so I think my biggest bug to date I found during the Zero Day Quest. This particular vulnerability affected Dynamics 365 sales, and I just found it by exploring features in the app. And so, yeah, this was by far my biggest bug to date in terms of severity as well as bounty award and was eventually issued a CVE as well. So, it was very, very exciting.

Wendy Zenone: Did you go out and celebrate?

Brad Schlintz: So, I found out when we were in Uruguay and we were out having lunch, my wife and I were having lunch and it -- we were sitting at the table and I -- my phone buzzed and like I saw the e-mail and I just, my jaw hit the table and my wife was concerned, like, what happened? I was like, I just got a $30,000 bounty. This was incredible.

Wendy Zenone: Yeah. That's amazing. So, this is your first massive hacking event. It's actually mine too. I've heard of them, I know that they exist, and I was so excited to be part of this. I love that you don't have any expectations because we've had other folks on here that's like, "I've been to one, so I'm seeing how this compares." It's like, I like that this is the first for you, so I'm hoping that it exceeds expectations for you.

Brad Schlintz: Brad, related to that case you were telling us about, what was different about this one? So, I actually can see some of your submission history here. And first of all, you are prolific, sir. In less than I think two years, it looks like you've submitted over a hundred cases or somewhere around that, which is just incredible. Thank you.

Nic Fillingham: A lot of those were cased. A lot of those also earned a bounty, which is incredible. But what was it, if you can sort of think back to that process and think back to all the little things that were popping up for you as you were exploring this particular product and this feature and how things were working, what was it that was sort of different? And I'm really thinking more in terms of guidance that you could perhaps share with other researchers and hackers out there. Like, how do you help folks, you know, sniff out these avenues and opportunities to go and explore, given that, you know, you can go in so many different directions?

Brad Schlintz: Yeah, so when I start looking at an app, I typically look for integrations. Integrations, I've found more often than not, can kind of be exploited in different ways and so, in this particular case, I discovered that there was an integration between Dynamics and Azure storage accounts. And so, immediately this triggered my brain to say, "Okay, let's see how this integration is configured? How is this set up?" So, that's kind of, in this particular case, how I got started on that track. And I would say just in general, you know, advice to give other researchers, focus on the integrations, whether you're searching on an AI program or Dynamics or SharePoint or OneDrive or Windows or anything, you know, really hone in on those integrations and see what identifiers are in place that link the two things together and see if you can intercept that.

Nic Fillingham: That's incredible advice. So, you're looking for -- and I think some people might say the seams, but you're looking for the -- where does one system talk to a different system and how do they talk to each other? And then what is information you shared backwards and forwards? And then how do you potentially start to sort of manipulate that and look for areas where you can get it to do things that it's not meant to do? We should pause here and just clarify that this bug has been resolved.

Brad Schlintz: Yes, this bug has been resolved. It was fixed in December of last year.

Nic Fillingham: Excellent. So, people listening to this podcast, don't go and try and poke around on this one. I guess you can if you want because it's been resolved, but, yes, this is a bug that has been fixed. And then, you know, again, you don't know what's happening at Zero Day Quest, it hasn't been, you know, disclosed yet. Perhaps by the time this episode is aired, you might have some new information, Brad and we'll find out. But do you think that approach of looking for the seams, looking for the integrations and the connection points, that's something that you -- that's sort of a skill and a technique that you're going to hopefully bring to Zero Day Quest and sort of the on-site hacking? You're going to -- you're going to look for where does one system talk to another and how does it talk, you know, how can we intercept that and maybe do some fun things with it?

Brad Schlintz: Absolutely. Yeah, I would say, you know, even a lot of the SSRFs and XSS bugs, the same applies to both, it's integrations. So, oftentimes on the XSS side as well, it's two websites that are trying to talk to each other, but you should be asking, how do they validate each other? How do they trust each other? What mechanism is used to ensure that it is who they say they are? The one that, you know, the other website that's trying to communicate across maybe these different iframes or something, so it's typically the integrations is where I find a lot of the bugs. That's not always the case. Of course, there's some that are just inherent to a specific product. Maybe something was designed poorly or coded poorly, or just a particular edge case wasn't thought of, but more often than not, it is the integrations.

Wendy Zenone: I know we've heard before that I think just in our last podcast, we realized that, you know, you always -- people always ask, "How do you get started?" And you think you just start from nothing, but learning that, you know, poking around something usually leads to another thing, leads to another thing, leads to another thing. So, do you ever have that where you find one, what whatever that one is, a vulnerability, and let's say it's, you know, you submit it, it gets fixed, but then you're like, I'm going to go back, you know, kind of like Nic was talking about, you know, feel free to poke around, but it's been fixed. And you've gone back and found, okay, wait, there's actually another layer to this that I didn't realize before. So, you don't just start at zero, you kind of just build upon what you've already found, or other people have found?

Brad Schlintz: Yeah, absolutely. Yeah, if there's one bug, there's probably more than one bug, that's typically what I've found. And usually I'll find one, really try to understand it, don't immediately submit it right away. I'll kind of spend the time to circle that bug to figure out what other pages, what other functionality, what other features are nearby. Maybe the exploit could be made simpler if I just understand the bug better. Otherwise, you know, if I just start with, okay, I've got this XSS, okay, how do I make this thing to report? Sometimes you might have to jump through a lot of hoops to find the companion exploit, maybe to leak an authentication token where you wouldn't have to work so hard. Maybe the -- maybe it's built in and it's right there. And so, I found that many times where, you know, I'll start kind of hacking on something and there's usually, it depends on the page, but a given page, you know, if I find one maybe post message handler that's weak, I'll keep looking. Perhaps there's other query parameters that activate other handlers on the page and etcetera, right? So, it's easy to kind of keep going and pull out a bunch of bugs from one spot.

Nic Fillingham: So, Brad, one thing that we hear from successful prolific researchers that are submitting to MSRC and are having lots of cases accepted and also securing bounty awards, is that they start to develop sort of some really good habits with the reports that they write, and they submit. And a lot of the times, you know, they'll tell us that, "Oh, my gosh, that first report that I ever submitted to MSRC was terrible. It had very little information in it, and I didn't know what to say and I didn't say enough. And, you know, they just came back to me with 25 questions." And then as you sort of learn the process, and you learn what's required, you start to include more information and all that kind of stuff. And so, I guess, could you share when you think about documenting what you have found, in order to submit it as a report, whether it's to MSRC or whether it's to, you know, any other sort of bug bounty program, what are some of the things that you do? And that again, that you would sort of recommend others consider when they are documenting their findings in their process?

Brad Schlintz: Yeah, so, always with reports, I make sure to include several screenshots, you know, and annotated screenshots describing clearly what you're seeing as a bounty hunter. Don't just take a screenshot of the code, but annotate it and say, "Okay, this means this, and this other thing means that, and these two connect together by this other thing." So, screenshots are very helpful. I always include videos as well. I -- for a while, I would stop doing videos and then I would start doing videos because it takes a lot of time to kind of set up the reproduction and the exploit in such a way that you can create a concise video, but I found more times than not that it always is to your benefit. When you include a video, if you forget to include something in the report, the video may show or demonstrate the step that you forgot to write and so, it's always important to have that video. In terms of the actual report itself, I would say, you know, spend the time creating a brief summary, so that way somebody who's coming along can just quickly grok them say, okay, because in three sentences, this is what this report is, spend the time to dump out everything you know. Do a full brain dump with like a description of the vulnerability and everything that you can find about it. And then I always include, you know, what the expected result was versus what the actual result was, right, that you've come across. So, that typically applies to almost any type of vulnerability. I usually spend the time to figure out what the exploitability of this particular bug is. You know, is it something that is very niche and almost impossible to exploit or is it just one click of a link and you're, you know, you're in? And then I usually take the time to provide some remediation steps. You know, I think maybe just because I have a background in software engineering, I kind of can see what went wrong and try to provide some advice there. I think even just being a bug bounty hunter long enough, you'll start to kind of pick that up. Even if you don't have an engineering background, it's sort of you'll start to see what you need to do there. And then, of course, the actual steps themselves, make them clear and concise, make sure you include everything. And, you know, usually what I'll do is I'll write the whole report up and then I'll go to bed. The next morning, I'll have a cup of coffee, I'll read the report again, make sure, you know, you didn't miss anything, you didn't miss a certain thing. So, what I found sometimes is that I'll leave out a detail. Like one example that comes to mind is a particular vulnerability only affected Dynamics 365 sales and so I forgot to say, "You need to use a sales tenant for this. You can't just use any old Dynamics tenant for it." And it ended up coming back where the triager came back and asked the question, "Hey, I can't reproduce your bug." And I said, "Oh yeah, I forgot, I didn't include the sales part." So, it's important to make sure you get all of that in there and I think, you know, over time, I just, I try to answer all of the questions that a triager would ask before they've asked them. That makes my life easier as a bounty hunter, so I don't have to go back to old reports and try to figure out what went wrong here. And it makes the triager's life easier. They can more quickly reproduce the report, and it makes the payouts easier. The whole process goes much quicker by just taking the extra time at the beginning to write a good report.

Nic Fillingham: That's amazing advice. Two things that I just want to point out that I love that you said. One was put yourself in the shoes of the triager and read what you would be submitting here and see what questions they may have. That's great advice. The other thing that you mentioned too, which I thought was really interesting, was providing, "Hey, here's what I did. Here's what I expected to have happened, but here's what actually happened." And I think, instead of just saying, "I did X and I got Y," I think saying, "I did X, I expected foo, but instead I got bar," I think that's also a really important step to include there too, because it also shows that you also sort of know what's going on with that product, with that technology, with that service, and sort of how it functions so that you did this thing, you thought it was going to do this, but it did this thing instead. That feels like an also important step to highlight. This is great advice. Thank you so much, Brad.

Brad Schlintz: Absolutely. Yeah, it really demonstrates that you took the time to understand the product or the feature. And so, I think, you know, from the person who's receiving the report, I think that's helpful to them and ultimately to the engineer who has to fix that bug. I think having all of these put together, it really kind of helps streamline that whole process.

Wendy Zenone: You submitted to a few different bug bounty programs, and you also highlighted how previously when you weren't a full time bounty hunter, you were in the technical side, but also highlighted how important soft skills are, which I'm sure helps with your reports. But from the researcher side of things, what makes a good bug bounty program? Obviously, ours is the best, but I mean, you know, you know. You know because you're interacting with humans. There's the technical component, but there's also the human side of things, so from your perspective, what makes a good program? What makes a good relationship for the researcher and the bounty team?

Brad Schlintz: In my experience, it's having an open door communication with the bounty team themselves. With MSRC, I've had a lot of good interaction, I would say. You know, inevitably you're going to run into situations where you're going to have duplicate submissions. You're going to have cases closed as out of scope or NA, things like that and that's just part of the game of bug bounty. But typically, whenever I've had issues working with Microsoft, I'll, you know, explain my side, I'll provide evidence, you know, saying, "Hey, I don't believe these are duplicates." And I would say 80% of the time or 90% of the time, it gets resolved fairly. So, you know, either it does award a bounty, as I thought it should have, or, you know, it's like, okay, yeah, I was wrong on this one and it doesn't deserve a bounty. So, I think it's just having a fair and honest open dialogue. You're on the same team, you know, and really be on the same team. You know, it's not just, I'm on the outside trying to get bounties, we're both trying to secure this thing and I think it's really behaving as if you were on the team.

Wendy Zenone: Yeah, I totally agree. Years ago, I worked with a bug bounty program, and I still am connected with a bunch of the researchers because it's like that human side of things that you can't take that away from it, I think that's a core element, but I love that.

Nic Fillingham: I'm going to just quickly come back to the last question that you mentioned that you sleep on it. Before you hit submit, it sounds like you sort of you write out your report and then you sort of maybe wait till the next day or you sort of go and do something to maybe change your scenery, change your mind, and then come back. And perhaps sometimes every now and then something will come up that you're like, "Oh, I should have clarified that, or I should have added that." It's the old adage of like, never send an e-mail angry, right, or a text angry, right? You want to sort of get yourself calm. You want to get yourself into a good space and, you know, obviously then put your -- if you're going to put your thoughts down on paper, be it physical or digital, that you're doing it from a good place. I thought that just was great advice and I wanted to just sort of reiterate that it sounds like you'll give yourself a bit of a breather before you'll actually hit submit just to see if anything else comes up or you sleep on it and see if there's any more information. How often do you find yourself writing a report, but then hitting save, you know, as draft and going away and having dinner or going to bed, and then you come back and before you hit submit, you're like, "You know what, I'm going to add this thing, I'm going to change this thing." Does that happen a lot?

Brad Schlintz: I don't think it happens a lot. I would think it really depends on the particular vulnerability. You know, I would say if there was a string of vulnerabilities that I just found, let's say there was five in a row and the very first one in that particular application, that one I probably will take my time on. I'll sleep on it. I'll make sure I got the right things, but then the subsequent ones, the second, the third, the fourth one, affects the same application. It's got a similar exploitation path. It's got a similar type of impact. Those ones I'm usually more quick about. Like, maybe I don't sleep on those because I already kind of have one. I took the time to master one of them or finesse one of them, you know, so it's just right. The rest of those are sort of copy paste and change the details to make sure that it matches up with the impact or with the particular vulnerability, the new vulnerability that I found.

Wendy Zenone: I know that we're coming up on time and so, I wanted to just wrap this up with a question before we say goodbye. What's next? I mean, aside from Zero Day Quest, do you got more travel? Are you speaking anywhere? You know, is there any upcoming events that folks can come and hear you discuss some of your skills and findings?

Brad Schlintz: I'm still pretty new to the public sphere. I would say this is my very first time kind of talking about bug bounty or security research, so this has been very exciting for me to come on here, to come on to the podcast. I don't have any speaking plans yet, but I do plan on attending DEF CON again this year. I attended last year, and I absolutely loved it, so I'm looking forward to that again this year. And in terms of the travel, you know, we will continue to travel around South America. We want to at least go until the fall of this year and after that, we have no idea. We'll probably go home maybe for a couple months, see friends and family again, and then pick another part of the world and keep on going.

Nic Fillingham: Where is, air quotes, "home" in the U.S., Brad, if you're -- if you're willing to share that?

Brad Schlintz: Yeah, back in Wisconsin.

Nic Fillingham: Ah, does that make you a cheese head?

Brad Schlintz: Yes, a cheese head [Brief laughter]. Yes. The land of cheese and beer.

Nic Fillingham: Is everyone from the state a cheese head, or is that specific to a college or a team or something?

Brad Schlintz: I think, technically, everybody's a cheese head, yeah.

Wendy Zenone: Yay!

Brad Schlintz: Yeah [Brief laughter].

Nic Fillingham: I'm not sure how much cheese we're going to have at the Zero Day Quest, Wendy. Is there a...

Wendy Zenone: I think I saw something about a cheese plate or something. There's going to be -- there's going to be some cheese.

Nic Fillingham: There'll be some cheese. All right, great, excellent. Thank you so much for being on the podcast. Thank you so much for your prolific submissions to MSRC over such a short period of time. I'm so excited to get to meet you in person and have you come to Redmond in April for Zero Day Quest. We would love to have you at a BlueHat event. We'd love to have you on the podcast again in the future. Thank you again for your time. All the best with your travels and your hacking.

Brad Schlintz: Absolutely. Thank you so much. I can't wait to attend the live hacking event and to meet you all in person.

Wendy Zenone: Thank you for joining us for the BlueHat Podcast.

Nic Fillingham: If you have feedback, topic requests, or questions about this episode...

Wendy Zenone: Please e-mail us at bluehat@microsoft.com or message us on Twitter at msftbluehat.

Nic Fillingham: Be sure to subscribe for more conversations and insights from security researchers and responders across the industry.

Wendy Zenone: By visiting bluehatpodcast.com or wherever you get your favorite podcasts. [ Music ]