Like, where else though, outside of your use cases, where else do you think it's useful?

Um, I, I, I think, like from a vendor perspective, I would say like it's really useful, like, you know, a customer will say, "Hey, can you guys do this?" And, and the an- and as, as a vendor, if you can say, "You know what? Great idea.

You can build it yourself in Foundry, and if AI makes it, you do it quicker." When we first looked at the Foundry integration, you know, 12 months ago when it was sort of brand new, we weren't using all the, you know, agentic AI coding and such, and they didn't have all the skills, and it was quite difficult.

You know, there was a lot of JSON files, a lot of definitions and stuff like that.

Um, and we got some minimum viable integration going.

It was sort of okay.

Um, but compared to now and what we've done in two weeks, [laughs] you know, last time we would've spent two weeks just connecting to it and getting it up and, you know, getting it say, "Hello, world," and now we've got the whole UI done.

Um, you know, and I think we're getting past a little bit of shock and awe, and starting to get our hands around actually how do we move forward.

And from a C-suite level, it's about what are we doing to lock down risk, and a lot of the conversations are about let's take, you know, squares off the chessboard.

I'd say like definitely like in my experience in the past when I've spoken to more senior executives at larger organizations, the conversations would be more like, "Well, we just need to get app control running and reinforcement, and then we're good, right?" Um, and now the conversations, and you know, they've achieved those goals, but the conversations now tend to be much more tac-tactics based, where it's gonna be like, "Well, what are we going to do about this class of malware?" It's like, "We've had findings from our regulators or from our pen testers that, uh, click once malware is a problem for us, and we are controlling, we know we, we know we're getting some level of control, but how do we deny this whole class or just roll that out completely?" So I feel like everything, like that's the thing, a lot of the conversations I have are like, or a lot of the time I spend thinking is, okay, yeah, we can stop them executing this code, but how do we stop them even having the attempt to use this method? And there's only a, if you call them TTPs, you know, there's only a limited amount of them.

So control, stopping the TTP from even happening preventively rather than again, just allowing and responding as soon as you can, you know, that's all our focus.

And that's where people sort of get excited because you just go, you know, we're worried about this, we're worried about click fix, we're worried about XYZ.

And if you just go cross them off the list [chuckles] then, you know, they know they're making progress.

Um, so when you can see that association, it just makes it so much clearer.

What's been really interesting when I've talked to customers about it is that they've been shocked to see their internal apps recognized as apps.

That's sort of, I think, something interesting, because we didn't, like, when we first discussed this, I went, I was the guy going, "Oh, well, we probably need an app, app catalog of the top 50, 100, 200 apps, and let's start there making these definitions." And then David's like, "Oh, but then we have to maintain it [laughs] and, you know, it's never gonna be good enough and see everything that's there." And then, you know, through some very clever design, um, LLM enhanced, I think, but not, not using it, um, the, we've ended up in the situation now where I'm like, "Oh, wow," like, you know.

So for us, in order to get that setup phase going really, really quickly by providing that sort of prioritized recommendation work list is where that power is um you know and i think to be honest the majority of customers are going to end up using that system for recommendations at the very least if not auto trust in the early stages and then you know the critical thing for us is also providing visibility into what decisions are being made and why so there is a little bit of natural language going on about why the system has chosen to make that recommendation, but not using natural language or LLMs to make that decision in the first place, if that makes sense.

Yeah, I'd say based on what we're building at the moment, if you looked at, you'd think it was LLM driven based on the content that's coming, the plain language that's coming back to you.

But it's really a lot of decision trees and a lot of intelligence from what we've learned internally ourselves, what mistakes people make, Building allow lists like making sure that you take into account low bins or hey, you don't want to trust PowerShell as a trusted process pretty good idea Because it can do bad things and it's just layering all the stuff out of our own heads what we know and You know all of our customers now what they're seeing and sort of rolling that up into sort of recommendation rules It's all contextual, you know, and I think the big flip here as well is that you know We built this framework product where you can see hey here's all the executions you've seen your environment now make some decisions on it sort of that's great if you've got a pretty good context about yeah i trust these publishers and these files um it makes sense to sort of do this reconciliation but flipping this this flips a little bit on its head um either an automatic or a recommendation mode where it says based on what we've seen your environment these are the suggestions of what you should be adding so it sort of guides users and i think it lowers the bar a little bit for operators as well

Daniel, did you preempt the attacker behavior by build it? Like what prompted you to do the work, the engineering work on that feature in the first place?

Yeah, I think what we really...

At that time, I guess, you know, at the end of the day, what we're trying to do is stop code execution.

So if there's a way that attackers can execute code that is sort of out of scope for us, it really becomes a giant hole in the solution.

So, you know, at that time, I guess when your PowerShell reflection was sort of a new technique or was sort of in the news and, you know, customers were asking about it and ourselves internally were... you know, trying and we're like, oh, we got a bit of a gap here.

Basically.

Yeah, well, it sort of started in this weird thing where we were saying, well, why do you want to block application files? They're not actually executable code.

So it becomes this conversation like, don't you want these trusted sign files? And they're like, well, there's some malicious components.

And a couple of our customers were like, I'll send you some artifacts.

And then we looked at it and went, oh, wait.

this is much worse than anyone that you know that the customer didn't understand it properly and it's the first time we've seen it and that just turned into a big sort of research piece as well or being like well what's actually going on here um and then you know because it's really a combination you've got the click one stuff that's been around forever like in visual studio you can just go compile this to a published website to deploy this app it's just a deployment method And the .NET assembly reflection config file stuff has been known for like five years and sort of dropped off a bit.

But what they've really done here is they've combined both of them by making the .config file also a dependency.

How is EDR dealing with this, or why is EDR not dealing with this well, which seems to be what you were implying earlier?