Meet the experts who power Synack’s strategic security testing platform. Our Synack Red Team unites over 1,500 of the world’s most skilled and trusted security researchers, who work with patented technology to deliver best-in-class offensive security testing on a continuous basis.
Synack Red Team member Bloodtyper reveals his journey from the DMZ to discovering critical AI prompt injection vulnerabilities. Learn how he creates bug bounty reports that get accepted as well as other golden nuggets of advice to learn and grow your penetration testing skills.
Listen to the episode
S4 E7 · Dive Into Pentesting with BloodtyperWE'RE IN! Podcast · 28 min
Key takeaways
Keep a template of accepted reports Most of Bloodtyper's early denials came from formatting and wording, so he recommends saving the structure of an accepted report and reusing it instead of writing each one freehand.
Recon is most of the work He estimates reconnaissance is about 80 percent of his SRT work and says building custom tools for requests and fingerprinting saved him hundreds of hours.
Sanitize data behind internal AI tools A client's isolated AI assistant returned, in JSON, internal URLs for documents containing words like sensitive, key, or map, because the dataset had not been stripped of internal infrastructure paths.
Blocking one step rarely fixes a chain In FedRAMP environments he often sees teams block a single step of a multistep exploit, leaving the underlying vulnerability in place; requesting patch verification catches this.
Start with networking fundamentals His advice to newcomers is to learn the OSI model, TCP versus UDP, IP addressing, and subnetting, for example through CCNA material, because you cannot test technology you do not understand.
Notable quotes
It's really all about hardening your reporting strategy. That's the biggest thing I would harp on. Reporting, reporting, reporting.
…it's not about the tools that are there. It's about the tools that you can make.
Because if you don't know the technology you're testing, you're not going know how to test.
So blocking one thing doesn't necessarily fix it.
Questions this episode answers
How do you write bug reports that get accepted on the Synack Red Team?
Bloodtyper says to harden your reporting strategy: once a report is accepted, turn it into your own formatting template. Small wording issues can get a report rejected, and others may then resubmit the same bug. Read this section
What was the AI prompt injection vulnerability Bloodtyper found?
Through tailored prompt injection, he got a client's internal AI assistant to print, in JSON, the internal URLs and naming conventions of documents containing sensitive keywords. The client had not sanitized internal infrastructure URLs from the dataset. Read this section
Why should clients request patch verification?
He says many clients never request it, and when they do, fixes sometimes only block one step of a chained exploit. Verification shows whether the overall vulnerability is actually closed. Read this section
How did Bloodtyper get into the Synack Red Team?
He applied almost a decade ago through a written assessment and verbal interview and did not pass, but asked for feedback. He applied again six or seven years later and was accepted. Read this section
What is the best first step for someone starting in cybersecurity?
Build a networking foundation: the OSI model, TCP and UDP, packets, IP addresses, and subnet masks. He suggests CCNA routing and switching material, Hack The Box, and CBT Nuggets. Read this section
About the guest
Bloodtyper is a Synack Red Team member and US Army veteran who served as an airborne infantryman, mostly at Fort Bragg, with a tour at Camp Casey near the Korean Demilitarized Zone. After leaving the military he joined Cisco through the Veteran Talent Incubation Program and, at the time of recording, works there as a network consulting engineer for commercial clients. He earned three associate degrees from the University of Advancing Technology and a bachelor's degree in network engineering.
Hello and welcome to the latest episode of WE'RE IN, the Synack podcast. I'm Josh Mason, one of the, solutions architects here at Synack. And today on the episode, we've got one of our Synack Red Teamers, Bloodtyper. Thanks for joining us, man.
So a lot of people know what Synack does, that we do penetration testing, but often it's some mysterious face behind the console. And appreciate you coming out and sharing a little bit about yourself, little bit about your background, so people can know, you know, who's on our team, who's actually doing these pentests. Now, you and I have a similar, but different background. I used to be a pilot in the air force. If I ever dropped you off anywhere, that was not fun. I'm sorry about it. But what was, you've got a military background as well.
Yes, sir. Yeah. Yep. Yep. I was in the primarily a lot of my locations. I did most of my time down at, Fort Bragg here in North Carolina. But before that I did a year and a half stint, out in South Korea down at Camp Casey on the border there on the DMZ so that it would be. The DMZ is pretty much the Demilitarized Zone, and that is kind of the border that separates the two countries. But it's hilarious that you actually mentioned, sorry if I jumped anywhere they didn't wanna be. My last jump, none of my shoots actually properly opened. So that that was that was fun.
No. So what kind of Right. Led to kinda even joining Synack in of itself? I mean, I've always had a a interest or an aspiration towards technology computers only because when I was in elementary school, we were the first school to get something called MLTI. So Maine Learning Technology Initiative. And it gave us access to clamshell Apple computers back in the day. Now the ones you could bash against the walls and nothing would happen to them. Right. And, I was just tinkering them with them and my interests kind of just never went away. And then it worked up into middle school, you know, getting myself into trouble and computers were kind of like my safe haven someplace I could kind of do anything I wanted to, as long as I found a healthy place like Synack, for example, to kind of tailor those passions I had towards technology.
And for me, that kind of kicked in kind of the bug aspect or the vulnerability part in high school where my technology teachers kind of noticed, you know, Hey, he does terrible in all his classes. He's bottom of everything, but he excels in this one area. Let's see what happens if we feed that. And so before, after school, during lunches, everything, I'd be chilling with the tech department, telling them how to break through Windows 2,000 images and the stereotypical story you might hear about, Oh, this kid changed his grade. Cool. How did he actually do it and how did he get in? I would be the person that would do that to help our tech department. That's kind of where the whole thing never kind of changed. It's always been there. So it wasn't necessarily a career change in of itself. It was more just going after the passion I had since I was a child.
the kinda answer, how did I get from the military specifically to say the tech sector in general, not necessarily just Synack. Because before, when I was in the military, you know, door kicker airborne infantry guy, diplomacy, Iraq, all of that. They had an amazing transitional program, which I was surprised about because, you know, sometimes you'll hear a lot of negative things towards the transition process for veterans. I guess it just depends on the installation you're at. But I got lucky at Fort Bragg through their transition program. They had a new thing called VTIP at the time. It's a veteran talent incubation program, and that was through Cisco systems. And I was like, I'll try it, you know, going from a grunt to tech and never actually tried anything in the professional sector, civilian job sector, you know, just stuff from when I was a child.
And I was just trying to see if I had a knack for it still. And I ended up making it through the whole program and kinda got my C C yeah. I got my CCNA round switch through that program. And then I ended up sticking with the government sector down at Cisco. And I did that for several years, and now I'm still a network consulting engineer with them now in the CX space for commercial clients.
Always has been. Yep. So actually, it's funny. Before I was even done the VTIP program, I was hunting because I never officially looked for a bug bounty platform in of itself. Right? I never even really knew of it. I knew of DEFCON. I knew of Black Hat conferences. I knew that stuff. Wasn't too familiar with actual, the ethical hacking perspective of it to report vulnerabilities to companies like Synack does. But before, like I was saying, before I was done VTIP, I found Synack and I actually did the old, old interview process with them about almost a decade ago. Unfortunately I didn't pass that one at the time, but I don't necessarily remember who interviewed me, but they gave me good critique. I asked them specifics, you know, what, what was wrong?
What could have been better? What needs to be known? You know? And they gave me good, valuable feedback. And I came back again like six, seven years later and I got in. So I just didn't stop. I kept pushing for it.
yeah, one of the things that we do differently here. I know I've got a account on Bugcrowd and HackerOne from, you know, when I had the idea of going and doing some bug bounties, but I'm not clear to be on the Synack Red Team, ironically. I need to go through the whole process even as a solutions architect here. My boss has asked if I wanted to get my hands dirty, I can, But I have to go through the process still before I can touch anything. Back then, was it through the hack the box route? You finished these pathways and then you're able to interview or?
Nope. It was a, written assessment and verbal interview, within some other, either solutions architect or another pentest or analyst security analyst at Synack. It was more of a open board kind of form back and forth plus a written portion as well prior to that interview.
Yeah. Definitely a lot more old school than it is now. Now it's strictly all no no talk, no conferences, no meetings, just straight prove your skills, and then you're good.
Yes. It's definitely more convenient now and definitely more informative if anything. So a lot of people are familiar with practicing on Hack the Box prior to coming or trying out for Synack. I think that's where a lot of people kind of hone their skills in a sense to try to stay up to date on stuff. Because more or less, I noticed, especially this past year, some people have different opinions on this, but I feel hack the box has gotten better on making certain CVEs or, advanced persistent threat actor scenarios, related to their boxes. So it's more up to date. So you're better apt on the technologies of today, really. They're not super outdated like they used to be when they started. Yeah.
When like five. Yeah, exactly. Five, six years ago, or Hey, the Metasploit framework just came out, you know, stuff like that. Back when people were grinding custom scripts and their text editor to paste over into the CLI nonstop. It's not like that no more. So I, I kinda liked that. And I think that helped a lot with the interview process too.
That's huge. Does it feel like it, aligns with how you're turning in vulns and how you're finding stuff when you're on missions? I don't wanna get too much proprietary.
Or the... And the testing to become part of the Synack Red Team. I know a little bit of Okay. How Vones are reported for SRT members is different than how a bug bounty report might get turned in and you might get rejected from things because you're like someone else has already reported the same bug,
I'm but you don't know about glad you brought up the reports piece specifically because the big, me personally, the biggest headache I had when joining Red Team and even getting vulnerabilities denied was actually the reporting aspect. Because up to getting into the Synack Red Team, there's no, like somewhere in my situation, right? I've never done an official report. I've never done an official submission. And then when I get to a reputable company like Synack, I didn't know the ins and outs or the specifics on how to do it. Yes, there's formatting in the reporting, but what specific details are you needing as a prereq for it to get accepted? And as you know, sometimes there's the back and forth depending on who's reviewing and who's submitted.
I've seen it at Synack, I've seen it before when I was working with pentesting companies. I did a lot of cleanup on reports before they went out to clients.
It's really all about hardening your reporting strategy. That's the biggest thing I would harp on. Reporting, reporting, reporting. And once you get something accepted, you create a document formatting sheet yourself. That way you have something to reference from a standard that was accepted. Don't just freehand it every time you got to do one because just certain verbiages or anything can get that kicked out the door. Once that's rejected, you know, analytic hunters might see that got rejected. They'll look at it themselves and report it on your out of vulnerability report just because they're better at doing the type ups. But that's what a huge chunk of my denials is actually the formatting and the reporting.
through No, was of that, I guess, to kind of go back to what you wanted. I wish there was more of that leading up to joining. A valuable feedback. Maybe even part of the interview process or even part of the, even after, say, you just get in and you're doing your onboarding training within the company, maybe adding that as like a prereq training thing wouldn't be terrible prior to actually getting access to the platform.
And that that that would that would save a lot of headaches for the VO and the reviewers and everybody else because if everybody was on the same page, a lot less denials, lot less headaches and arguments.
You said the VO. I know if I've done a demo, I've talked about Vulnerability Ops. But Vulnerability Ops for our viewers, listeners, after Synack Red Team finds something and turns in a report, it's gonna go through vulnerability ops where they validate, they review the report. Sometimes it'll go back for language. Sometimes it's looking to see is this exploitable? Is this valuable? Is this something that we need to send along to the client? And it's another human being with experience who's been, that's a full time Synack position. And I know a bunch of our VulnOps folks. Their job is to make sure that we're sending quality to the clients and, you know, working with our SRT members to make sure that they know, you know, what's valuable in the long run and help in that process ideally.
It's a little different than sending off a report to Microsoft or to Google and being like, I don't know. We will see if they like our bug bounty or not.
Nice. So you, you got into, the Cisco program and also at the same time, we're doing SRT stuff. Since then, you've grabbed a couple degrees and some certs along the way. You're kind of a...
when I got out of the military, like a lot of us, right? I like to say for most veterans, when we get out, we find our niche. So me was technology in this example. I like to, as I joked around with my wife, I like to keep the same work ethic in the get go while I still had the motivation freshly out, you know, still had that go get it mentality can deal with low sleep and just deal with the suck. To be blunt. So I kept that going for at least a several, like about four or five years, just grinding, sleeping like five, four hours a night for several years and just full time student and just knocking out the certifications, the huge college that I ended up liking because they're per their.
I guess their technology that they had access to at the time remotely specifically. And the professors, were real good with remote learning was, University of Advancing Technology. And I was able to get three associates there to kind of get a baseline, understanding of where I wanted to go. And because I was just started, I was less than maybe three years at Cisco at the time. I wanted to keep growing the foundational because everything's off the foundation. Right? Need a good foundation before anything else across the board. So I got those three associates in, forensics, cybersecurity, and don't, and AI, I think was the other one. And I ended up getting my bachelor's in network engineering because that was my day job at Cisco Systems.
And once I got that good foundational knowledge, then I started granting off the certifications, the hack the box to stay relative on a bunch of stuff and to kinda build my knowledge set on that to help with SRT work.
Yeah. Yeah. Very cool. What's been one of your biggest lessons on this path that you'd like to share with people who might be interested in getting into cybersecurity or becoming part of the SRT?
of a big one. It's a... It is a big question. So I will say, I'm just gonna say, let's when I first joined Synack, you know, I'm efficient on a plat, my first bug bounty platform that actually has some type of structure communication, a nice community. And I think the biggest lesson I had to learn upfront was it it's not about the tools that are there. It's about the tools that you can make. So by that, I mean, customer reconnaissance based tools for simple curls and gets and posts and something that can scan the overall architecture for fingerprinting of metadata, things along those lines, because it, it will save you. For me, it ended up saving me hundreds of hours. As someone who was kind of lost initially first getting into the path, I wasted a lot of my time looking for things that weren't relevant, and I didn't know they weren't relevant at the time.
So I would say it goes on me preaching on that found the foundation is everything. I had the knowledge set. I didn't have the foundation for the tooling, and that was the gap I was mixing, missing. So if I was to say anything is don't rely on the tools that are readily available to you. It's to truly learn the tools from their foundational level and then build your own. That... That's what I would say. Because a lot of people miss the tooling aspect because recon is, I like to say, a good 80% of what what I do at SRT.
So there was a client who wanted to build, I believe it was part of the black box process, right? Keeping it isolated from their actual production environment, but they created an AI instance where you could basically ask any question about, sorry, I'm trying to think how I can word it here. It was basically an internal AI instance that you could just basically, ask you questions and it would give you answers back off their specified dataset that they pre programmed it with. And the Regex injection I was able to do, I was able to force it to via prompt injection. So I had to tailor prompt, see how it react back and forth, but I had it print out to me in pure JSON format.
The internal URL structures for any, any document that had any type of sensitive keyword in it, like either the actual word sensitive or the word key or the word map, because you know, everyone likes maps on networks or passwords, etcetera. And it printed out. And then what the result was, because once again, remember this is all production. They created it internally and what they failed to do is they failed to sanitize the internal only infrastructure URL dataset from where those documents are located. So I was able to see the actual internal URL locations of what sensitive documents they, that were in that AI instance.
So what they separated from the production environment, I was able to see what their actual internal, in a sense, special VPN access, special key, etcetera, etcetera, that I would need access to even access that URL, but I was still able to get the naming convention of it, the actual URL of their internal production environment, and what was in those documents. All via JSON.
For someone who... The way this would... Could be weaponized if someone else was to find it, like a insider or someone who gets access to the network and has access to this AI at all, then they'd be able to replicate those same exact things, before.
Yeah. I actually did one yesterday, yesterday evening. Nice. It was for a, the biggest thing I'm finding now is in plain static, on a plain static page, people are leaving their API environment pathways open. A lot of times they don't think, Hey, it's just certain keys, or it's encrypted. There's always ways to decrypt stuff. And then if you have an access key and it's not blatant what it is, or, Hey, it's just a test environment. Anyone can always use the AWS CLI and use a callback identity and see specifically belongs to, and they'll tell you how to actually approach enumeration further to break access into that account.
Wow. When I'm on a sales call, I often tell people about patch verification and the fact that if, you know, a vulnerability comes in, they have their team work on it at point where someone in this situation like on the cloud dev team, might say, yeah, we've we've patched that. The client can go in and hit a patch verification button. I, you get a notification on your side of the portal saying, hey, this is to be checked. And then you go in and see if you're able to redo what you... The process when you found it in the first place.
Yep. Yep. And yeah, that's, that's fairly accurate, but I will say about 80% of clients don't actually patch. They'll request to patch through us anyway. And I will say only in my experience, I'll say specific to the FedRAMP space, a lot of times if there's a multistep process into how we got to say high privilege read write, as an example. And it was a multistep process to get there. Sometimes we didn't necessarily need every single step in there to get to that high privilege read write. So they'll just internally in their team say, Oh, I'll just block off this one piece. But that doesn't necessarily get rid of the overall vulnerability in the chain that we did to get that high privilege read write.
And when they don't sometimes request those patches, that might be the case for a lot of them. There's no way to know because they never requested a patch through us. But if they did, I will say sometimes that they won't properly patch them. I have seen that. And that is the benefit of them requesting us to validate a patch. Yeah. Because their teams internally might have thought if we block this one thing, we're good to go, but a lot of times they're not. Especially if it's a chained chained based exploit, you know, we don't necessarily need every duh, every single step to get to it. We were just showing you our workflow on how we got there. So blocking one thing doesn't necessarily fix it.
And that's valuable then that they can come back multiple times and verify if it comes back now, we're still able to reach it for this reason. That's great feedback for them.
So I wish clients, especially in the FedRAMP space. Yeah, exactly. Right. And that kind of is what I'm I'm talking about. They, I wish they more clients specifically in the fed space request patches more to kind of hard, make sure their environment's properly hardened instead of assuming that they're good.
gap right there. Very interesting. Something to take to my CSMs and my TAMs, Those who are dealing with the Fed space. Excellent. Man, thank you so much for joining us today. Is there any last piece of advice that you would give to anyone who's starting into cybersecurity? Red Team, Blue Team, GRC, sales. I don't know. If someone were to come to you and say, hey, I'm getting out of the military or I'm getting out of high school and very interested in cyber. What's one piece of advice you might share?
I think I'll go back to what I've been saying the whole time and where I started. It starts with a foundation. It really, really does. And if they, it depends where their knowledge is with technology, I would say get familiarized with the OSI models. You know, what's TCP versus UDP. Start at the very basic. What's a packet? What's an IP? What's a subnet mask? And get familiarized with that. And I'd like to say the CCNA routing and switching certification exams through Cisco Systems really gives you a broad overview of all that. And if you don't think you're up for doing the full CCNA, you can do... You can do partial just for your own knowledge set. You need a strong networking foundation before you can work up to the SRT aspect. Because if you don't know the technology you're testing, you're not going know how to test.
It's true. It's true. And maybe it's my opinion or my view. I I don't think it's that hard to to learn that stuff if you get the chance and the opportunity to to see it. But it is usually foreign to a lot of people, and it's not something you can just skip. I'm with you on.
Right. Yeah. And, and once again, Hack the Box is an excellent resource or if you're doing network engineering aspect, like I said, to get that foundational knowledge, CBT Nuggets is always a great resource as well.
