Tales from a Triage

All right. All right. Good morning, guys. I figured y'all make a little more noise than that. There's a lot of people here. Good morning. All right. First of all, I I wanted to say this is absolutely incredible. I've been to a lot of different conferences, some of the biggest ones in the world, and this is surpasses a lot of them. It's incredible. Wanted to say thank you to the volunteers and particularly to Nicks who have been working on this. I've seen them running around like crazy. Thank you guys. I'd like to give us a round of applause for them. They're doing all the hard work here to make this for all of us. So, today I wanted to talk to you

guys about Tales from the Triage, right? Um I based this title off of kind of we had a series called Tales from the Crypt about the creepy stuff that you know creepy little stories for kids. And I I think that the triage team is very misunderstood. Um, and then also how do we communicate through a triage team, not only a bug bounty, but when I'm looking at people and saying what do my clients think if I'm just a red team or what am I and whether it's an internal client um or whether it's a client that I'm giving a report for, how do I communicate? Well, uh to me the communication in cyber security is one

of our major barriers right now. And so to introduce myself, my name is Charlie Waterhouse. I'm a senior security analyst. Um, I'm with Synak and I work in our special projects division. A lot of you may have seen me kind of in just different places where I show up. Um, on SRT Slack, I go under Texan. Um, mostly I work there, but if I reach out to you, you just say hi. Um, I spent 22 years in a completely different field in airline. Um, was a translator, travel over 52 different companies there. Got into cyber security as a second career. Um, it was a passion of mine. I've been in I was one of the Napster guys who was

downloading on servers there. I was one of the guys who was on very early Commodore 64s writing on green screens, writing C++ um, all the way back in the day. A lot of fun. But I really got passionate about it again. I said, "Let me make this a career. I want to be able to protect people. I want to be that good guy." And oddly enough, I figured out how to do it by being the bad guy. um by being the bad guy, there was always more interest to me in Lex Luthther than Superman. And so I was always more interested in Darth Vader. Um I I know that heart of kind of let me see what I

can do. And that curiosity is at a lot of our core. Um I've been a red teamer for over 5 years. I'm also on SRT. And so how many SRT do we have out here? I know we've got a few. How many bug bounty researchers do we have? Okay, awesome. How many people have wanted to go into it and are thinking about it? Great. I like those hands. Also, what we're going to talk about today is kind of the ability for how do we communicate and how do we start shortcutting this a bit. Um, I've developed products on OASP um work with their com on their some of their advisory boards, NIST, OSET APIs. Uh, if

you've looked at the Sync headless API, I was one of main security engineers behind that. Um, we've got a lot of great products, but it really comes down to our researchers. Without you guys, we don't have a business. It's really that simple. So, we're trying to help you write more impactful reports, understand more of what the reader sees. It's very easy to get blindsided and think about it from what we have instead of what they need, help you communicate better, and get your reports accepted. If you're a blue teamer, these are also good for you to realize for how your red team needs to communicate to you. write these in their request and say, "I need this

from you guys." Engineers, we all speak, as I told some people, we have engineers that speak one level of nerd. I've got security and sock analysts that speak another version of nerd. I've got security researchers speak a third version of nerd, and nobody translates between the three. How do we bridge that gap, much less into other things outside of the securityities things? I don't expect my CEO to be a security person. That's not his job. how do we communicate in their language? Um, so the communication piece is a very big key to me. So, let's start off with an example of some triage reports that I've seen. I've done over 25,000 of these things. So, I've got a pretty good feel

for where people have habits, where fallacies happen, and where problems are. This person wrote me in a very detailed report. There's about 23 steps. I had a custom GitHub repository to show me code. He ranked this as a CDSS 10. I mean, this was an incredibly detailed report. That was what I got. Does anybody notice the dock type HTML? It's the code behind the website, guys. He was very disappointed when I said, "I don't care. This is low impact." He goes, "But it's code." And I'm like, "Yeah, and that's how the web works." Um, so the point being that sometimes we can get very blindsided and overstate our impact. We need to be a little critical as

researchers and say, "What is my impact really?" Not because I found it and I'm excited to find it, but what is it critically from somebody else's perspective? If we have somebody who is a head of engineering, they've got to spend money on this. This is not a freebie fix. Is it worth their money and time to fix? Do I, you know, how is this worth it? So question yourself about impact. Be a bit critical. When I've submitted reports, I've had to go back. I'll tell you the most painful rejection I ever had. It was for myself. I put in a report. I started thinking about it critically. I had to go in and reject my

own report. That's pretty humiliating. But you have to get critical on yourself and question if you adjust CVSS high. And we all do that and we all want to do that whenever we're putting in a report because why? it pays me more money if it's higher. So, you've got a financial interest to go high. Well, guess what? I don't on the other side. It's not that I care either way, but I've got to be keep it consistent. That that type of report is very consistent in the CVS score and ranking for our clients because when I send it to them, they're going to have to put this in their program. If last week it was a seven and now it's a nine,

they're going to question me and why I'm not consistent. So, I've got a key that I need to keep consistent and honest. You're not doing yourself any favors. I've both raised and lowered CVSS scores. Now, normally I have to lower them because people want to put them up higher than they are. On occasion though, I have raised them to where I'm like, "No, this is more impactful than they thought." So, don't be afraid, but let's be very honest about what we're doing. Let's see if we got this working.

Nope. I'll just use this. We're good. Okay, sweet. Okay, number two. I've seen this a lot with people, is they act like the triager is their enemy. They act like I don't want to pay you. Guess what? If I don't pay anybody on that program, I don't have a client. I don't have anything to send to them. If I'm adding blitzes and incentives, it's because I want vulnerabilities. I want you guys to find something. So, I'm not your enemy. In fact, I'm going to give you a secret. The people that are the closest to the researchers on bug bounty programs are probably your triagers because they are also researchers. They're also hackers. That's the only way they can do the job.

They're going to be the ones that go in and fight for you in front of clients. So understand we're not against you guys. We're probably your best ally. It's why I work very closely with our community team. Um Rubric, our head of community is there just to make sure that everyone tries to make money and has the chance to make money on Synak. We want everybody to make good money. Um, I know that Hacker One also has people who do the same thing with Harley and his team. I'm certain that Bug Crowd has the same thing also. So, they've got people that are your allies and one of the biggest ones is your triage team

because they've been in your shoes. Okay. Report example number two. This person comes in and he goes, "I found a SQL. It's on a major company, Global Top 50. And hey, I found this local police department. I hacked their uh SQL database. It's on that infrastructure. Y'all really think Global Top 50 owns a uh police station database and he just pulled down all their cases? Talk about cringe moment for me. I'm like, huh, wow, we got to call this police department till we just hacked them. That's not good. Sometimes the clients make mistakes, right? So, if you see things that are not passing the sniff test, be a little critical here. Read the rules. Understand your rules.

These are, let's not kid. I've joked and I've said what I do for a living is felonies for fun and profit. We need to remember that the stuff we do as researchers is illegal in most cases. It will end you up in prison. The only reason we have permission is because we have that permission document that tells us what we can do. Don't go outside that. It gets bad. I have to answer those calls for clients when that comes through. If something is off and it doesn't make sense, like you see a police department on a global top 50 or that there's somebody offering guitar lessons, ring us. Ask us and say, "Hey, does this really belong?" And don't go

out of scope. Um, I know it's tempting. I know we see things that are along the periphery, but ask the question first. Make sure you're legal and that you're within it. quickest way to get on the bad side of any program is to keep going out of scope. Um, you're adding risk not only for yourself but legally for us. Not great. I I know a couple of former colleagues who have had to deal with these issues also and uh he's grinning right now. Not fun. So, new example, researcher writes a really long report, super detailed. I mean, it's amazing uh the amount of detail they put in it. I can't read it. I'm an American. We don't speak

languages a lot. I speak three languages are pretty exceptional. I don't speak Chinese and neither does my client and neither does my triage team. Figure out which languages they'd like this in. Generally, it's English for our international, you know, customers here, but just make sure that you're very clear. Um I I I've had reports like this multiple times that come in in languages from across the globe. So, what this brings us to is communicate clearly. Um, this is one of the hardest things for people to do. First of all, assume I've never seen the app. I am looking at 12, 15, 20 different apps in the day. I may have never seen this and you spent three,

four, 10 hours on it. You know it intimately. Explain it to me like I've never seen it. Give me those detailed instructions like you would someone who's never touched a computer. Click here. Give me a screenshot. Do this. Give me a screenshot. Treat me like I'm just starting in computers because I may have never seen this app before. Also, show the impact. Um, this is key. A lot of people forget to do this, oddly enough, that if there's no impact, I can't accept it. So, show me the impact. Speaking of that, detail why it's a problem. Now I say this not only for you know bug bounty but also particularly if you're a red teamer and you work for as a

consultant or you do red teaming reports remember that your CEO is not a specialist in cyber security he doesn't know what the impact is because it's an IDOR if you're going to sit and you do uh cross- sight scripting don't give me alert one that doesn't mean anything to him or to my engineers give me a document doommain show that you can pull something down and then explain hey this is enough that I can now Start fishing and getting credentials from people. Anybody in your organization, start explaining what it is. I I often said to people when I'm triaging, "Show me the evil. Show me the bad that you can do with this." That said, within reason, right? Let's not go

crazy and damage production systems. But go that extra step to really demonstrate what the problem is. Don't just tell me and then think critically about it. If you've got a reflected cross-sight scripting that's not signed in, aren't you going to get credentials from that guys? There's really kind of no impact there. So, if you think there is, make sure you're very clear with us about why. Because also, it has to be very clear for our customers. If I, as a triager who deals with hundreds of these things a month, don't understand your impact. My client that's seeing this for the first time never will. So, make sure that we very clearly explain it. Next thing, provide visuals. One of my

favorite ones, and this is an SRT who I'll give an example here. He is a Titan. He is Olympian. He is a guy you guys know. Um, if you're on SRT, he's he's top. Um, also has a very good sense of humor. He sent in a video one time that was modeled after the 1970s Batman show. It had bang and pow in it that he put on it. And at the end when the exploit hit, it started playing Rock You Like a Hurricane all over our office at the top volume. We loved it. We had to edit it a little bit, but we loved it. The point being, he took that video to show us very clearly what was going on

and very clearly how to reproduce it. Now, the engineers on the other side who get this, they've never seen that vone. Obviously, if they didn't if they knew that vone existed, they wouldn't have programmed it that way. So, he showed them exactly how he reproduced it. And us, too. was very amazing. So, detail each click you did. Also, detail your setups. Another thing, make sure you show us which browsers you're using because all of a sudden, if I'm looking and I'm like, "Wow, you're using um a browser from 1992. I may not take that vone, right? I mean, there's a lot of things we can do with those old systems." So, make sure you show us exactly how you set it up.

Show me. Um in the US the state of Missouri is known as the show me state and very much research is like that show me how you did what you did. Just coming up with the answer is not enough. I it's not what is the answer. A lot of times we need steps as to how you got there. What was your work along the way? That helps us to really get to the bottom of this problem. And also nice thing about a video guys, I've had targets that have gone down. I have targets that have changed in the middle of a test. somebody's re-engineered it. I can't prove that you had it with a video. I

now have a lot more proof that you actually did it. So, if something changes in the meantime, I'm like, "Yeah, that was there right then. It's not acting that way now." But, so make sure you give us a video if at all possible. That does not substitute for screenshots because those load differently on the back end, but just give us both. Air on the side of too much information. Reports with no steps. Um, I have seen some reports that are a single paragraph, no spaces, no punctuation, I can't read it. It's horrible. I can't reproduce it. It's like, I found this. I'm like, okay, what do I do with that? So, show us your steps. It's make it very easy for us to

read. Divide out those steps. The reason why Synak is notorious for asking for separated steps is it makes it so much easier for us to read and so much faster. I'm going through these things at scale. I'm trying to get through a vulnerability in no more than 30 minutes on average. I don't have time to sit there and parse that out and it makes it really ugly on the client side. When I send it to this gentleman here as an engineer, he goes, I can't read this. This looks horrible. So, let's make it very legible for people. break it down and make it simple. That's a big key here is that you guys understand to do some things that are

amazingly complex that very few people out there know how to do. We've all heard it. People are like, "Oh, you're a hacker." And they think it's some mystical magical thing. We know it's not. But we also need to be able to explain it well. And we have to realize that what we do daily is complex. So, let's own that and break it down a lot. Stay safe. Um, in case you can't tell, I'm a big dog fan. I work with Husky Rescue in Texas to rescue dogs. So, love them. Um, ask if you're going to cause damage to a system before you do it. Particularly if we're in production, right? If we're in production, we can make mistakes that

can cause the client a lot of problems. Um, I had one happen two weeks ago. There was a board meeting over something we accidentally did and it was a pure mistake that he could not have predicted. But let's not intentionally do things like run, you know, eternal blue when we know what that can do. We know eternal blue is a risky exploit. Let's not try running that in a system without saying, "Hey, I think I can get it. Can I?" They'll tell you yes or no. But it's better to be safe and not take down a client's system. Of course, remember that what we can do can be a crime. So, let's be careful that

we're staying within the scope and within the rails that they've set for us so that we don't go out and I don't then have to have legal involved. I personally have had the sheriff show up with a restraining order and with court orders for me. It's not fun to answer those calls. And in that case, I was not out of scope. Um, but you don't want those knocks from the police. Let's make sure we don't do that. And should be without saying, don't hack off the clients. That's a real quick way to upset people, particularly my team. I've had people who sit and like I've had somebody that they thought it was very simple and they

told the client, "Well, this is really stupid. Go figure it out." How do you think my team reacted to that? It It was not nice. Um, so let's make sure that we're always being there, which leads me into stay professional. This includes not only the clients, but also your triage team. We're here to help you guys. I am here to approve loans. That is my job is to pay money to people. It's pretty exceptional job that I get to hand out thousands of dollars in a day. But in my head, cutting a check for $15 and 10,000 is the same thing. It's all money on a screen. It's not my money. And I'm not audited on it

because my job is to pay money. They just want to make sure that I only pay the right things. So, make sure that you're always polite. Be professional, maintain good relationships, and be personable when you're talking with people. It's very easy for us to get caught up and particularly in bug bounty about money. And we'll talk a little more about that later. But I just make sure that we're always professional. This is a very easy thing to get frustrated. We understand that. But try and always double check yourself because I I at least every couple of weeks I have somebody that goes off on somebody and says something that you like, "Yeah, that wasn't really professional.

Listen to the feedback. Um, this ta t ties in with be professional. I give a lot of feedback. If anybody in here's ever got one of my reports triaged back, you understand I will write a lot because I'm trying to train you. If I reject something, I don't want you to make that same mistake in the future. Your triagers are your next level of education. They're looking at dozens of reports a day. How do you think they know what they know? It's because we've seen it before. That's the value for our clients is they get to use our knowledge to help supplement you guys. What you guys can do with it is understand where we're coming from. Ask questions. If we

reject something, say why. Please explain to me how this is low impact. Here's where I'm seeing it. Don't come at me and go, "I feel I think I think this should be worth more money." Well, I don't. Um, it is what it is. It's the price we set on it, guys. And so don't come at me with I think and I feel and emotional statements. Come at me with facts and say here's the facts that I see. And I'm going to tell you this from Hacker One, Bug Crowd, Cobalt, Thinac. Nobody wants to hear that. Well, Hacker One takes this, bug crowd takes this. Well, yeah, it's a different company, guys. Um, go figure. We've all got a

little different rules. That's not the facts I want. The facts I want is here is my exploit. And then remember, you must have not explained it well the first time because you're having to reexlain it. Take that feedback. This is all feedback for you to learn from. And I've had some people who have said, "I thought that the way y'all made me do reports was extremely painful. I hated it." They go, "A year in, I am a better pin tester and a better reporter at my main job because you guys made me do it right." So understand that when we're pushing you, we're pushing you to be better. It's not out of a negative. The

triage team wants to help you ask questions. Mindset. Um, I just changed this slide this morning. So, this slide is really about what it takes to be successful. How many people, like I said, we had a bunch of people that wanted to get into Bug Bounty or we're in Bug Bounty. My question here, how many people are interested in Bug Bounty because it's money? I hate to tell you that's the wrong answer. I see one person here who's probably made more than anybody else in the room that didn't raise their hand. If you approach it and you come at it because you say, "I want to make a million dollars." Yes, that happens. It it absolutely does. But if you approach

it from that, for some reason, it doesn't work. You have to approach this as I want to learn. People come to me go, "How do I learn to pinest?" Go out and get a bug bounty program and learn on that. You're learning against some of the best in the world. I've had people that have spent millions of dollars on these clients to develop it. Now, you get to see with what you learned in the classroom and on your online courses and your certifications really applies in real life. This is a learning tool. On my desk, I keep lock picks and I keep locks. I My fiance came out the other day and I handcuffed her with a handcuff

and, you know, then handed her a bobby pin and said, "Now, let's figure it out." She goes, "Where's the key?" I'm like, "I don't have one." Um, it's a challenge. It's a puzzle. When you approach it with the mindset of it's a puzzle and this is a free learning opportunity for me to where we pay hundreds of dollars for vulnerable machines to learn from. If we go and we do bounties, it's free. I've encouraged engineering teams to go and learn and do it because they're going to be free training and if they get good at it, they'll actually make a little money. Hey, instead of paying for vulnerable boxes to test, I got paid a couple

bucks. Oh, even better. approach it from the mindset of a learning tool, the money will come. But if you approach it as I need to go out and make $100,000 in the next 6 months, you're probably going to fail and you will have rejections. Is there anyone in here that is dubbed bug bounty and had more than 10 vulnerabilities that has not had a rejection? Exactly. No hands. Expect to be rejections. You're going to make mistakes. It's okay. We're not going to hold that against you. include remediation. Now, this is a big one that almost 95% of people do not do well. This is your chance to shine and to show what you've learned. You can get

into more detail than you think you need. I don't want you to say, "Well, you block this payload with your W." Okay, that's great. What's the real core issue? I want to hear stuff like when I see a cross- sight scripting I know that that is an input sanitization error with an input sanitization error other ones that include it in there or other types of cross-kite scripting and SQL injections I can point this out and say the true fix for this is to improve input sanitization here's some uses of white list versus blacklist here's how we can go about doing this give them a novel explain it because if they knew it they wouldn't have done it that way to

begin with right guys, why would you potentially and intentionally engineer something bad? So, what we need to do is really get explain show that knowledge that you've learned over years and tell them good, bad, indifferent. Make sure you tell them the remediation. Choose systemic fixes if you can so that way they don't have another flaw. Real goal here is not to make money at a point. It's to help them fix the system. So, if we can give them a systemic fix, that's even better. follow up gracefully. Um, everyone here who has done bug bounties has had a report that took longer than they thought to get back. Instead of reaching out and assuming that we're doing bad

and saying, "Pay me, do the needful, please reach out and just say, hey, I understand you guys may be busy. I've researched and I saw that you had a holiday. Please let me know what a time frame would be." Be gracious. It's going to get you a lot further on us than having to annoy me. and now I've got to go look at it. And I'm like, "Yeah, this guy is just rude to me." Don't get conf confrontational. Just understand that we may be busy or there may be another reason that you can't see that we had to hold that report. We're going to be as transparent as we can, but just reach out, be graceful, be a kind human. A lot

of this goes back into it. So, to summarize, overstating impact, triage doesn't want to pay me. Know the program rules. Communicate clearly, provide good visuals, stay safe, stay professional, listen to feedback, mindset, include remediation. These are the keys to being able to do your reports better. And if you start working on these, I can guarantee you're going to see a significant difference not only in the number of accepted reports because you're getting a little critical with yourself. A good example of that, lost the screen. Good example of critical. Um, I had a report that comes in and somebody goes, "I found this data leak. I have first name, last name, phone number. I have their address. I

have their job. It's all in this database. This is critical." I rejected it. The guy goes, "Why? I've got all this data." And I said, "Well, the first name on that list is Homer J. Simpson, and he's in Springfield, and he's a nuclear safety inspector, and the next one is most hislac." And I'm like, these are characters from the Simpsons TV show. This is training data, guys. Be critical. Information disclosures are awful about that. I It's a code disclosure. I can see code. And I'm like, yeah, well, and just because I see the code doesn't mean it's a problem necessarily. Did the client tell? No, client didn't say there's a problem. Well, yeah, open code's bad. I'm like,

yeah, tell that to Linux. Um, so understand that if you come at something, what is the impact? make sure that we're talking the right language with each other. Um, where are we? Okay. Um, couple of quick thoughts that I'm going to give you guys in closing to help accelerate those of you that are looking at starting Bug Bounty. I I have an 8 2040 rule that I have in mind and it's just something I've watched after 5 years of people. If you come in and you say, you know, I'm going to try this Bug Bounty thing this weekend for eight hours, see how it goes. I'll tell you, don't waste your time. you have a 95%

chance of failing and getting frustrated and not working. If you come in and you say, "Over the next two months, I'm going to spend 20 hours total investing in this information," you got about a 50/50 chance. If you say, "Over the next 6 months, I'm going to spend 40 hours really focused, not just scan time, but really working and analyzing," you got about a 95% chance of making good money. And by good money, I don't mean $ 15 or $20. I mean hundreds of dollars over the course of the month and it's going to re compensate you for your time. So keep those things in mind when you're looking at this. Oh, now we got

our slides

back and we're okay. Read the rules 2040. Um, another one, and this one was one that I got reinforced with Nick when we were talking in uh in Vegas, is specialize, learn one exploit at first, get to be the world expert in that. Train it, know it, love it. It's your deal. It's your jam. Whatever it is, whatever interests you and preferably something you have the skill set for. So, if you're a SQL database engineer, learn SQL injections. If you're a coder for a website, learn to do HTML. Learn cross-sight scripting. These are your these are kind of your specialists. Learn that. Once you can do that like nobody's business, that's when you add a second thing. Don't do it

beforehand. Get to be that expert and dig deep on the targets. A lot of people would just run a scanner, go, I didn't see anything from Burp. Well, guess what? Very little is found that way. Um, if it was that easy, the engineers would have fixed it, right? you guys are specialists and redteamers, you got to go deeper. Understand the app, dig deep. So, those are some keys that I have just for you guys as getting started or wanting to increase your bounties. This is what I would suggest is these items. Thank you guys for your attention. I really appreciate you being here. Um, without you guys, we wouldn't have this at all. And quite honestly, I wouldn't have

a job without the red teamers out here and our SRT members. Thank you guys sincerely from my heart. Um I have said many times internally we don't have a company without you and I am quite sure that Bug Crowd, Hacker One, Cobalt, they all feel the same way about the researchers. We love you guys. Um happy to ask answer any quick questions that anyone has. I've got a question back here. I didn't quite hear the last part of that. I'm sorry. Can we get a mic? Ah, there we go. I got the can we elaborate and I didn't hear last part.

So can you please uh tell some describe more about the 80 820 40 rule? Uh about which one again? I'm sorry. The third one. Oh the 20 820 40 rule. Okay. So this is my own deal. It's just the way that I've seen it. 8 hours. If you're only going to spend 8 hours trying to start bug bounty, you're not going to succeed. You've got 95% chance of failure just because it's going to take you longer. I think on average the first bone that people find is about 20 hours and it's unlikely to be a high value. So you're going to spend 20 hours and get $100 or $200. That's probably not a real good return. So if you're

going to give it 20 hours, you've got about a 50/50 chance. If you're going to say, "I'm going to dedicate 40 hours to doing this," you're going to find the first of all, like I said, about 20 hours on average. I I see some head nods out here for people that agree. My first one took over like 20 hours. The second one took 10. The third one took five. So, give it that 40hour time where you can start seeing these things come in and see the results in your effort. Because if you just say, "I'm just going to look on Saturday," you're probably not going to succeed. Um, I would suggest you go out and have fun instead.

It's very unlikely that you're going to do anything but pad my numbers for showing time on target. Um, that's not what your goal. Your goal is to find flaws. So, to do that, you've got to get really used to it. I can say that real commercial systems act significantly different than Hack the Box. For the most part, it acts way different than DBWA. That thing will fall apart in seconds when you touch it. So to learn to get into this mode takes you a minute. Don't give up too early. So dedicate that time, give it 40 hours and just say I'm really going to try. So just one more question like uh recently I faced a problem. Uh I had

submitted my bug report and the triagger had uh pushed it down from P2 to P4 and I have I had the report looked upon with my colleagues and different friends also and they insisted that it is a P2 vulnerability but I was not able to explain it to the triagger that it is a critical level vulnerability. So how should we handle that kind of situations? I I think the first thing is ex make sure you explain clearly um using whichever scale they're using. For example, we use CVSS. And so I've got the question like, is this an internal or external? Now granted, Sack, you're all remote. So there's never an internal. You're never local on that

machine. So that kind of limits it, right? And so but I have people all the time, they'll go, "Yeah, it's local." Like, how's it local? Where are you at that machine? Um, understand where they're coming from. Make sure you're using their scale. explain yourself, but also at the end of it, you have to trust them. As I said, we're not here. The money that I pay out is irrelevant to me. It It's just photos, you know, it's a number on screen. I'm not trying to downgrade it to get rid of money for it. What I'm trying to do is make it match everything else. So, I'm looking across hundreds of different reports that are similar, and I know how I've ranked that

before and how the company ranks it. So at some point just take that back and go okay thank you for the feedback I you know and make sure you get clarity as to why they rank it that way. Make sure you line in with that in the future because they may rank it differently. Um we try and be consistent within the same company but in between companies it can be very different. So um even with like a uh CDE we may be slightly different than that um just because we rank it as a slightly different thing. Thank you. No [Music] problem. Uh thank you Charie for the great insight. Uh thank you Charlie for the

great insight. Uh I just wanted to ask that you mentioned about we should always follow what we have in scope right like if there is something some subdomains which we should not go out of the scope but I want to ask like we are ethical hackers right the thing that uh differentiates us from the bad guys is the ethics here uh what if some guys they are there in China or Russia and they try to exploit that same kind of subdomain and you don't have any American jurisdiction under there how would you deal with those right because I'm not there for bounty for those uh uh blacklisted or not allowed subdomains or out of scope things. What do you what is

your take on this? So with scope first of all each program and I I've looked at some of the other platforms we all note scope a little differently. So make sure you understand how your team is noting scope. Um it's all a little bit different. There is no standard. So be that goes back to be very familiar with your platform and with your rules. Um, coming from the Synak platform, anytime I've touched say Hagger 1 or Bug Crowd, it's felt very undirected to me because I'm used to our launchpoint system that's our private VPN. So, understanding how each is supposed to act and the scoping is very critical there. And if you've ever got a

question, and we were talking last night about ambiguous scope. Um, if it's unclear or you're not 100% sure, stop. Write in a support ticket and ask us and say, "Hey, is this in scope?" Don't go and test it and then ask me if it's in scope. That's worse. Um, but just make sure that it's in scope. Ask them. And it's better to miss that bounty and miss researching on it than it is to create an incident with a client. I would much rather you see see you air on the side of caution. Um, and you don't have to go out of scope to find things. I know some very top performers, very top globally people

that have never had an out of scope problem because they follow it very directly and they're air on the side of caution. It doesn't keep them from making money. It doesn't keep them from finding things, but they don't have to go out of scope to find an advantage. They stay within the rules. So, that's really what we want is you guys to be safe out there, not have those incidents. We don't want to have those problems where legal gets involved. And I don't want to have to go and talk to a client who's mad at me. Um, those are never fun when you're getting yelled at by SISO. I can tell you that when you

have a publicly traded company says so, that is yelling at you, not a good day. So, um, for right now, I'm going to wrap that up. I know that we running a little behind today. Thank you guys again. If you have any questions, please come up, ask me. I friendly. I won't bite. Thank you guys again.