Name: Think Like a Hacker: Understanding and Reducing Your Modern Attack Surface
Uploaded: 2026-01-21T17:15:41.336Z
Duration: 35 min 4 s
Description: Think Like a Hacker: Understanding and Reducing Your Modern Attack Surface

Transcript for "Think Like a Hacker: Understanding and Reducing Your Modern Attack Surface": Hey, everyone. Great to see you all, and welcome to today's webinar. Let me share my slides real quick. Okay. So today, I wanted to speak with you all about a session called think like a hacker where I will show practical session on detecting and responding to attack surface risks in the eyes of an attacker and based on real world attacks. So first of all, who am I in a Wiz fashion? We like to use the graph for everything. So my name is Gal Nagli. My hacker name is usually Nagli, and I'm a hacker. I have a background on HackerOne, top five there in bug bounty, and I'm finding a lot of bugs anywhere. And, also, in Wiz, I'm like a hacker in residence where I'm making sure our attack surface management product and other solutions really aim to find the bugs that hackers want to exploit in your environment. One of my favorite cities is in London, and I'm an Arsenal fan just to break the ice. And when I'm not working, I'm hanging out with my dog Chip. So I want to start with the problem. The attack surface is growing and faster than ever before. All organizations are moving to the cloud, and AI is also accelerating development. Anyone is now a developer. More AI applications, more services that are using AI, and a lot more people are now developing using AI that never touched code before. Not only AI checkbooks and applications, but actually AI writing the code. So attacker opportunities have never been bigger than today. So if we're seeking on your attack surface, it's way more than web applications, SaaS applications, or network appliances. What about your cloud VMs, your buckets, your API gateway, your source code, your AI infrastructure? A lot of the times, it doesn't have the company name inside it. So how do you know if it's yours? How do you know to map everything altogether to your company? Some misconfigurations. I mean, it's not only theoretical. It's actually happening. We know Volkswagen were hit with a massive data leak which failed to secure one of the web servers, which leaked some of their AWS keys. Also, Tata Motors had a breach with a lot of sensitive data that were exposed, and it was originated from a JavaScript secret inside the file. Attackers use that file to extract data to those systems. And also more another example that is more relatable to us, it's a vulnerability we found last year on DeepSeek. So DeepSeek, it was a major AI company. They had a lot of buzz last year, and they exposed a public facing click of database to the Internet. So once we see as an hacker I'm putting my hacker hat on now. When there is a new technology or something new that we want to scan, the process is very simple when we want to hack any company around the world, not only DeepSig, but just this is what attackers would would like to do if they would want to hack your company, for example. One second. So the process is pretty simple. When I want to have DeepSeek, I need domain domain first. So I'm taking deepseek.com in this example. It could be any other company. Then we go to do subdomain enumeration. Want to find all the publicly accessible assets that the company have over the Internet. Then I found a domain which was looking pretty weird, and then I want to check what is actually alive and not only internally facing. So I want to see what is actually open to the public Internet. That's where I did port scanning and HTTP resolving, and we found a service which was on port 9,000, which was publicly facing. And we saw the technology was clickhouse. So then when we see technology from the outside and the public service, we want to actually hunt for risks. So I'm running a lot of templates, and this is what attacker is doing, running a lot of rules that try to check for common misconfigurations, like unnotetected access to database, like expose secrets and data. And finally, I get an auto automation notification to my own Slack. So this is a real example. Like, I just was in lunch, and I tried to hey. DeepSeek is a new technology. Let's try to hack it. And then I got this notification to my Slack in about fifteen minutes. So this whole process of, like, taking a company, checking what is publicly accessible, trying to hack it, is sometimes it's just a click on a button on your computer. So I will show you very soon how it actually looked like, but just after I got this alert, of course, you want to investigate if it's a real bug. So I opened this on my own web server, on my own browser, and I saw that there were actually tables exposed, a lot of sensitive data, API keys leaked, services, log stream, and actually actual plain text chat messages also publicly facing to the Internet. So this whole process is literally me clicking enter on my virtual machine. So I made a bash alias, which is called hack now, and I just put the domain inside. Here I put a domain which we put a CTF similar to the deep sink. So I just said, like, you can put any company around it. If I want to check-in if a company is vulnerable to any misconfiguration, it's the same process. I'm writing the company main root domain. I'm finding all the company subdomains with many public open source tools, certificate transparency, and so on. Then I'm running a tool called Pure DNS, which is checking what services are actually have records behind them, they are alive, and we can access them. After that, I'm using a tool called HTTPX, which checks for public exposure of the services. It gives you the status code, the title, the IP, and then you can you have an actual representation of all the publicly facing assets of your target and of your company. And then the next step is simply to run some vulnerability scanners like Nuclei, which is a signature based scanner which tells you, hey. If you see a Clickhouse database, run this Clickhouse Authenticator API check. If you can actually get the result that you expect, if it was misconfigured, give me an alert to Slack. So this is just a summary of, like, a whole process of hacking any company around the world and even you. What the point I'm trying to make is that it's super simple and easy, and there's a lot more applications to have today. I want to see all your public assets. I want to check what is actually publicly facing and fingerprint it, and then I'm just running some set of rules and misconfigurations that could be happening on your assets. So this what happened with DeepSeek, and it could be any other company. Anyone could host a click of database and just expose it to the public Internet. So this is exactly why we try and develop and now launching with ASM as of last month. So, basically, we are releasing the, I could say, the world's first context driven ASM. We are using external attack center scanning like I showed you now, but it's enriched with context on the security graph. It means we are visible with a lot more information that is not available to the public attackers, to the public Internet, like your buckets, your API gateway, a lot of resources. And it's also not enriched with the context that we can tell you, like, what is the underlying resource? Who's responsible to fixing this issue? Do we have any similar issues in our environment? So this is what powers us in our LSM approach is to really find the critical risk that matter most. And let's just do a very quick look to how a real life cloud exposure looks like. It could be the same with DeepSeek. So we started with exposure discovery. This is this EC two instance that we have in our environment. And now we check if it's really publicly facing. This is the exposure validation pay phase. I want to check if it actually has an IP that is open to the Internet. And in this case, we saw, and we got a screenshot of it, and so on. The next step is to do application fingerprinting. We want to know what services are publicly facing on this app so we know what misconfigurations to scan for. In this case, we found the Jenkins instance and Jenkins technology. Then we are trying to check for exploitability. Is there any active expert that could work on this asset? And in this case, the Jenkins was misconfigured with default credentials. So this is one of the rules that we would check or attackers would check for any Jenkins instance they would find publicly facing, and then we can give you an alert. Okay. This Jenkins instance is actually with different credentials. It's very critical. Anyone can run code on your systems, but this is usually where all other tools or where me as an attacker stop because I can't know more in an automated fashion now. So what I would do if I were an attacker, I would check if there is AWS keys that I could access now. I would try to obtain the AWS keys, check the permissions, and so on. But this is what's nice when we give you more context inside Wiz is that we know the key, what role it actually permits to, what's if it's sensitive, what access can it get, who's the actual owner who deployed the server that needs to fix it. So we have a lot more information that you could know just by being an attacker from the outside because it's already represented in the graph, and we already have this context inside with. So the best part is to know, like, how what's the blast radius? Because a lot of the times, this environment are just development environments or staging environment, and the product team or the recent or the developer, they say just a staging instance. It's all good. But then when you look at the actual AWS keys, you see that you can get go way further than they ever imagined. This is where the graph and the context comes all together in a very nice way. And now I want to show you actual product demo for five to ten minutes. So let me go to the product page. Okay. So this is the WISP portal. And in WISP, when I want to show attack surface management, we have the lens concept, which is basically it's like a lot of different products in one page, but then we can give you the view you care about the most. So we could tell our attack surface story in five different stages that it's similar to what I showed you earlier. We always start with discovery. We see all your cloud instances, all your API gateways, buckets, and so on. So we have a lot of information from the inside for public assets of yours. We also allow you to import your own on prem assets. You can just upload them into Wiz. And then you can see here that, for example, I uploaded some assets that are not in a cloud that is connected to Wiz of my bug bounty master class CTF. And then you could also see here in the scan log what we're actually scanning for in your environment all the time every day, seeing what is publicly publicly exposed and publicly facing. So in the discovery, not only that, we also allow you to import assets from different tools that you scan for. We also use our on prem sensor to see the traffic that you interact with your applications and can create more API endpoints from it. We can also find from the code and, in general, just giving you a holistic view of all the publicly facing assets that could be from your environment. So the first step is just discovery, knowing what the candidates are, what the names. And in the second step, we really try to see what is really publicly facing with no restrictions, no firewall. Anyone in the world can access it. And here we get to the actual inventory page that we have inside Wizz. So just having this sort of inventory is great for attackers because you can just look for a lot of misconfigurations and secrets and internal services that are publicly facing without even needing any scanner to tell you there is a risk here. For example, you can look for technologies, and it's a very nice view to know, okay, those are all technologies that we have publicly facing on the Internet. Another cool filter that I like to do is to filter for status code 200, for example, and then you can see all your applications is 200 status code. But now let's see also the resource type because, okay, what are all of my buckets that have 200 status code? Maybe they expose internal information. Now these buckets are publicly facing on the Internet. Anyone can find it. But the biggest gap here is the attribution. Because if an attacker would find this bucket and he could find it, he would just grab the entire Internet, he couldn't know that this bucket belongs to Wizz. So if someone can export your company, he didn't target you specifically, but in a campaign where they scan the entire Internet, they would find this resource which actually belongs to you. So when we know already the the context from the inside, we can find a lot more interesting stuff right away, not waiting for someone to find it inadvertently. Because you can't really do software enumeration in to Wizz. Or something to find these buckets. Those assets are not connected to your main DNS names. So this is where it's a little it's getting tricky to find all your exposures and where we really shine because we have internal visibility to your IP addresses, ELB, ALB instances, and so on. This is why the cloud is really crucial now in the age of AI and rapid development to know all the IPs that some developers just spin up to do some testing, for example. After we have the interface facing validation, we are doing application fingerprinting as I showed you. We see all technologies that are publicly facing. And then we are really getting into the interesting part of scanning for risks. What risk could actually exist? What risk could actually exploit you now external attackers, for example? The main category for risk that we have in WIS is attack surface rules. Those are a list of over 700 deterministic rules that try to check if a certain misconfiguration actually exists. For example, Grafana. If we detect the Grafana instance in your environment, we will try the default credentials. And if we really manage to succeed to log in with default credentials, let's say admin admin or admin prompt operator, we will give you an alert. Those alerts are very high fidelity. It means there is an actual risk. This Grafana is really publicly facing, and anyone can really authenticate to it and and run SSRF or other escalations. So we are really focused on the critical risks that matter most, the high end criticals. We want to give you all the attack vectors that, you know, all the script keydies or anyone who just scans the entire Internet would stumble upon himself if they try to scan you and actually hunt for risks. You can also see here, for example, that we have high profile threat category where we added the latest high profile threats like Next. Js. We have to share vulnerability that happened a months ago. MongoDB, MongoDB, those are checks that are not theoretical. Like, okay. I have a CV on my machine. Someone might exploit it, but it's in the internal network. Here, we give you an actual proof. We really scan you from the open Internet, and we know that it's exploitable for someone from the outside world. We give you all the proof, and all you need to do is open it to a new tab and actually validate it. So those are the first set of rules that we check for risk. It's attack surface rule. We also have secret findings. We scan every asset that is publicly facing, and all of its underlying JavaScript file that is loaded in the page for secret findings. Here, for example, we found AWS key in the main page of this domain, but we also scan all the JavaScript. Not only that, we also scan for data findings, every API gateway that you have, every pass. We try to see if there's any sensitive data out there that we might warrant an immediate fix. So this is the most critical research we do. And now for the best part that we can show you is the toxic combination, how it's all connected together. So this is where the issues come to play to to play. Let me show you here. Let's pick an issue. Okay. So this issue is about externally validated software with default credentials on a VM with sensitive data access. So we have an instance here, Jenkins. It's with default credentials, and we know the actual machine. We know the IAM role, and we know that it can actually access sensitive buckets with sensitive data. Not only that, we also know you where it was deployed, who was in charge of it, what other findings, and who's the owner that needs to fix this issue eventually. This saves you a lot of time knowing what to do, when to do, not just getting a report, but actually knowing how to trace it back to an immediate fix. Because those prep reach alerts, you want to fix them as soon as possible. So this is where we try to help. Also, everything in Wiz is AI powered, so you can see the full explanation in a natural language in a very easy way. But this is how instead of just getting a finding, hey. You have a Jenkins with different credentials. Good luck. Figure out who's the owner, what's the impact, and how to fix it. We give you everything on a plate as a red highlighted issue that you can just pick it up, spin up the remediation right away, sometimes form with like, you don't need even to leave the portal. You can already initiate and trigger the remediation. And those are the issues that matter most. Those critical red related issues are ones that we know are for sure could be exported from the outside world because we validated those. So this is the approach we're taking, really combating the real risks that could harm your company. Now back to the slides. It's quick. So if I would summarize the five stuff, if you have if you have a risk customer or in general, want to see if there's any risk in your attack surface, this is what I do. After you have your inventory and you discovered all your assets, I'm starting with the attack surface rules. Those are the list of the deterministic checks that try to see if you have any misconfigured third party software, Jenkins instance, exposure of a dot n file. This is the first thing I'm trying to do. The second thing is just to scan all of the applications for data and secrets to see if there's anything sensitive also, which is publicly facing. We see a lot of companies expose secrets in their JavaScript files now when they develop new applications or byte called applications mostly. Then I would say just look at all your assets. Look at all your buckets if you have width. Try to see if you have any public buckets with sensitive data because it's very prevalent, very common, especially now with AI when everyone store all their data inside buckets. So they get big. They get a we they are filled with a lot of sensitive data, and they are publicly facing to the world. So this is the most the worst combination that you want to find and fix. And then I just would recommend you to hunt for internal assets in your environment. Just check s 200 status code, take the internal with context, and you will find a lot of misconfigurations or just portals that are explicit for your company, but they should have never been public. We are also developing an AI agent now in this area in the API security assessment phase. It's called the WizzRed agent, and we are already hunting on Akwa one. You could see we are the first connected there. And we are helping our customers also find vulnerabilities that are not deterministic based on the business logic and based on their actual context so we can sense us even more risks going from deterministic to any risk that attacker could find by itself. And finally, just to stay on top of the threat intel center, every month or every three weeks, you see a major threat, Shai Khulud, MongoDB, React to Shell. And those the the first thing that you want to ask is not if if I'm vulnerable from the inside, if I know the CVE, if we have public assets, do we know any actual exploitable assets to the outside world? And this answer, we can we can give you with the with ASM. And if you know if there is a publicly facing asset that could be exploited, the next question would be, do we see any actual exploitation on it? This instance, we can also give you with with defend. So we can really close the loop for, are you actually vulnerable? Can someone exploit you? And did someone actually exploit you already before you fixed it? So those are, like, the five main rules that I'm doing when I'm giving access to a tenant or if I want to do hunt myself. This is what I would look for to see any meaningful risks in the environment. Okay? I'm also really recommend to set an automation. So for every disk of red lighted issues, you can do an automation from Wiz. If you're not using Wiz and you just want to hunt public companies on HackerOne, for example, just do Slack alerts because it's very important that every time you find something which is meaningful, you really want to fix it first or report it first. So automations are very crucial. Like, I use Slack personally, and this is, like, an example from Wiz. If I see a tenant if I see that our tenant has a new Springboot actuator heap dump running on a serverless machine, this is an alert I would want a SOC to see right away, the IR team to see right away because you want to fix it right away. You can't keep it hanging for weeks or months because there might be sensitive data inside it. So for all of these kind of alerts, I I would, personally, I ingest them like an IR or like a SOC alert that is actually validated. We really want to take action right now and fix it before it's too late. Just going back a little bit to the first cases that I showed. So the Volkswagen leak, it was an actual exposed Springwood actuator heap dump. This is a reuse case we actually have in Wiz, like, explicitly. It's just another attack surface rule. So if you're using the Wiz ASM, you're covered by it. It's not that those bugs are really complex. It's more about, do I know all my assets, and do I scan it continuously to know? Because you might be good now. You might be good next week. But one time in the year when a developer on a weekend made a mistake in the WAF rules or the network configuration and expose it to the public Internet, and it's too late. So the the ASM and the attack surface management approach is not a single point of time. The biggest the biggest approach you need to do is continuously to know that if someone makes a mistake, you are okay. You know someone is watching. You know you will be fine. So this is why it's super important to monitor for this stuff continuously. Also, the Tata Motors breach, so it was a job secret in a JavaScript file. And we also would have found that because we are looking at all the files that your browser is loading when we navigate to a website, and then we would have we would have alerted you for the exposure of the secret. And using the secret, you could know which data you could have accessed. So this is also coming out of the box. For every asset that we see that you are probably facing, we already tell you what secrets are in there without any extra action needed. And the final point, as I started to say about the high profile threats, this is an example of the Palo Alto RCE that happened last year. And the the nice thing here to see that you have an EC two instance. And first, you know the CVE because the version is not matching. Because we scan your disk and your machine, we know that it's not the latest version, and there is two CVEs for Palo Alto. But then with the attack surface, we actually know to tell you, hey. This Palo Alto, it's actually exportable. We verify that someone can run code on your system. So we give you, okay. Someone can actually export us. And finally, to close the loop, we can also tell you if someone put a Trojan horse or if someone actually put a malware on your instance because we are visible to your deal system, to your file file deal. So this like, for for example, you could have a Trojan horse with no CVE and no attack surface, it means someone exploited a zero day on your instance when there is no known CVE. If you had the Palo Alto indication of the attack surface that we found, if we see that we found the RCE, but there is no origin host or there is no with defend CDR indication someone exploited you, then it's it's not great because you still need to fix it, but it means no one exploited you yet, so you're still fine. And if you only see the CVEs from the inside but no indication from the outside, it means that either your WAF blocks it, either you're okay, or either the CV is not really exploitable or that widespread, and it's we are not in a major risk right now. We want to fix it, but there is no no immediate threat to our to our environment by exploiting this vulnerability. Yes. I think I I went about it really quick. Some examples from the real world about with ASM. So thank you for listening, and I'm available for questions for any any subject data. Yes. So I see a question from Randy about withDefend, and I saw that that it was answered. But the the cool thing about withDefend and ASM and all the connections is that if you have a publicly facing Grafana instance with different credentials or Jenkins and you know someone can run code, then if you have the WizCell, so you can actually see the code that is running. You can actually see that someone tries to request your IMDS, for example. It's cool for me because I like to hack a lot from the bug bounty perspective. And then sometimes I hack internally. I'm hacking our customers because they want us to do an engagement. And then it's funny when we actually catch myself. Like, I see, okay. Oh, they actually saw me running this command here, which they didn't seem really intrusive. They actually saw my all my actions in the sensor, in the CDR. If I use the AWS credentials to do SDS get caller identity, for example, then you also get indications for that. If someone tries to mass mass download a lot of data from your buckets, they can also get insights from that. So it's very nice to close the loop with more insights that we have either on the machine from the just with cloud or also from with defend when we see actual exploitation going live when we are hacking the when someone tries to intrude or hack your your environment. ServiceNow, I believe we support ticketing with ServiceNow, so it should be and you can also ask Mika AI any like, we have AI assistant on the docs, and it can answer all the questions, but I'm pretty sure we are supporting that. We will we will release any ASM rules provide prompt injection. So this is pretty tough because we can't really know when prompt injection was successful. Like, how do we indicate success? So we are we want to tackle this in different areas. First of all, we want to see from the inside if we know this system is running AI workloads and those AI workloads are connected to sensitive data, then it and you don't have guardrails, for example, bedrock guardrails and so on. This is where we want to alert for you. Also, are developing a red agent, which is AI powered pentester. And this one, I want you to tell me if there is any public facing chatbot instance with no authentication. So we know, okay. There is a chatbot with no authentication. It's not supposed to be public. But jailbreaks and prompt injection, it's a little how to know how to hack it with a deterministic rule and know, okay. We are actually vulnerable or exploitable. So it's a it's a tough question for ASM rule, but we are going to tackle it from a lot of very cool areas from the inside, from the workload, from the disk, from the outside with an automated AI pen tester. So we are going to tackle this, but not out of the blue, just checking within attack surface wall. It's will be from different part of the product. Where are you doing the upload that you showed early on in the demo for the attack surface scans? Wait. Let me check the question. Wiz is just for for customers, so you can also only put your assets that we see from the inside. Or if you have vendors that you want to check their security score, and they allow you to scan them. So we allow you to add them, but you don't you can't add just random websites to Wiz, but you can also just use the techniques I showed to do backbounty, article hacking in general, or not a one background and so on. I will answer the questions for the exposed secrets. Let me see if I can share my screen again for a second. Okay. So let's say we have this website. And when you navigate to this website, when you navigate to the main page, it's loading a lot of JavaScript files to actually power what you see. So I just navigate to this URL, and then you see all the static chunks where a parser that we load to actually render the content of the website. And then in one of them, usually what we see in this example, it's on the main page, but the the biggest point of the ASM here is that a lot of byte coded applications are running these huge JavaScript files with a lot of content. And then inside them, a lot of the times, you see how it coded credentials. So this is what we do. We don't only scan the main page. For every page that is rendered, we simulate the rendering of the page, and then we check all of it for secret, up to five megabytes, which is most likely capturing everything for secrets. So this is how we are going beyond just the main page. We are taking it one step forward. And we are also working in 2026 for the AI powered crawler, which will release more API endpoints from all of these huge JavaScript files we can try to autonomously attack them as well. But for your questions on secrets, this is like when you load this page on your browser, we also load all of these passes that you see in the our scan log page, and we also scan each and one of those for secrets and data findings. Yeah. I hope it answered the question. Matthew, I didn't get your question a 100% on what you're doing the upload that you showed earlier on in for the attack surface scans. Happy to answer it if if you can ask it. If you can point me point me directly to that. I'm happy to take any more questions in general about attack surface landscape with some of the hacks we see outside some some of the core research world, like, in general. So while we have some time, I'm still be happy to take any more questions. Or if I did any slide too fast, I can also repeat. Okay. So, Dilip, this is a great question. So tools like NetSys, they really I would call it a DAST. Don't call it a DAST, but they call it a DAST. It's like, hey. Missing header, informative. Hey. SSL, critical. You don't have codes, critical. You don't have CSP, critical. You don't have same site on cookie, critical. We are not on that page. We are really like, I'm trying to we are bug bounty oriented, not for because we it's bug bounty because we want to push you for real risks. We want you to trust our alerts to give them to your SOC, to give it to your engineering team so they can just fix it up fast. They don't need to triage it because for sure it's vulnerable. They can just open a new page. They see all the proof they need, but we want when we say critical and high, it's really critical issue. And for all the other NSO stuff that they usually do, like missing header, CSP, we plan to add them soon as a best practice rules, as informative, just to give you the peace of mind if you need for compliance reasons and so on. But we are really focused on giving you the real risks. And now we develop actual DAST rules, like SQL injection API endpoints, open redirect, XSS, SSRF. And we are also building an AI agent that does Dust for you. It basically tests you for OS top 10 for everything. We believe this can replace Nessus for you. But, again, we will not give you informatives there. We won't really focus on high end criticals, Not for compliance, just to give you, like you know, we want you to fix the risk that could lead to a breach. So NetSys, now they I would say most other tools not NetSys specifically, in general. A lot of them really overexaggerate critical issues. Like, hey. This version you expose your engine next version. It's not updated. There is 200 CPEs. All of them is public POC. You are screwed. And what we see for us, there is no risk. It's just a login page because we are really focused on validating everything so you won't waste your time, which is the most precious thing that you have, your engineering time. Oh, yes. Sorry, Matthew. Yeah. I can show it in in a second. I get I I got what you said now. I forgot to go to the attack surface settings page. So this here, you can configure all the sources that you want, and we have an option to add a target group. So here, I added my bug. This is, like, hosted online node. It's not even in Waze. We didn't connect to it. But you could just specify the assets you want to scan here, and then you can scan any asset, basically, not only your what we see from your cloud, and you get our top notch risk assessment. So you can upload it for you. I hope this is what you asked. So you can also upload it from our set experience here in Waze. Yes. Happy that helped. I'm not sure if we will get this, like, maybe some some of the slides or this whole session to rewatch, but we'll we will update you later, and I can of course, I'm available on LinkedIn or accounting if you're with customers. Like, you can ask me questions anytime. I'm happy to answer on XO or LinkedIn or or any way you'd like. Yeah. So we have a lot of exciting stuff to do. I'm very, very, like, excited about the AI agent stuff that we are building because it will service more cool risks in your environment. And we also, like we experimented it on Akio one. We found great bugs on some of our design partners already and in companies in general in the world. So a lot of cool stuff coming from the risk side. And as always, we are here to support you in any risk related, attack surface related stuff. We really want to find the most critical risks in your environment before it's too late. And the whole story we are building now, a lot of exciting announcements in RSA, all of those coming together to, like, were I exploited? Could I be exploited? How can I be exploited? How do I immediately do one click? So you won't waste your time chasing noise and and stuff that don't matter. Thank you very much, everyone. They I I can speak to The middle in the haystack, there is small caveat there that maybe the agent won't do because they need to look over GitHub to find something. But the second part, it can solve it. Like, the second part of leader in the AIS that can solve. The first one, not yet. And thank you, everyone. Still available for questions. Like, if you want LinkedIn, x, Wiz afterwards. And thank you. Thank you all.