Exploit Development, Agentic Vulnerability Discovery, and Fake PoCs
Welcome to the Practical AI Podcast, where we break down the real world applications of artificial intelligence and how it's shaping the way we live, work, and create. Our goal is to help make AI technology practical, productive, and accessible to everyone. Whether you're a developer, business leader, or just curious about the tech behind the buzz, you're in the right place. Be sure to connect with us on LinkedIn, X, or Blue Sky to stay up to date with episode drops, behind the scenes content, and AI insights. You can learn more at practicalai.fm.
Narrator:Now onto the show.
Daniel:Welcome to another episode of the Practical AI Podcast. This is Daniel Whitenack. I am CEO at Prediction Guard, and I'm joined as always by my cohost, Chris Benson, who is a principal AI and autonomy research engineer. How are doing, Chris?
Chris:Hey. Doing great. Going. Going. Going.
Chris:How's it going?
Daniel:Going. Going. Going. I mean, Chris, it seems like every day we're hearing about something like this, but today also was a was a was a doozy, I guess. You know, we...
Daniel:I I saw Wall Street Journal article saying, you know, AI discovered, exploit that affects 7070% of the web. Right? So this is happening, I guess, as we're recording this October 21. So we're hearing about this all the time, and, it conveniently happened that we had scheduled to, talk talk with us today on the podcast, the director of Exploit Development at Vulnerability, Spencer McIntyre. Welcome, Spencer.
Spencer:Hi. Yeah. Thank you for having me.
Daniel:Yeah. Definitely. Well, I I know, you know, today's today's events, we may not be able to, go into detail because we're still learning all the things, but it is evidence of something that is on the top of everyone's mind, which is how AI intersects with this world of cybersecurity, particularly around discovering exploits, developing exploits, the offensive defensive side. Excited to dig into some of that with you today. But our audience maybe isn't coming from not everyone's coming from a cybersecurity background.
Daniel:Could you help us understand, you know, a little bit about your background, how you fit into this world? People might find the director of exploit development title rather interesting. So just to help orient us kind of where do you fit within this world? What are you what are you doing right now with Vulnerability? That that sort of thing.
Spencer:Yeah. Absolutely. I was really excited when they offered me the title of director of Exploit Development. Pretty awesome. I thought that was pretty cool.
Chris:That's a pretty
Spencer:cool I've always been really passionate about exploits. So that's kind of actually how I got into the information security industry. So my background started out in consulting, but being very interested in exploit development. At the time, I was under the impression, this was a long time ago, that you really needed to have a strong background in vulnerability research and have a pocket full of O days really to get a job as a pen tester, which I would find out then was not necessarily true and is not true now, but that was what I was told. So that was how I got started.
Spencer:Then after working in consulting for a while, slowly transitioned full time into doing research and development, which really has been my focus over the past ten years. Some of that overlapped with research and development in consulting, which was really interesting because I got to work with a lot of different organizations in the private sector, as well as a few different governments, hospitals, education, retail, hospitality, bunch different things. But then, yeah, I slowly transitioned over to working in research and development full time. I have an extensive background in the Metasploit framework, doing module development and things like that. Metasploit was a big part of it and on my journey of doing exploit development that brought me to Vulnerability, where, as you mentioned, I'm the director of Exploit Development, and I work on the initial access team, which provides the data for our initial access intelligence feed.
Daniel:Maybe just to dig into a couple of those terms, just briefly, could you explain maybe Metasploit for those that aren't familiar? And then what you mentioned at the end there around the particular feed that you're plugged into, what that means in the context of Vulnerability Check?
Spencer:Yeah, absolutely. So Metasploit is a framework for exploit development and penetration testing and vulnerability validation. At one point, it was the second largest Ruby project, I believe, behind Rails. I don't know if that's still true, but it's a pretty large project. It's been going strong for, I think it celebrated its twenty first birthday last year.
Spencer:So a pretty old project at this point, started back in Ruby one point eight, but it was a platform for vulnerability researchers to be able to develop their exploits and share them in a normalized format. And this of course started quite a while ago. The industry has evolved since then and a lot has kind of changed technologies, protocol stacks, way we're doing things, the advent of AI and completely altering our workflows in the past few years, which I'm sure we'll talk about quite extensively, has shifted how things have operated and how vulnerability researchers have approached a lot of these problems. And also we've seen the trend where things have been dispersed quite a bit more. There's not really centralized resources for a lot of this information, which is one of the ways that the initial intelligence that Vulnerability Check provides actually offers value to our customers and our users.
Spencer:It is timely data. One of the things that we really focus on is the speed of how fast we're able to provide this information. And it's a holistic view of the vulnerability, of which the exploit is one part, but we also provide detections and high level understanding of how the vulnerability operates. And then we package that up into a data feed and then provide that to our customers.
Daniel:Yeah. And and you even you even use some some words there. You mentioned, you know, the exploit isn't the only thing. Like, when when events happen like is happening in today's, you know, news cycle, could you help orient people? You know, what what defines an exploit?
Daniel:Like, what what is that, and what is the important context around that exploit that that maybe not the exploit itself, but things that we may use in the rest of the conversation that people just need a a grounding in.
Spencer:Yeah. So I think you, had actually mentioned earlier, that, like, an exploit was discovered, and I wanna have my, like, well, actually card. Yeah. Yeah. Please do.
Daniel:That's what we that's what we need. Consider me the noob and learning along with you.
Spencer:Yeah. So there's nuance in the term that I'm really passionate about because even in medical literature, different contexts or when you're talking from consulting perspective or something like that, people use the phrases differently. So being around for a while, you understand what people mean. But a vulnerability is basically the potential for something bad to happen. And if you really dive into a lot of vulnerability research, vulnerabilities have to be validated.
Spencer:But that line of what constitutes validation and then what would actually be useful by an operator of an exploit that's trying to do something like legitimate testing or a nation state actor or something like that, regardless of what their motivations are, is gonna be typically almost always higher than what the industry would generally consider to be proper validation. That's a good thing. I want to clarify that that's a good thing because that's people basically saying, Well, it's hypothetically possible that this could lead to realistic bad outcomes because we have this hypothetical bad outcome that we've proven. So we're gonna take this very seriously and we're going to fix it. We're going to apply the patch and for things like that.
Spencer:So the vulnerability is really the abstract concept of what the flaw is and what could be done with it. And an exploit is a concrete implementation that leverages that to do so.
Chris:I'm curious to kind of tie in. I've used Metasploit in the past just as a user trying to make sure that my own infrastructure was up to speed. As we look in the last year in particular and see how clearly things are changing heavily in your industry, specifically with things like Methos developing all sorts of insights into vulnerabilities and identifying those and stuff like that, Before we dive into a lot of the specifics, can you level set for us what the landscape is now and how it's evolved into that and what has that required you and people in your industry to pivot on because the world has changed with these AI capabilities that are doing that. It's one of those things for those of us that are in AI but not necessarily in security specifically, we're right on the edge of that and wonder a lot. I was wondering, I'd love to get that kind of general perspective from you.
Spencer:Yeah, absolutely. Disclaimer, I've never actually been accepted for Mythos access myself. I have experience with a bunch of other models, very hands on and everything. But what I've seen actually goes back to that difference between vulnerabilities and exploitation that I'd really like to mention because a lot of the AI models, whether it's Mystos or Opus 55 or what have you, or the OpenAI models or GLM, they seem to be doing a pretty decent job at identifying vulnerabilities. But then where people oftentimes struggle is with, Okay, this is a vulnerability you can look at in the code and you can understand, This is bad.
Spencer:This byte is overwritten, or This token is leaked, something like that. That seems to be where the analysis stops and people take it seriously and they want to go and patch it, but then a lot of these end up getting hyped a lot. I think where there might be a disconnect is what the impact is of a lot of these vulnerabilities. And that's because we're missing that gap between the validation and the actual functional exploit that proves attacker utility. And that attacker utility is what something even a legitimate pen tester or a law abiding citizen would really need to understand because there are so many of these vulnerabilities.
Spencer:As you're mentioning, there are like big ones that came out today. So people are often struggling with is the the prioritization. CBSS is only gonna give you so far when there's 20 CBSS, you know, nine and above. You really need to understand the attacker utility and then take it into context of, like, your business to understand, well, if x y z happens, what does that really mean for me? And that's kinda like where people struggle.
Spencer:So the AI is doing a pretty darn good job of identifying these vulnerabilities. I think the projects where the firms are sharing it so that people can identify the vulnerabilities quicker, but I think there may be a disconnect with what the practical implications of these are in the real world.
Daniel:And does that... Maybe just talk a little bit about that validation step from from your side.
Spencer:How how
Daniel:is it that you get or or maybe maybe just help explain a little bit because people are bombarded by so much noise. Right? And you say, like, things are things are hyped so much. So just, like, practically speaking, I'm bombarded by... Well, like, you know, even today.
Daniel:Right? There's, like, this PHP vulnerability. I'm, trying to use the the right terms now. Right? And it affects all of these.
Daniel:So how do how do I then map that onto my situation from a business leader standpoint or a practitioner standpoint within a company? Like, what what principle wise should be at the top of my mind as I'm trying to parse through that that noise to, well, should I really stop what I'm doing today and and sit down and look at this more deeply? Can I put this on our backlog to investigate at some point? Any practical tips on that side?
Spencer:Yeah, absolutely. I've been through this rodeo a few times where a really big vulnerability comes out, and I just knee deep in it an hour ago, trying to figure out, like many people are. We're trying to figure out what are the constraints upon exploitation, because that's what's really gonna tip it into the barrier of people are going to be able to use it in the wild. Generally speaking, from my experience, you know, being around for, like, React to Shell and, like, Log four j and things like that, my gut feel is that the longer it's been out and it hasn't been confirmed to be overhyped is is generally not a good sign. That that tends to be people have...
Spencer:There there are enough leads. There are enough variables in this that there could be cases where it could be bad. So it's it's very early to say, but my my advice is on this one in particular, like, would take it seriously. I would definitely use the time period we have right now before that level of research is published to go ahead and, like, patch your systems and things like that because so far, it does not appear to be to be overhyped or we're still kind of in that gray area here.
Daniel:Yeah. And and I'm assuming that some of that, like, for for example, in in in our own company, like, we aren't PHP. Like, our our stack isn't written in PHP. And I imagine some of that is just related to whether we use this sis... We use this platform to to run our website and there's a content management...
Daniel:Maybe they're using PHP under the hood. And so, yeah. Is that part of it judging, like, what you control internally and then what you don't control, like, from the from the vendor standpoint?
Spencer:Yeah. Absolutely. I think, ideally, organizations would have an idea for, you know, how many different PHP applications that that, like, they are running. But you bring up a really good point from, like, the vendors that, like, PHP is gonna be running on, IoT devices and appliances and things like that. It's such such a popular language that there are gonna be all these things.
Spencer:And when I was talking about the variables, the variables in the hardware and the builds and the operating systems that are running PHP are going to be much larger because you have all of these different appliances. PHP runs on multiple architectures, like all the IoT space. In particular, you're gonna have all these different potentially older versions of things, things that haven't been regularly receiving patches or were manufactured by a company that is no longer in business because this vulnerability apparently affects back to like PHP five. So it's very possible that there's gonna be some of these and that's what makes it very, very difficult and, is contributing to a lot of noise.
Sponsor:It's crazy to think that we've been doing this podcast for about 375 plus episodes started back in 2018. I can think back to that time, 2018, and it was intimidating to think about entering into this new craft, the podcasting, getting the website set up, getting marketing set up, email, etcetera. But I'm so happy that we, at the time, found the right people to to make it happen, but it was a lot of work. What I love about what our partner Hostinger is doing with their AI builder is that you can go from no website, email, marketing, etcetera, and then actually prompt their AI builder, their agents to help you create that website setup, whatever it is, manage it over time, SEO, website copy, email marketing, that can all be included and driven by and through their AI builder. There's no coding or designer or developer needed.
Sponsor:It's an all in one platform, and I wish we would have had it back when we were launching the show. Plans start at just $3 a month, and creating a website does not have to cost thousands of dollars. You can begin at your own pace and and build from there. Hostinger builds your vision step by step. Create your website today.
Sponsor:Go to hostinger.com/practical and use Practical for 10% off now. That's hostinger.com/practical and use code Practical for 10% off now.
Chris:So I'm curious as we've been kind of talking about AI starting to really have an impact on identifying vulnerabilities, you still have some of the same problems in terms of kind of categorizing and determining the risk near term, longer term. As you guys have adjusted to this, could you talk a little bit about how your own team is implementing AI? What types of activities that using these different models, you just enumerated some of them right before the break, how are they helping you and what are the things that are still very much human in terms of what you're managing and stuff like that? How do you integrate in with the AI to be productive today? Which I guess is a specific question of a more general thing that many of us are trying to find our way through in our jobs.
Chris:I'd love to hear how it's affecting your team.
Spencer:Absolutely. It has helped us quicken our pace with a lot of things. At Vulnerability, we actually utilize our open source Go Exploit framework, which is really nice for this. So Go Exploit is our modern exploitation framework that handles a lot of the problems that we see our users running into with our vulnerability content. It normalizes how you would go through and handle the variances between checking for a vulnerability, scanning for it, validating targets, then of course, like running the exploit and setting up your C2.
Spencer:So having a structured framework like Go Exploit is very helpful because when we're working with the LLM, it's not starting from scratch and we have a very large corpus of a backlog of exploits. It's growing every single day. I think we added, I think it was like 50 last week and we're on track to add like 60 this week. So there's quite a few. So having that corpus and then normalized structure that the framework of Go exploit provides helps it, seems to be providing it with better results.
Spencer:Then from a user's perspective, it helps normalize that interface. That way we know how to interact with it without needing to necessarily worry about the details between the different exploits. Because the LLM and even the human authors as well aren't necessarily having to build all the scaffolding by itself, which has been really helpful. Beyond that and beyond Go Exploit, once you dive into the real details of the vulnerabilities, vulnerabilities fall under certain vulnerability classes. And what we've noticed is that LLMs seem to be pretty darn good at exploiting multiple vulnerability classes and not very good at exploiting other vulnerability classes.
Spencer:Not everything, but a lot of them fall into one of those two buckets. So, for example, we've had a lot of luck using AI and LLMs to exploit open source web applications. So these types of flaws that are logic flaws and how token logic is being handled or expression language injections or file leaks and things like that, it's pretty darn good with those. But when we start getting into anything that's closed source where there's a layer of reverse engineering that has to happen ahead of time because it's like firmware or even closed source proprietary x86 software, those types of things where it has to do like patch diffing, it tends to struggle a lot more. So those are kind of the the two ends of the spectrum that we've noticed.
Daniel:And I'm wondering, you being on a team that's obviously looking at and developing exploits, you know, and and using AI assisted methods to do that. There's a lot of things that we hear, you know, from not being in your position that, I'm curious, like, how how much of a of a problem they are in the sense that, like, for example, with the OpenAI Hugging Face case that it talked about how the Hugging Face team, you know, when when we looked into that, they they couldn't, you know, process all of these logs associated with what they were seeing back to OpenAI because of... They weren't in sovereign control of the OpenAI guardrails. Right? So they were getting blocked from doing certain things with that, you know, third party API.
Daniel:And so they hosted a version of GLM to do this analysis and that sort of... So that that just being one example. But I'm wondering about this concept of, hey. I'm a team. I'm actually developing an exploit or working in research from a positive perspective.
Daniel:Right? I'm not a nation state actor trying to exploit something maliciously, but I'm doing this for a positive purpose for a legitimate reason. How, are there ways that you're handcuffed now in terms of the AI tools that you use? How do you how do you navigate this sort of guardrailing aspect where you can use a tool openly to do things that are legitimate? But, you know, obviously, I I understand being, you know, providing software or, you know, myself as a...
Daniel:The company that I lead. I understand why a company wants to put in the appropriate guardrails and put in their own... Especially if they're a SaaS provider they're offering a managed platform. How do you navigate this as a team and what are the real blockers that you see? What's inbounds and out of bounds for you?
Spencer:Yeah, that's a really good question. The guardrails are definitely a thing. So we try to navigate it first and foremost by following the formal processes with the companies to get into the cyber verification programs and things like that. We do do that. The results aren't great.
Spencer:They don't really seem to change much of what we're able to do. I also have my own personal cloud subscription, and I'm learning about particular exploit primitives and things like that, and then CTFs. So I kind of get a feel for what types of things is gonna be like, No, no, no. Know what you're doing. That's dangerous.
Spencer:And I compare that to what it's at work. I'm like, It doesn't really feel like it's doing much better. In talking to a lot of folks, they've had similar experiences. The trends in the guardrails definitely seem to have gotten more strict. If you talk to anyone in offensive security research, basically the answer is if you're using one of the American proprietary models, it's to downgrade it.
Spencer:That's the thing. So I'm kind of worried about, I think Opus 4.6 or 4.8, which is pretty darn effective. There seemed to have been a cliff in how helpful it's gonna be after those versions are gonna be sunset in February or something like that's coming up. So that's gonna be interesting. A lot of shops, I think, are preempting that and they're moving towards local models.
Spencer:Even Anthropic, I think a few weeks ago, basically came out and said that they benchmarked GLM 5.3, which can be run locally, except that's open weight, was doing, I think it was 90% as good as some of their frontier models, and it was released three or four months. They were framing it of how it's so dangerous and everything, which, yeah, that's great because we need to protect ourselves from people that aren't law abiding and aren't going to do this to help folks and publish research for people to defend themselves, but I think what's really difficult for a lot of these guardrail conversations is proving intent. But that's been a problem that we've had in the security industry for so long in general. You can pretty much talk to any person in threat intelligence, and a large part of what they're trying to do is, Well, they know the attack was run, but it becomes much more difficult when after you've attributed it, you're trying to figure out what are they trying to do. Is this just for politically motivated?
Spencer:Are they looking for money? That type of thing.
Chris:So I'm curious, as you've kind of dived into some of the different model choices and stuff, and I'm certainly coming from national security side of stuff, and there seems to be kind of a choice if you're in security in the West in general about kind of dealing with these various guardrails on... Because there's a lot of legitimate work that is offensive and defensive, both. So you're dealing with guardrails on one side with American models, mostly proprietary, but then on Chinese models, if you have that, that's generally not allowed in national security context, but if you're in a larger security world, then is the concern about having things like poisoned weights and the other concerns, whether they are real or fabricated about Chinese models, how do you, as a researcher out there doing this kind of work, how do you balance that of saying, Well, there might be more trust guardrails versus the, What am I dealing with in the open source world from the East? So any thoughts about that?
Spencer:Yeah. So a lot of folks are recommending GLM, in particular, GLM and Quinn. Someone was just telling me, Oh, you should be using GLM yesterday. And much kind of like you, I'm like, No, I can't really share the data that I'm working on. I'm not working in the national security space, but I can't share my data with anything else.
Spencer:So I see a lot of places that are trying to pull them internally. I haven't actually heard of anyone expressing concern around poisoned weights. In fact, some people have even been talking about, was it abliterating? So they're editing the weights themselves to make them even more dangerous. So, I haven't heard anyone talk about this, but I would assume that if they're looking at the weights and they're benchmarking based on that, they would probably find if the weights weren't already there in the direction that they wanted to, because they're already in there looking to edit it.
Spencer:That would kind of be the same with source code. If someone is going in and patching things, then it's much more likely that they would identify if there was an issue already embedded within it. I think a much more immediate concern would be if you're using the hosted models models yourself, because of course all of the data is being shared up. I think there's been instances where one of the closed source models was uploading all of the repositories and they ended up getting found on an S3 bucket type of a thing. And that's what they've accidentally shared and published, but you don't necessarily know what they're doing internally with them.
Spencer:And so from a researcher's perspective, especially when you're working on these up and coming vulnerabilities, I think that the real question is, are you comfortable sharing this information with who you're trying to get help from in terms of the LLM? And so a lot of people just just don't wanna deal with it, and they'll they'll host it themselves.
Daniel:I'm wondering just to kind of tie in to some of the use of of AI in exploit development, I I was really intrigued by some of what Vulnerability had published around kind of fake or AI generated, POCs of of exploits. The... And we can link this in our show notes. There's obviously, like, a lot. This is probably a a few few hours or days conversation in in and of itself.
Daniel:But I'm wondering if you could help us understand what what is the idea of this? What does POC mean in this context? And why may this be... Like, what sort of problem is this or what effect is it it having maybe is a way to frame it?
Spencer:Absolutely. Yeah. No. It's a it's a great question. So when we're talking about vulnerabilities being the theoretical flaw and the exploit being the real concrete implementation of it, a POC is somewhere in between.
Spencer:It gets to be a gray area, and some people will use that term a little bit more interchangeably. Sometimes a POC is just going to cause a crash, and that would validate the vulnerability, and like I said, a lot of people will take that seriously, and they'll apply patches and fix it as they should. I don't wanna discount those efforts. But other times, sometimes POCs will be fully weaponized, they call it, and actually deliver a payload that does something useful for an attacker. So I'm not really sure about the motivations of a lot of people that are publishing the POCs.
Spencer:I think there's a huge variety of them. I think there are some that are just doing it for clout and fame and glory, and I think other people are genuinely interested in learning, and they wanna share what they've learned. Other people have actually found the vulnerability, and so they wanna share a POC to prove their concept, which is where that acronym of course comes from. Tying it back into Vulnerability, one of the things that we do as part of initial access intelligence is we review all of the POCs that we can identify by CVEs across GitHub, CodeBurg, GitLab, and I think a couple of other sources. We look at all of them.
Spencer:We look at them every single day. Something like the PHP to Shell one comes out, basically, have a subsection of the team that's trying to work on the exploit ourselves while other people are going through what is out there in the wild and validating is this legitimate or not because our customers care about not only do we have it and can we provide it to our customers, but they also care about what does the other guy have? And so we're keeping a very close touch on the pulse of what is going on in the open source community. I had alluded to the fragmentation of the distribution of security research over the past ten years, and GitHub has contributed to that, where what we're seeing is a lot of POCs are being dumped onto GitHub as opposed to going to the old school, more centralized forums like Exploit DB and PacketStorm and things like that. You can still find those.
Spencer:Most people are just pointing them up on GitHub because why wouldn't you, unless Microsoft bans your account? Because that's a thing that happens sometimes. So, yeah, we are looking through all of those. We, at Vulnerability, actually just hosted ThreatCon one. It was our second ThreatCon a couple of weeks ago, and one of my colleagues gave a talk about this analysis we do on all of the open source public POCs, and he shared something I thought was really, really interesting.
Spencer:We categorize them internally as whether or not we think they're AI generated or not and whether or not they work. Removing the dimension of data about whether or not it was AI generated, what he pointed out was that with the increase in POCs that we're actually seeing, we saw a tipping point in 2026 where the average number of POCs that looked illegitimate for one reason or another, most often they're broken, they don't quite work or meet our standards for doing something worthwhile, tipped to over 50%. So what we're seeing is that today, your average POC that you find, it's probably not what you're hoping it would be, where it's actually going to truly leverage the vulnerability it says it does and prove some kind of attacker utility.
Daniel:This is this is so intriguing by, you know, some of what you had mentioned around the... This tipping point around POCs, how how AI is obviously con... Contributing to that or or a portion of what's contributing to that. I'm wondering just to switch directions just slightly, there's, you know, how exploits are developed. Obviously, you're on a team that...
Daniel:That's looking at that. There's these POCs that are out there. I'm wondering about the the kinds of vulnerabilities that may be net new or maybe they're just... They're the same as other vulnerabilities that we're seeing in the actual AI stack. So we have new things, like whether that's agent harnesses.
Daniel:Right? Whether that's Cloud Code, OpenClaw, Hermes, etcetera. We've got, obviously, model serving frameworks have been around quite quite a while. We have workflow development tools like DAG pipelines that you can build with with AI tools and even some of these integrated into larger platforms like Workday or others like that where you can build these automations. I'm wondering in this kind of new realm of the AI stack, however you define that, the...
Daniel:These kind of net new things we're dealing with. Are there unique types of types of things that you all are considering as a part of these platforms that you didn't have to consider before, or is it just sort of more of the same, in terms of how how these things can be can be exploited or vulnerabilities associated with them?
Spencer:So you're asking about vulnerabilities within, like, the AI stacks, not how the AI stacks are being leveraged for vulnerability research? Yeah. Okay. Okay. It's been kind of a lot of the same, I think.
Spencer:A lot of the newer ones that I've seen have been, they're almost always interpreted languages because by the nature of AI having been released within the past couple of years, you don't really see a lot of people writing AI code in like, for these types of things that have a remote attack surface, you don't really see a lot of them being written in like C, C plus plus or even like a Rust. I'm sure they exist, but they're probably the lower level components that don't necessarily have an attack surface that a remote attacker would be interested in. And a remote attacker is what we're going to be focused on a lot at VulnerCheck and Initial Access, because that's that initial access component of it. So we look at a lot of web interfaces, distribution frameworks, and things like that. So we're seeing a lot of the same kind of vulnerability classes that we've seen in the past where there are logic flaws, where files can be read, deserialization flaws, logic flaws in how accounts are being registered and access controls.
Spencer:So there would be a really good overlap with a lot of the flaws that have been in the OS top 10 historically over the past ten years, we're just starting to see them more in bulk.
Chris:I'm curious. I'd like to actually flip it over to the other side of that equation and talk about leveraging the AI stack in that way. Something that I have seen lots of are the notion of agent swarms, and we saw that clearly in the OpenAI hugging face attack. I think that in certain areas the notion of agent swarms are becoming more and more common. Any thoughts?
Chris:What does that mean for the leverage of an exploit? Aside from finding a vulnerability, let's say that you... Or potentially... It's kind of a second half of that, or potentially using agent swarms to find vulnerabilities in real time that are then exploited in real time, which is to some degree, as I understand it, kind of what happened in that OpenAI situation. How do you think about that as researcher, and how should we, us non researchers, non experts, think about these possibilities as we are thinking about protecting our own organizations and stuff going forward?
Spencer:Yeah. I think there are a lot of similarities actually in my mental model of how I think about it with fuzz farms from a long time ago, in the sense that it was a scaling problem where you have a 100 nodes fuzzing Chrome or something like that, you're going to find presumably that many more bugs. Similarities also carry over into what I'm seeing a lot of research shops talk about is they're home brewing their own harness and their own prompts and things like that because everyone assumes, much like they did in fuzzing, if you use an off the shelf fuzzer against the product that everyone else is fuzzing, like Open S Sage or something like that, you're probably going to find the same So, are assuming they use an off the shelf harness with the exact same model. There's more entropy going on there, but I think a lot of people are being encouraged to develop their own, which has been great. The similarities end there because what we're seeing and how the industry is moving more in a quicker direction is that nowadays with the AIs, it provides you with a better understanding because once the vulnerability has been identified, it's kind of removing that first line of triage.
Spencer:Of course, it's varying degrees of quality depending on your controls and model and whatnot, but it's gonna provide you with a good degree of analysis of, is this exploitable? What is the bug class? How did we get here? That type of thing. I haven't seen evidence that full on wide scale exploitation is where we're currently at.
Spencer:But having said that, I would be shocked if the answer isn't different in three to six months because these things are just constantly going on. That's what's really interesting about all of this is anything I say now is probably gonna be outdated and really needs to be taken into consideration in a couple of months.
Daniel:Things are Absolutely, moving
Spencer:astronomical pace. So yeah, I think the agents are really helping with the analysis capabilities, and they can even build the POCs to be able to go back and re trigger the flaw, which are all leaps and bounds, what we used to have to do manually. So it's really speeding that up. And then in certain cases, kind of going back to the vulnerability classes that's really good at exploiting, we can get it to the point where it will create a POC or a fully weaponized exploit that we would consider to meet our bar for quality, but it's not quite reliably there for certain classes.
Daniel:Yeah, that was gonna be my follow-up is just clarifying. So if I'm understanding right, are you saying, because you had talked about these classes of vulnerabilities previously. Right? And and AI is doing really good on certain of those categories. And so is the fact that...
Daniel:If I'm understanding right, you know, AI AI found vulnerabilities aren't necessarily exploited at higher rates or with higher impact than human found ones at this point, or is that true or not true? And is that partially related to this fact that AI models are really good at only certain of these classes and haven't quite made the progress with the other ones?
Spencer:Yes. I I would say that it's safe to say that today, AI is not as reliable at exploiting them with the same impact as humans, because humans, first of all, they're gonna be motivated for looking at the vulnerabilities. There are people out there that look for vulnerabilities just for funsies, but by and large, a lot of people have some kind of a motivation. They need to look at a particular application because they wanna know, can an attacker get in or something like that? They have additional context in terms of what the impact would be, and they use that as a point that they wanna get to.
Spencer:It's almost always gonna be code execution, and so I tend to see a lot of the more human curated exploits that have been developed are much more mature in their utility for what a real world user could use. Whereas in my experience, a lot of the AI exploits will drop it as like, This is a crash that's theoretically exploitable, and they try to push it. You know, it might veer off and and go in a different direction that's not quite as as beneficial for what a human operator would need.
Daniel:Yeah. So maybe if I'm kinda merging two two of the things together, if I'm if I'm understanding your points correctly, You could have, let's say, a a team of agentic researchers that are, like you were saying, almost acting in that fuzzing sort of capability. Maybe even if you have your own harness, you... That's doing it in a in a unique way. And so you have this very wide set of things that the agents are looking at and they...
Daniel:You know, maybe to be most effective in in your role, you could use that capability to then identify things and filter them down to human experts to to maybe increase the utility of the exploit or the the impact, etcetera, and, you know, or prove out the POC, make sure it's not broken, that that sort of thing. Would I be understanding that right if I'm like, let's say for those out there that are maybe in in the research space or interested in the research space and want to use AI in a useful way, would that be roughly a reasonable way to think about it?
Spencer:Yeah, absolutely. It's boiling that information down until it gets to the high level of, once the vulnerability has been identified and you know how to trigger it, and the AI might even know a little bit about what you can do with it. Just certain classes, it struggles with getting to the point of, what can you do with it? What does attacker want? And then that intersection there.
Chris:So as we start winding up here, it's been a fascinating conversation. It's really, really interesting. I guess one of the things that we tend to do at the end is we kind of ask people to wax poetic a little bit about what your thinking is. It's kind of like the going to bed at night and you're thinking kind of freely, taking the shower, your brain goes wherever you want, that kind of stuff. Can you talk a bit about where you think things are gonna go?
Chris:And you can choose whatever timeframe you want, but I'd love if all of us are getting a glimpse into the mind of you as a security researcher when you're kind of free association thinking, Where does that go? What does that look like? What does your future look like that you're anticipating and preparing for? And of the things you may be thinking about, what do you think is super cool and stuff? I just love to kind of finish off that way.
Spencer:Yeah. I'm pretty optimistic about things that are coming up because things are getting faster and better, of course. But what that has meant for me as a researcher that's trying to help people and trying to produce information to allow them to make better and more informed decisions, speed is really important. A long time ago, attackers don't play by the rules, that's the definition of it. So, they would have this advantage where they can spend an undetermined amount of time to develop a vulnerability and they can release it by using it and harming people.
Spencer:And so there'd be this window where it's actively being used and people that are trying to like patch it and and defend against it are having a harder time like understanding it. So like one of the things that we're seeing is that we're able to run through that process a lot more quickly. So we are reducing the value that they're getting out of all that effort, which I think is a real good thing. We're able to react much more quickly when there is a variable or a new vulnerability that comes out. So that's been really great.
Spencer:I'm curious to see on the less technical side, some of the legal implications of some of these things. One of the things I really want to know about, I'm genuinely curious, is as you read about these texts that take place in the news where someone asked Claude to do X, Y, and Z, and in order to do X, Y, and Z, it owned this website or something like that. I think I was reading an article where someone wanted to get into a spin class, and Claude exploited a SQL injection vulnerability to bump him to the top of the queue. Just not great, but I'm really curious to know where the precedent is kind of be set in terms of who's responsible for those types of breaches. Because, like, I think we all kind of have our opinions, but, like, I wanna see, like, how it actually, like, shakes out in the courts.
Daniel:Well, hopefully, some vulnerabilities can get me back in my exercise routine. I I I I a little bit of help there. But, yeah. That... That's awesome, Spencer.
Daniel:Thank you. Thank you for taking time to chat with us on a very eventful day, in in in in the world that we live in, and the cyber world. So, yeah, appreciate it. And we encourage everyone to check out what Vulnerability is doing. We'll put some some links in the in the show notes.
Daniel:Just amazing work. Thank you so much, Spencer.
Spencer:Absolutely. Thank you for having me.
Narrator:All right. That's our show for this week. If you haven't checked out our website, head to practicalai.fm and be sure to connect with us on LinkedIn, X, or Blue Sky. You'll see us posting insights related to the AI developments, and we would love for you to join the conversation. Thanks to our partner Prediction Guard for providing operational support for the show.
Narrator:Check them out at predictionguard.com. Also, thanks to Breakmaster Cylinder for the beats and to you for listening. That's all for now, but you'll hear from us again next week.
Creators and Guests
