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.
Malcolm Stagg, an Independent Researcher at Sodium-24, LLC and a member of the Synack Red Team, found his biggest research project by accident, while investigating a customer’s virtual machine on a live Synack target.
In this episode of WE’RE IN!, Malcolm walks through NatJack, a set of NAT table manipulation attacks he’s spent 3–4 years developing, and how a joke RFC document from a teammate turned a slow proof-of-concept into an attack fast enough to hijack live HTTP connections.
How does manipulating a router’s NAT table let an attacker hijack a DNS response, or take over someone else’s TCP connection? Why does this affect Linux, Windows, and Mac alike, not just one implementation? And what should security teams actually do about it, starting today?
Don’t miss Malcolm’s rundown of the mitigations that matter most and follow his research at natjack.io.
Encryption is the strongest mitigation Because many NAT systems were still vulnerable at the time of recording, Malcolm's top recommendation is strong encryption such as TLS and HTTPS, so hijacked traffic is unreadable.
Shared NAT layers break isolation Containers and virtual machines that share a host's NAT layer can be attacked through it, undermining isolation between VMs and between a VM and its host.
Harden routers against NAT abuse Enable protection against client IP spoofing, sometimes called IP source guard, and limit how many NAT table entries each client can create.
Lock down container privileges Avoid running containers as root and turn off the default capability that allows raw sockets where possible.
Not just a Linux problem The research started with Linux Netfilter, but Malcolm found nearly all the NAT implementations he examined, including Windows, Mac, and cloud systems, had the same flaw.
Notable quotes
The approach I really like to take a lot in cybersecurity is I really like to understand the system really well.
But because they're all going through that same NAT layer, it becomes possible through the NAT manipulation techniques to attack that NAT layer.
So it affects Windows. It affects Mac. It affects a whole lot of cloud stuff as well that's not based on those same libraries.
So even if an attacker manages to hijack that traffic, they can't access anything, pretty much.
Questions this episode answers
What is the NATJack attack?
NATJack is a set of NAT table manipulation attacks. An attacker behind the same router can trick it into sending them traffic meant for another user, letting them take over the victim's connection and impersonate the victim to the server. Read this section
How was NATJack discovered?
Malcolm found it by accident about three or four years before the recording while testing a customer virtual machine as a Synack target. An idea about hijacking a DNS response led him to experiment with flooding a router's NAT mappings. Read this section
Does NATJack only affect Linux?
No. Although his initial research focused on Linux, Malcolm found that almost all the NAT implementations he looked at shared the same flaws, including Windows, Mac, and many cloud systems. Read this section
Does IPv6 prevent NAT manipulation attacks?
Wider IPv6 use would help, but Malcolm noted IPv6 is often still deployed with NAT, and NAT and IPv4 infrastructure will remain until IPv6 is closer to universal. Read this section
How can you mitigate NATJack?
Use strong encryption such as TLS and HTTPS, prevent client IP spoofing, limit NAT entries per client, and run containers without root and without raw socket capability. Malcolm planned a website at natjack.io with more mitigations. Read this section
About the guest
Malcolm Stagg is an independent security researcher who, at the time of recording, had been a member of the Synack Red Team for about six years. He previously worked for about four years as a software engineer at Microsoft and then took part in DARPA challenges, including a secure hardware challenge that led him to Synack. His NATJack research describes a new class of NAT manipulation attacks.
Alright. Well, hello, everyone, and welcome back to another edition of WE'RE IN podcast. My name is Ryan Rutan, and I am the director of Synack Red Team. So I get the privilege and the honor of working with some of the greatest hacking minds on the planet. And today, I'm here to talk with one of those minds, Malcolm Stagg. So, Malcolm, wanted to, get a chance to kinda give us a quick introduction of yourself.
Sure. Thanks, Ryan. So I'm Malcolm Stagg. I've been on the Synack Red Team for probably about six years now, I think. My background is sort of mostly in both electrical and engineering, as well as I worked for about four years at Microsoft as a software engineer. And I left there to work for a few years on some challenges that the Department of Defense was putting on at the time. And kind of just decided to start my own thing, pretty much with my own research and stuff. And one of the challenges that I was working on got me involved with cybersecurity.
Nice. And I do remember when you joined. I remember it was a very fun time, and we'll get into that in just a second. That being said, we're all about backgrounds here, so I do wanna look at yours. You have a lot of cool toys in the back, and I'm just curious, like, if that is one of your hobbies, if that is your hobby, or is that your is that your passion? Or, you know, can you talk a little bit about what is it that you like doing on that table behind you? Because it looks very interesting.
Yeah. That's one of the things that I really love is just... Was working on on electronics projects. Just designing circuits and building things with robotics and all sorts of stuff and stuff like that. I've got a lot of the equipment behind me. I've got some oscilloscopes and power supplies and function generators and some stuff back for, like, soldering and... Yeah. I've I've I've... I mean, it's just a stuff something I I I I, like, a lot.
So, yeah, I guess we talked a little bit, you know, about kind of like, you know, how you got to Synack, and that's great. And you mentioned the Department of Defense challenges. And so I was wondering if you could go into a little bit on the DARPA SSITH. I know that that was one where I feel like that's where we first met and overall kinda how you... We first got involved. So could you talk a little bit about that challenge and maybe, you know, any other challenges like that that you were particularly proud of or thought you had an interesting moment in? Sure.
Thank you. Yeah. So at the time, I'd just finished working on the DARPA Spectrum Collaboration Challenge, which was kind of bringing AI to the radio spectrum. And I was still working at the time the Subterranean Challenge, which was designing robots to explore underground tunnels and caves and stuff like that. And while I was working on that, they announced this new challenge, which was called SSITH. And so basically, they designed this new hardware that was supposed to be super secure. And they wanted to test the security of that hardware. So I was just thinking that sounds like something that would be a lot of fun.
So I found out how to get involved in that. It turned out there is a capture the flag thing. So I did that. And I did well enough in the capture the flag to join Synack and work on the challenge. And so it was a lot of fun. The approach I really like to take a lot in cybersecurity is I really like to understand the system really well. So if there's source code, I'll want to study that. If there's binaries, I'll want to reverse and engineer those. And so, SSITH, that was something I really enjoyed, because I could spend a whole lot of time just digging into to the source code and just kind of trying to figure out how how the system was meant to work.
And then I kind of find that when I really have that understanding of of how it's supposed to work, that's when I can kind of start to find things like, this cohere does something that maybe they weren't intending that it would be able to do. So that was kind of my experience with the SSITH challenge, was I just, after getting to know the systems really well, there were a few things that just kind of popped out to me, and it turned out that that those were things that I I I could ex ex ex ex exploit.
You see me smiling and grinning over here because I remember that project very vividly. And so when I look at, like, if I remember back what the process and how you were going through it and the stories and everything like that, it's like things just go right when Malcolm gets curious and things pop for him. So I think it's a really interesting thing. And so, again, I definitely respect the level, the detail, the craft that you go through to understand it. The creativity I see in your bones and that submit the platform, just the way in which you think, definitely, like I said, love hearing about it. I'll always smile when I hear about it.
You mentioned an interesting part in there around AI, about how you originally got started with, like, the frontier elements of AI, and this was, like, like, five, six years ago at this point. And I'm just curious, like, what is your state of of, I guess, interest in AI right now? Like, where do you see AI impacting cybersecurity right now? And then more importantly, where do you see the opportunity that it has, you know, to make a difference even more so in the future? Ed, wonder if you had some thoughts on that.
Sure. Yeah. So I I I... I've kind of been been in in... Interested in in AI for a long time now, kind of before the big, like, surge with large language models and and all that stuff. Yes. So a lot of it kind of has come as a little bit of a surprise to me. I was at first a little bit skeptical about what the capabilities would be of the large language models. But I'm happy and surprised to see that they can actually solve some real problems and stuff. So in terms of cybersecurity, I kind of still have some mixed feelings at at this point. Because I've kind of seen firsthand that as the AI models have become more capable, then people are kind of moving entirely to finding vulnerabilities with the AI models.
And there are some that the AI models are great at life finding. Whereas there's also some more larger, more well, larger issues are maybe less obvious. And I think some of those issues, the models would still have trouble trying to find. And because they have been taking over, they've been completely overwhelming. Companies like triage teams and all that. So it's been good in some ways that they have been identifying a lot of new issues. But also at the same time, I think that can sometimes make it harder for other issues to be found that they don't, at least not right now, have the ability to find.
I agree. And again, think at the end of the day, you know, creativity, the human component really can't be undersold. So AI is really great at replicating and recreating anything that's been taught for the most part. But, overall, when it comes to the human component, I agree there's there's definitely a blend there around AI and then the human element to to kind of accent and work it together. So so thanks for that. So, again, we could talk about AI for a little bit more, but to be honest, I know that you're working on some really cool research right now. And overall, I was really wanting to get to talk to that. So if you want, if you would just share a little bit about the research that you've been doing for a while, share a little bit about how long you've been working on it, you know, your process, your methods, and then overall, just anything you wanna tell tell and share it about us, that would be great.
Sure. Sounds good. So I've been working on a project. I'm calling it NATJack. And it's basically a set of NAT table manipulation attacks. So kind of just to give a little brief background. When you've got a router, you've got a bunch of computers kind of behind that router. And they all share the IP of the router, pretty much. So the router can test it to up to... The router basically needs to have the ability to map between an internal machine behind the router and an external machine that someone's trying to communicate with, to send data back and forth over the network.
And just kind of as a really brief overview of these attacks, I found that it's often possible to manipulate the router so that instead of sending traffic back to the intended user, if there's an attacker somewhere behind the router, they can trick the router into sending them the traffic I meant, for that user. And this basically allows the user... Or it allows the attacker to take over a connection from a victim, and also pretend to be that victim as it continues to communicate with a like server, pretty much.
And, yeah. So I've been working on this research for probably about three or four years. Now, kind of on and off, haven't been working on it full time. But it has taken a large chunk of my time, though. And it was really something I just determined, or I just found by accident, pretty much. I was actually working on a Synack target at the time. And it was to investigate a customer's virtual machine. And I kind of had this random idea that it would be cool if I could take over a DNS response and kind of replace that with my own response, pretty much. And I was kind of just thinking, well, don't know exactly how I would do that.
But if I did, I'd probably have to somehow stop the first DNS request from getting to the the, like, server, pretty much. So I first had this random idea that maybe I I could just try to use up all the ports on on that computer and see if that would block it. And so I kind of went offline and was experimenting a little bit about what might be possible. And I found that at least in the experiments I was doing, it didn't really work or help to take up all of those ports. But I had this idea that what if I made the router a part of the attack? Because the traffic's somehow going from the VM through some sort of a router before it gets the Internet.
And I didn't know too much at the time about how routers work, but I knew enough that I knew they had to map between an So the first thing I wanted to try was, what would happen if I send so many packets through the router that it would use up all of those mappings? And it would be like... I'd I'd I'd I'd have one in... Internal port connected to one external port, another internal port connected to another external port, and so on. And and I tried to make it so the router would have to keep track of of of of all those mappings.
And so, I got some code set up, and I was just sending packets through the router. And the first thing I noticed, which was kind of surprising to me, was that the packets didn't stop going through the router. So I was thinking, how is it keeping track of all these entries, basically? So I extended my test code a little bit more, and I got it. So I would send a packet containing a white number, send that through the register. And the other end, when it would receive that packet, it would just reply with a packet containing that that same number, basically. So then I could get a better idea of how the data is flowing through the router as it goes back and forth.
So I did that, and the packets were still flowing back and forth. But what I saw, which was a huge surprise to me, was when I sent a packet containing one number, I would sometimes get a packet back containing another number. So that showed me that something was getting messed up in the mappings in the router between the internal IPs and the external IPs, which is called NAT table. So I kept on experimenting with this, and I dug in some more. It was a router running DD-WRT. So I took a look at the source code for that, and I eventually found that the network address translation was handled by a library called Netfilter, which is basically a part of the Linux kernel.
So I started to look more into the source code for that. And eventually, what I took down first about how the replies I was getting back weren't matching the requests I was sending out, I figured out how to turn this into So I figured out how to turn this into an attack, where a victim is basically trying to make DNS requests, and an attacker is also somewhere behind the same router. And what the attacker is doing is the attacker just keeps on sending a whole lot of packets through the router, which removes the victim's original entry there.
And then the attacker can send some packets corresponding to new entries. So basically, the effect of this is the victim's original entry gets flushed out of the NAT table, and it gets replaced with a new entry that goes back to the attacker. So then the victim can make a DNS request. The server responds. But then when the server responds, that actually goes back to the attacker instead of the the victim. And then sometimes the the attacker might be able to craft their own DNS response based on on that response and just, like, send that back to the victim. So, that was kind of the first attack I I got got to to to work.
So I'm gonna stop you right there because the onion that you just put together that I'm peeling back right now is so many layers, and it's so awesome. So I wanna kinda dig in. I just wanna make sure we kinda drill into it because it's the part that makes me very interested with this research that that you're talking about. One is I love the story the way you talked about it, right, about how you started off with just as a target. We're just trying to flood this thing and see how it breaks, find this breaking point. I I think you start seeing this kind of weird behavior that you couldn't explain. But the piece that I I love is that, you know, you started at target asset level, then you broke it down to, okay. We're gonna work and focus on the router, make it a part of the attack, and then breaking it down further. Okay. Now this is not just the router. It's NAT, and then NAT is now a library that is shared in the Linux kernel. And so this is one of those really interesting things that I love about the way in which you approach. Like, I mean, a lot of people will read source code and be like, oh, that's great. This is like multiple layers of source code and services and capabilities. And like I said, the the wherewithal to kinda dig through all that is is I can't say enough.
But long story short, I just... From an... From a NAT perspective, can you help paint a picture? I mean, how pervasive is NAT? Like, I I have my response, but how would you say, like, in terms of, like, it's it's it's importance to the Internet, importance to everything? Like, I wanna get your perspective and thought on that real quick before we go into your other attack types.
Sure. Thanks, Ryan. Yeah. So NAT's been around for, really, for about twenty to twenty five years. For the the most part... So when the Internet was originally designed, they they assumed that there would never be more than like 4,000,000,000 computers using the internet at the same time. So kind of as one of the limitations of the TCP protocol, the IP address of each computer is only limited to four bytes, which means there can only four be billion IPs. And today, that's a problem because if if you look at at all all the computers and, like, cell phones and all that stuff, there's way more than than for a a a billion.
So the way this was, solved, this was back, I think, somewhere around 1999 or 2000 or somewhere around there, was they started to realize that there could be the internal IPs which don't connect directly to the internet. And then those internal IPs could all share the same external IP. And that helped to solve the the problem that just there aren't enough IP addresses for all the computers to access the Internet at the same time. So routers are are kind of one of the the the main places that NAT is used today.
But it's not really limited to just routers. And there's a lot of other cases as well. And some that I was specifically looking at for the NATJack attack were hypervisors, and virtualization, and containers as well. So when you're running multiple virtual machines or containers on your system, often it's set up by default so that each virtual machine or container will have its own internal IP that belongs to that VM or container. But then, when it's accessing something over the network, it will actually go through NAT and use the IP of the host machine where that VM or container is being run.
So that was something I wasn't really thinking about at first when I first discovered the attack. But then, when I started to look at all the possible places where NAT could be used, that was a place where I saw that, oh, yeah, this could be a place where NAT could be attacked. And then you've got some cases there where you've got intended network isolation between those containers and virtual machines. Typically, you'd want the virtual machines to be isolated both from each other and from the host machine where they're running. But because they're all going through that same NAT layer, it becomes possible through the NAT manipulation techniques to attack that NAT layer.
And then you're basically breaking the intended, network isolation between those those those virtual machines, or in some cases, between the virtual machine and the like host where it's it's being run.
I see what you did there. It's my mighty crafty. Like, I ask you a question to talk about NAT, its prevalence, whatnot, and then you pivot it to the other attack types that you were working on. So I think that's great. So I would say, yeah. I mean, long story short, I guess the long... I think you hit it on the head. NAT is everywhere. The chances are if you're just an individual person alone, you probably have at least eight or nine NAT devices in and around your home. But more importantly, as an enterprise, as we look at virtualization, cloud, containers, at an exponential scale, it's everywhere. And so the fact that this is in a fundamental flaw and bug in that low level library that you've talked about, you know, it just means that it's relevant. It means that it's something that needs to be looked at. And so I think you've done a great job explaining it. And I would love for you to like, you know... I love hearing about all your fun stuff. So, like, I'd say, like, you've talked a little bit about, you know, session hijacking, if you will, DNS hijacking, you know, container escapes, things like that.
Yeah. So the the main attacks I was initially looking at was was first the DNS hijacking it, as a attack that I explained a little bit about before. Then kind of my next thought was, okay, this can be used with UDP packets and with DNS. Can I extend it further so it will also work with TCP? And I found that it was possible to do that through the same filter library. So it became possible with the next attacks I developed to hijack a I basically could hijack a TCP connection. But I didn't want to stop at just TCP connection hijacking either, because I wanted to kind of extend that to a real world use case where I could actually show that there is real security impact there.
And so, one of the TCP attacks, it was kind of interesting. It started out that attack was quite slow. But sometimes, it seemed to work a whole lot faster. And at first, I couldn't figure out why that was. And then one day, just as a joke, one of the people I work with on the Synack Red Team, His name's Neil. He sent me this document. It was RFC 1337. You know, like thirteen thirty seven, the weight in dehacking of community.
And so, this document, RFC thirteen thirty seven, it was called, I think it was called TIME-WAIT Assassination Hazards in the TCP protocol. And when I saw that, I started thinking, I think I could actually use what's described in this random joke document, RFC thirteen thirty seven, to extend these attacks. So that instead of taking seconds to execute, they could sometimes just take place immediately. So I took another look at the source code from the perspective of RFC thirteen thirty seven. And I found something I could use to make that happen. And one of the effects of that was, of course, I could make the attacks a whole lot faster.
But another effect was that I could really easily target HTTP connections as well. Because usually, there's not a whole lot of time between, like, you send an HTTP response to a server, and then the server responds back with the HTTP response. But I I found the attack became fast enough that I could actually attack the NAT table in that short period of time between the HTTP request and the HTTP response. And that allowed real world HTTP connection hijacking. And I I I I I could even demonstrate that against real HTTP servers. I'm like a Google search or like something like that.
I I think it's awesome when it comes to, you know, one, collaboration in the researcher community is something I love. Definitely something I love in the SRT. So when I see great people come together and share ideas like that, I think it's funny. I didn't realize the RFC for that assassination was 1337, so that's really hilarious that it happened to be that that... They have that prophetic number, if you will, and lead to such a thing. So... No. But that's awesome. Again, like, you know, I think what's really important about this research, think is important, is that, you know, the internet is built on assumptions, it's built on trust, it's built on things, you know, forefathers and forepeople who have created a lot of technology over the years. And a lot of times we don't look back far enough to understand, like, what are some of the assumptions that we have here? And I think that that's one of the things I find most fascinating about this is that this is like, it's kind of like, you know, going back and finding out that, like, you know, Isaac Newton got gravity wrong or something like, you know, just like, it's, it's weird.
So I think it's pretty compelling. And again, I'm excited to to learn more about it and and follow along on the the NATJack journey, if you will. Do you have any of others you wanna talk about without... Regarding NATJack? Otherwise, I have a couple of questions I wanna ask you to kinda wrap this up. One of them might just kinda be a little bit a hot seat thing, but other than that, you know, wanna give you a chance to talk about anything that you might have left unsaid about your research.
Sure. Yeah. So I talked kind of about two main attacks, the UDP DNS hijacking and the TCP hijacking. I also, I developed two other attacks as well. I I did finally get the thing I was trying to work on initially to work where I could send enough packets to fill up the NAT table in the router, so that no other data could be sent or received. So that was kind of one of the more straightforward attacks, pretty much. But the effect of that is just a denial of service, basically, to anyone that's behind that same router.
And there was also one more attack I developed as well, an information disclosure attack. Because I found, in one of the cases for the TCP hijacking, I would need to identify which port was used for the connection between the client and the server. I didn't need to know that for one of the attacks because it just ran fast enough that I could cycle through all those ports. But other attack did take a little bit longer. So I had to first identify what that port was. So I've also got a method for doing that. It's based on two behaviors that are a lot of not some use, which are called preservation and endpoint independent mapping.
And so basically, those are just the port assignment behaviors of the router, pretty much. So I found that I could exploit the way that routers and NAT systems assign ports to basically determine which port is currently being used for a a connection.
Okay. We should all run for the hills at this point. So... Yeah. Alright. Well, hey. Well, I had a couple questions I wanna ask because one, think it's actually kinda funny because, you know, I think, you know, you've been around the block for a while, same same as me. And I know that there was a big moment back in time where we said, you know, I p v six, it's gonna save the world, or are we gonna stick with IPv4 and then that? And I'm just curious, like, where were you in that argument back, you know, maybe fifteen, twenty years ago when when all that was going down? And then secondly, you know, where do you feel like IPv6 is... You know, would help solve this or mitigate this? Or, you know, where does that play in this in this conversation? And, again, the laugh right there just gives me everything I need to know right there. So... But, yeah, I'm curious to know where you land on that.
Yeah. Thanks, Ryan. Yeah. Yeah. You're you're you're absolutely right. Yes. So so IPv6, definitely, that was another method that was intended to replace IPv4, and the limitation that you can only have the 4,000,000,000 IPs at the same time. So definitely, if there were more universal use of IPv6, that would definitely help to mitigate the attacks. But it seems anything with technology involving the Internet, seems to move extremely slowly. Because you always have to manage the backwards compatibility, that there's still things that don't support the new technology.
And I think that's been the main thing preventing more widespread use of IPv6. Now, from what I do understand, a large portion of traffic over the internet now does use IPv6. But until that's closer to 100%, I don't think routers and NATs and all that stuff are going anywhere, though. And I should point out as well, though IPv6 doesn't technically need NAT, it often is still being used with NAT. So just using IPv6 doesn't necessarily solve all the problems unless kind of the older infrastructure that uses NAT and IPv4.
Nice. Yeah, it's like I p v six is great. You know, it's like in this concept, like, I forget the even the number it was like, so big. I was like, I've lost track of over time. It's one of those trivia things that you want for like, you know, pub trivia. But at the end of the day, you're always gonna have the internal and external component and a translating element there that sits between. I think really interesting. Any time an IPv4 problem shows up, the IPv6ers come out and say, you see? So I thought it I thought it would be an interesting conversation.
what what thing up. So so like my initial research into this attack was all based on Linux and the Netfilter library. But as I kept on on going further into it, I found that almost all the flaws I found, they weren't limited to just Linux or just Netfilter. So I was looking at a lot of unique NAT implementations. And almost all of them, they had the same flaw. So it affects Windows. It affects Mac. It affects a whole lot of cloud stuff as well that's not based on those same libraries.
Alright. Well, you can't leave a haymaker like that at the end without at least one more question then. So we've talked a lot about the impacts of this, all the ways in which it can be bad or misused or whatnot. I'm curious, I know that you also have been putting together a list of mitigations, best practices, things like that. I was wondering if you could share maybe the top couple of ideas from that list, and then maybe kinda tell us where we can keep up and follow along to of... What's the best way for people that are interested in this topic to stay educated and stay up to speed on how to assess their exposure and or how to put their best foot forward to try to mitigate any impacts to this?
Sure. So at this point, there have been a few patches released by vendors. But for the most part, for the time being, a lot of NAT systems are still going to be vulnerable to a lot of these attacks. So the mitigations that people can do on their own, they definitely are very important at this point. And probably the best mitigation overall is just the use of strong in encryption, like using a TLS, like HTTPS, just anything where the traffic is encrypted.
So even if an attacker manages to hijack that traffic, they can't access anything, pretty much. So I would say that's probably the number one mitigation, is just the use of strong encryption. Then there are several other mitigations as well. I would recommend, if your router supports it, to prevent clients from spoofing their IEPs. I think the name of that is sometimes called IP source guard. So it just kind of adds an extra layer of protection there. And another one is limiting the number of NAT table entries that each client can make. So those are just a few kind of common sense things that you can do with your router at this point to help.
If you're using containers and virtualization, it's always best if you can avoid it, avoid running the container as root. Just kind of try to lower the permissions there as much as possible. And there's one capability that's enabled by default that allows the use of raw sockets. I would recommend just turning that off if you can. So for containers and virtualization, those are a few things that would possibly help an attack. I'm launching a website that will explain more about the attack, and it will have list of of ways that you can help to to mitigate it.
Alright. And that's natjack.io. Just making sure. Alright. Sweet. Well, Malcolm, this has been a fun time. Like I said, I I could... You know, you know me. I can talk forever. And and more importantly, especially when you're talking with people that have a lot of fun stuff to say. So any closing thoughts or otherwise, we can wrap this thing up. And like I said, we'll... You know, looking forward to hearing you talk about this over the next couple of weeks and seeing where this goes.
Thanks, Ryan. Yeah. I don't think I have too much else to say. But, yeah, I've just really appreciated all my time. I'm getting to learn more about cybersecurity on the SRT and just exploring all fund targets. Yeah, it's it's it's it's been a a, like, blast.
Sweet. Alright. Well, we're going ahead and wrap up... Wrap this up. But I do wanna say thank you, Malcolm, again for spending the time with us today to talk about NATJack, talk about your origin story, talk a little bit about the SRT, and a little bit about DARPA. So, with that, we're gonna wrap this thing up. For anyone who wants to keep and check out more stuff about the SRT, check out synack.com/redteam. And, this is WE'RE IN podcast brought to you by Synack.
