Episode 145: Gr3pme's Secret: Bug Bounty Note Taking Methodology

Title: Transcript - Thu, 23 Oct 2025 14:48:59 GMT
Date: Thu, 23 Oct 2025 14:48:59 GMT, Duration: [00:28:19.36]
[00:00:01.19] - Brandon Murtagh
If you have good notes and you have very, very thoroughly mapped out a target and you've captured all this information, you can do this with little to no overhead in your current bug bounty flow. 

[00:00:38.95] - Justin Gardner
all right, hackers, the ad read is going to get a little technical today, so buckle up for this. Okay, I'm going to tell you exactly how threatlocker is screwing hackers at every step along the way with dynamic access controls preventing even port scans from happening on Threat Locker networks. So let's dive into it. There's three primary ways that Threat Locker implements this. I'm going to give you guys two for this, for this quick read and hopefully you'll be able to understand how exactly they're preventing hackers from doing port scans. So first one is called local Challenge. This is on the common scenario where a computer wants to connect to a network resource and they're on the same network. So what's going to happen is over, you know, this, this threat Locker handshake. The computer is going to send a request to the server, the server is going to respond with a challenge, and then the computer has to, you know, complete that challenge and provide a response back to the server before the SMB port is even opened up to that specific computer. Right? So you can't do any port scanning or anything like that because you're not going through this handshake with the computer. So that's one way. The next way is in like remote work scenarios where your laptop is like, you know, out on some WI Fi or whatever, and you still need to access network resources. In this scenario, the computer is going to shoot an authenticated IP change up to the threat locker cloud. Then when it requests access to a specific server, maybe it's trying to get in by like RDS or whatever. If it's, if it's in a remote work scenario, the RDS server, you know, before it opens up, that port, is going to query the allow list in the threat locker cloud and say, hey, this IP is trying to connect. What should I do with him? And then threatlocker cloud will give them a yes or no on that and they'll open or close the port based on that response. Okay, so with Threat locker in place, really, you can't even do port scans, guys. So tell you what, let's go back to the show and hack something easier and we'll let Threat Locker do their thing. All right? All right, let's go. All right, hackers, I've Got an awesome article in the this Week in Bug bounty segment for you. Okay, this is. Yes, we hacks minefield between syntaxes exploiting syntax confusions in the wild. And I learned so much from this just reading over this article. Okay, so typically in this segment I'm just going to give you articles to go read and give you a summary of them. This time we're actually going to dive in a little bit. Okay, so let's check this out. This article is focused on syntax confusion, which is essentially just weird ways to represent syntax in various contexts. And the research here is lovely. Okay, the first one blew my freaking mind. Look at this. Okay, what is this C code. How does this work? Okay, apparently there are these things called trigraphs and digraphs and in Cs or in C, which is character sequences such as question mark, question mark, equal sign or percent sign, colon or less than percent sign. And these just are converted by the compiler into different characters on the fly. So this C code right here, which I'm sorry, for those of you listening, but the C code here that just has no curly brackets at all and just uses less than sign, percent sign, compiles totally fine and runs crazy. Absolutely crazy. So look up C digraphs and trigraphs. Less than percent sign is equal to the left curly bracket or the open curly bracket. It's like, how does this even exist? These are the things that hackers need to know so that we can do cool syntax bypasses. Okay, so that was the first one. The next one was parsing on specific, specific ports, right? Like you can pad your zeros, your port number with zeros and a URL, right? So 0000443, right? Same thing as 443. Oh, this one was really interesting. Apparently in Python you can reference specific characters, Unicode characters using their backslash capital N syntax. So backslash capital N, Greek capital letter delta in all caps. It will give you the actual character point for that. Like what is this backslash capital N with curly brackets syntax in. In Python and Perl is super weird. And apparently there's a backslash P curly brackets syntax as well that is just whack. Oh, okay. And then check this one out, guys. In. In. You guys have seen content disposition all the time in your multi part form HTTP requests, right? Apparently there's another format for this, right? Where it's not just file name equals my file Txt, you could do file name equals, asterisk equals and then specify like a character set like UTF8 and then provide that file name okay, so now we can smuggle in Unicode characters into our file names in content disposition on multi part form HTTP requests. Okay. Which is going to be awesome for unicorn normalization. So good. Okay, so anyway, this article by yes we hack is phenomenal. It's chock full of these sort of syntax confusions and real life bug bounty finds right like that he does a full read SSRF and a cache poisoning bug. So go ahead and check out this write up. We'll link it in the description. The minefield between syntax is exploiting the syntax confusions in the wild and check out those like C trigraphs and digraphs and the backslash capital N syntax to access Unicode code points in Python and Pearl. All right, let's get to the main content. I think Brandon is doing an episode today by himself which is awesome. He's going to rock it. Pay close attention to this, okay? Because taking notes in bug bounty is extremely, extremely, extremely important and Brandon is the go to hacker in my opinion that does this extremely well. So, so lots of good content here. Enjoy y'. All.

[00:06:27.68] - Brandon Murtagh
Hello everyone, it's Brandyn. Gret me, we've got a bit of a different episode today for you. It's going to be shorter as it's a solo episode, but it covers one of the topics I've personally had a lot of questions on and has led to a lot of success for me personally as a bug hunter and that's how to have long term success on a target and my note taking methodology for that. Now, full transparency. This is also coming from a hunter who is most definitely not a recon guy, that's not me who never has been. So long term success on the target really boils down to my note taking, my JavaScript monitoring, my general target monitoring outside of JavaScript monitoring and also collabing. We'll start off with the notes as it feeds into everything else I do on my approach. Um, but hopefully it makes sense. So for the audio listeners I will be sharing my screen, but I'll do my absolute best to talk through it as well. Okay, so my notes essentially starts off with a default template. Every time I personally use Notion, I'm pretty much embedded into Notion, but you can use whatever you like. As long as you capture all this information, I don't really think it matters too much. So my default template first consists of the target, the target's tech stack, and what I'm looking at here is really the frameworks and the languages in use, any third party components in use, whether that's certain libraries for billing, JavaScript widgets, things like that, if it has any reliance on other applications, what database it uses, and all those kinds of things. That's the first part of the notes and what opens up the target. Then after that, the brainstorming risk section. Now this is essentially where I threat model, and this is also the area where you're going to want to put down every single attack vector you can possibly think of and everything that you've tried. So for example, I've got a little note here for myself to threat model and highlight high risk areas to target first and then walk through that. And how I actually take these notes is I have the endpoint or the functionality. I have a bullet point for the information that I captured from that and I also have a little tick box for the actual check that I want to do. Now the idea here is that you put down all your checks, but I'll come back onto this later on. Now I also have a high signal area, and this is an area where if you're hunting for a long time on the target and you've identified a really high signal search, whether that be a Google Doc, a very high signal grep, for example, in JavaScript files, or just kind of how they identify their routes, whether that be API, client side, whatever it might be, that goes down to my high signal section. And what that allows me to do is whenever I'm looking for something quick, I can just quickly come back to here and search for that and see it straight away on the target. The other thing as well, I have an error Oracle section and I don't really hear too much talk about this, although I see a lot of hunters inadvertently doing this and tracking them. And an error Oracle is essentially a part of the application or an endpoint that you can use to intentionally force an error to disclose information about the target, the system, the application, the process, whatever you're looking at. So say, for example, you have identified that there's a very, very sketchy endpoint that when you, instead of putting in, I don't know, a URL starting with HTTP, you put in a URL starting with or a URI starting with FTP and it causes it to fall over. It gives you the internal host in use, it discloses some ports, maybe even some authentication headers. Put that down in your error oracle. The reason I have a section for error oracles is because there has been more times than I can count where I have disclosed a bunch of information, whether that's through a verbose error, whether that's through Just general fuzzing, whatever it might be. And it hasn't ever been useful to me at that time. It's good information to have, but it wasn't useful to me. I couldn't exploit it. Put that down in your Oracle section in your notes and I can pretty much guarantee you if you hunt on the target for a long time, that will come in useful. One example of this is I was in a live event in I think it was in April and I had an error Oracle where I could disclose a ton of information about an internal service in use, including internal host names, authentication headers, ports, everything. A lot of information I noted it down wasn't useful maybe last month or the month before. That information actually came in useful when I was building out an attack chain on a similar but different area of the target. So definitely note those down, they are invaluable, especially when you're hunting long term on the target. And then the last part is attack paths and gadgets and this sort of feeds into the other two. But if I'm building out an attack path or I have a bunch of gadgets, whether that be client side path traversal, open redirect, a quirk in there or flow, things like that, I note them all down here and even if it's semi built out attack chains, they still go down, they still come in useful. And I also have a tracker at the bottom and if I am actively working on multiple attack chains or multiple bugs which convoluted and I can't get done in one session, they'll go down into my tracker at the bottom. So I'll show you what this looks like on an old target. And this is an older version from a target maybe last year that I was looking at. And I've noted everything down here. So first of all it starts off with all of the scope and credentials, for example, then we've got the behavior. Now this is very, very nice information to capture. If you look at a target for a couple of months, don't look at it and then come back to it. This is sort of information that will let you look at your notes and hit the ground running. So I've got release notes for the target, I've got support documentation for the target, I've got documentation on their access controls, if they have weekly demos and webinars on new functionality, documentation on their user and auth matrix, all of that is captured so I can come back, save it, refer to it at a later date. Also have the behavior of what the target does, information on the tech stack, the user levels, framework and language didn't fill out third party components here for whatever reason. Now this here is for me what makes me effective I think as a hunter because I threat model and I threat model a lot on targets and every single thing I can think of, whether that's related to, I don't know, basic idle testing, xss, more exotic authentication, bugs, everything, and I mean everything goes down in here. So for example, the first point here is I got cookie signed using Rails but can be removed with a screenshot as well, which I've toggled so you can't see it and all of these checks. So email functionality, export import account functionality and the checks I've done I've ticked off for example here error cause 500 when important HTML file. Now I'm showing you a redacted version obviously because I can't disclose too much information, but this allows me to list all my attack vectors and for everyone watching this, it's just genuinely massive, massive page of all of these different attack vectors, all of my different notes, what works, what didn't work. So I can keep track of the target and thoroughly assess each piece of functionality and be sure that I have thoroughly assessed it. Now the idea here is that these notes are a living breathing document. You don't ever really want to complete them. You want to list down as many attack vectors as you can possibly find. Whether that's from new research you've had, whether that is if the targets release new functionality, whether whatever it might be, this is a living breathing document that you always append to and always keep notes of. Now the good thing is when you get to a certain threshold in your notes and you have a lot of information about the target, this enables you to really effectively collab with someone. And what I mean by this is if you feel like you have absolutely kicked the living daylights out of a target and you feel like that, you can't push it any further, at least for now until a couple of months time you can pass these notes to another hacker and they can just hit the ground running, see what worked, get some immediate feedback, get some immediate gadgets, get a feel for the target within. I don't know how long would this take to read? Maybe 10 minutes to get to thoroughly read them and they can just go and get hunting. Now there isn't a recent example I can think of this and I hope they don't mind me shouting them out, but Greenjam and jrock have been collabing a lot and sharing Notes on a target that they both look at pretty heavily and they have absolutely cleaned the floor just by sharing notes and sharing gadgets on things that they both looked at but maybe couldn't exploit at the time. And it's been a bit of a bloodbath. So very, very useful, which is why it's one of my big things on a long term target. Now the other thing as well, JavaScript monitoring. I'm not gonna get into the weeds of what tools to use, what frameworks to use and things like that. I'm just gonna tell you some very high signal things I monitor for, which does let you identify if there's been a new change on the target. And you obviously wanna be the first one to look at that. So first of all you want to. And let me just go back for a second. If you have good notes and you have very, very thoroughly mapped out a target and you've captured all this information, you can do this with little to no overhead in your current bug bounty flow. Say for example, you've mapped out exactly how their endpoints, their routes, their permission sets are mapped out in JavaScript and you have that in your high signal search area of your notes. You can do this very quickly. It would just be a case of spinning up a server, identifying, creating a few regexes maybe and setting up that monitoring. You'll be completely good to go, which is why I'm so keen on having really good notes. But anyway, the things I look for are request handlers, endpoint declarations, user permissions, user flags and content types. Now I have this as a template to remind myself of things to look for because I can fall into a bit of a bit of a hole when I'm hunting and just forget to do certain things. So having my notes is very essential. And if you've collabed with me or worked with me like Justin will know this. If I need to do something and it isn't written down, chances are I'm never ever going to do it. So anyway, I have things like orphan session flows which I look at, which is uses of things like local storage, session storage, post message. I monitor new endpoints associated with the password reset and password recovery flows if there are one. Another big one as well is privilege and feature controls. So you might look at and every target's obviously going to be different, but there might be cases where you will see a lot of strings in JavaScripts to show you client side routes and different permissions with things like IS staff, is internal entitlements Scopes is admin is user is all these different sort of roles. If you can identify exactly how these are defined throughout an app and monitor them, you can pretty much be sure that if you get a new hit on one of these, there's going to be a new user role or new functionality coming out which probably hasn't been looked at if you're quick enough and that's going to be very high signal for you. I've had a lot of success personally identifying these different roles and making sure I'm monitoring for them. Another thing as well is feature flags and Justin talks a lot about this in some of his previous talks around response like rewriting and things like that. If you can identify new feature flags for a B testing again you can just pretty much unlock most times new functionality and new attack surface. Obviously you've got your endpoint discovery as well. You want to look at how these are identified. And one thing here is I've noticed with a lot of standard monitoring I've looked at, there's a lot of focus around naturally HTTP HTTPs URLs, but you also have websockets and that's very target specific. So if you can set up monitoring for that as well, that could be very high signal. GraphQL, you've got method and verbs, you also have query parameters and depending on how they're defined on the target you'll get different return on investment there. Now other things I have more recently started monitoring for as well, which I touched upon earlier is client side syncs. Before my monitoring was heavily focused around endpoints and roles and feature flags and things like that. But that can also be quite high signal. If you're monitoring JavaScript and you set it up, you might as well do the extra extra overhead as well to look at the other things. What else have we got? And I've just got a few other high signal things I try to look for file and content handling service workers framework, specifically hotspots. This is a good one. If you have like an XJS target for example, if you're they're using GraphQL there's going to be patterns you can lock into on those targets which will be very high signal and allow you to harvest things a lot more easier. And yeah, I've given myself some handy regex snippets and examples just to remind myself and quickly set up JavaScript monitoring. And the whole point of this and the whole point of the notes is to have very high signal, very frictionless things that you can do to add to Your hunting processes, which give you a pretty much immediate or close to immediate roi, which is as less overhead as possible to implement. So that's kind of what it looks like. And the important thing to note here as well. Let's just go into here. Okay, this is an example of a, of another application that I set up to demo. If you have a target, which for example is more of an ecosystem than a single app and there's multiple APIs, or if it's a star scope, for example, I just personally create another page in here and I start the process all over again. I create a page per application or page per API and go through that process again. You start off with your endpoint or your functionality, you have your bullet point to capture the information on that, what it does. Then you have your check on the actual check to perform. So test for access in the idle, in the idle parameter. I wish there's an idle parameter in the ID parameter as it's reflected. And then once you complete this check, you go back up here and then you add your feedback from that check and say not possible escaped properly in ID parameter. And yeah, that's sort of how I map that out in my flow. As I said, the idea here is that you capture all this information and you want to go with the mindset of okay, this is for long term success, where you want to capture the high signal things which might not be useful in that current moment you're hunting, but later on down the line it most definitely is. And for me, the thing when this really clicked and made sense was my first month in hunting. I started in January this year full time and obviously it's quite daunting when you start hunting. The very first thing I'd done, I went through all my notes for all my regular targets, about four or five targets I regularly look at. And my entire first month, and I'm being 100% serious here, was pretty much bred from my notes and things that I noted down. Wasn't useful to me at the time. I come back with a fresh set of eyes or there's been new functionality or if I'd found new gadgets on that target later on down the line, which I had also noted down and I could basically just chain them together, carry on hunting. And that was pretty much my first month I'd done that. Also went through my old bug reports and bypassed them. So perhaps you don't have notes right now. I will be releasing my templates that I use. These are my strips down ones for people to use and Apply universally across targets that they can cater towards whatever they're looking at. I use notion they'll probably be released in the hacker notes and if you're just getting started, my flow on how I do this personally, I sit down on the target for a couple of hours, I'll go through, I'll map out the application, take my initial notes from there and then say every I don't know at the end of every day after that point, I'll note down my attack vectors, check my proxy log, check my burp history, check my kido history, go through all that and note down the things that did work, didn't work, my error oracles, my high signal searches, all the gadgets I found from that day on. Now, if you want a bit of a cheat code to get started, if you don't do this already, start by going through your old reports on a target, noting down everything that you did find bugs in, how you found them, the endpoints they're found in, the parameters, they're found in, the bug type. If there were any error of course identified in that and start off with that, you might be able to start bypassing all fixes and things. So what this does, it might not be the sexiest method to get started off in, but it does definitely allow you to capture a lot of information to come back to that information later. A date and hit a target hard. Now, as I said earlier, if you can capture all that and give this to another hunter and let's say for example, you are looking to collab and you're not sure who to collab with, contact one of the top 20, top 15 top 10 hunters on the program you're looking at, Ask if they want to collab, build that trust and maybe start sharing your notes. And I can guarantee that if you've captured them in this level, in this format, you will be able to start sharing notes, collabing and getting more information. So I hope you find it useful. The templates on all of this, on my notes, on basic JavaScript, monitoring the things I captured, exactly what you're looking at here will be shared with you on I'm guessing it's going to be the hacker notes and you can clone this in notion. If you don't use notion, just use a similar layout to whatever your favorite note taking is and it will work. I hope you find it useful. I've had a lot of questions on this. I haven't really shown it in this much depth before and again it's not the sexiest, but it will most definitely allow you to capture a lot of information which will lead to longer term success on a target and allow you to essentially get free bugs when you have enough information captured and you revisit a target at a later date. It's worked for me. I've shown a few hunters that I've had good feedback overall on it. I've given some hunters I've collabed with my notes and it's allowed them to hit the ground running and start hunting very quickly. So hope you find it useful. As I said, bit of a different episode today, bit of a shorter episode as well, but this might be useful to some of you. So let me know what you think. I'll be sharing them. And yeah, thank you everyone.

[00:27:52.00] - Justin Gardner
And that's a wrap on this episode of Critical Thinking. Thanks so much for watching to the end end y'. All. If you want more Critical Thinking content or if you want to support the show, head over to CTBB Show Discord. You can hop in the community. There's lots of great high level hacking discussion happening there on top of master classes, hack alongs, exclusive content and a full time hunters guild if you're a full time hunter. It's a great time, trust me. All right, I'll see you there.