From Discovery to Defense: SAP & Onapsis Joint Response to Zero-Day CVE-2025-31324

Hi everyone and welcome to today’s webinar from discovery to defense SAP and Anasys joint response to a zero day. My name is Sophia Giloy and I will be managing today’s session. Before we get started, I have some housekeeping notes. First, I want to point out the questions module within the ON24 platform. If you have any questions, please enter them at any point during the presentation. And if time allows, we will answer whatever questions we can at the end of the session. You can always adjust the size of the media player on your end to make it bigger or smaller depending on your preference. And finally, please note that this webinar is being recorded and a link will be sent to you. Now I’m going to pass it over to our presenters. With us today, we have Vik Chang, Global Head of Product Security Response at SAP and JP Paris Echegorian, Chief Technology Officer and Co Founder at Onapsis, who will give us a behind the scenes look at how security research and collaboration accelerate guidance, patching and response to this zero day. And with that, the a lot that is going to be covered today, so I’m handing it over to our presenters to kick us off. Excellent. Thanks a lot, Cecile. Hello, everyone. Thanks for joining us. I’m super excited to be presenting today with BIG. We go a long way. We’ve met for several years, and and this is a testament of the great collaboration and partnership we have with SAP, have had for for several years in regards to vulnerability submission, patches, and and security collaboration, strengthening the the security of of our joint customers and and the overall SAP community. So with that, we have a lot of content for today, but, I’m I’m gonna do my intro, and then I’ll pass it over to to the for him to to intro himself. So as Cecile mentioned, JP, CTO and cofounder of, Onapsis, and I’ve been on the cybersecurity for SAP domain, for probably over twenty years already, and doing a lot with SAP customers from the vulnerability research perspective, securing SAP applications, also assessing SAP environments and as well training and presenting at a a number of different milestones and and events. And I’ve been deeply involved in all the events that follow the release of CV twenty twenty five three one three two four, so I’m really happy to be presenting here with with Vic. Vic? Hi, everyone. It’s Vic over here. I I’m from SAP, and I also lead the product security response functions at SAP. Like JP have mentioned, JP and I have known each other for more than a decade. It also shows how long the relationship between SAP and ONAPs has have been, especially around responsible disclosure and vulnerability submissions and patching. In this particular case, in this webinar, I’m happy to be here to to to walk through what has happened and how has Onapsis has contributed to our internal workings. So look forward to have you in this webinar. Thank you. Thanks a lot, mate. Thank you. Awesome. So let’s, start with the key takeaways. These are some of the highlights of what we’re gonna be presenting today. First and foremost is SAP’s rapid response to these events that follow the CV twenty twenty five three one three two four. Right? So we’re gonna be talking about a sequence of events, different issues, but all highlighting how really good response and good collaboration and and rapid response can help strengthening the security of SAP customers overall. We’ll talk about the collaboration we had. We’ll provide some insights into the timeline and what happened, where which were the most relevant events that follow the the incident that we saw last year? What active expectation revealed about threat actors targeting SAP applications in today’s threat landscape? And we’ll talk about recommended steps SAP customers can take to reduce future risk, and we’ll talk about how important is patching and and really consuming those security patches that SAP is providing monthly and periodically to SAP customers. In terms of agenda, a little bit of what I already mentioned, but I will go through introductions. I I’ll I’ll talk about the analysis research labs. Vic is gonna talk about the prod security response team. And then we’ll deep dive into the CVE twenty twenty five three one three two four, threat actors that we have observed targeting this vulnerability. And then they somewhat. Right? Okay. What our organization should do? Not so much on the this specific CV. We’re gonna talk about the the related vulnerabilities and all of that. But since this is from last year, our expectation is that most organizations have already reacted in some way, shape, or form, but it’s more important, like, what do we do moving forward? Right? How do we stay prepared for any type of that is coming through a pipeline and how organizations should be consuming and reacting to that? So I wanna start with the OnAxis Research Labs. This is a team of security researchers that I’m very proud of. This team is periodically analyzing and understanding, on one hand, the threat landscape of threat actors targeting SAP technology and SAP applications. And on the other side is the actual technology around SAP applications and identifying potential improvements, specific vulnerabilities in different components. And we work hand by hand with SAP. We report those vulnerabilities through our responsible disclosure methodology. And when there is a patch, then we publish after sometime after that, we publish advisories about the different patches and vulnerabilities and what are the the potentially affected technologies versions and and work from that. This because of the work we do, this team has been involved in presenting at security conferences, working with computer emergency response teams like CISA, like BSI, and other computer emergency response team from different countries, providing threat intelligence and information to raise awareness around organizations that need to react in some way, shape, or form to different events, be it a new critical vulnerability or vulnerability being actively exploited by a threat actor or a specific campaign of massive exploitation of of different vulnerabilities. So we have reported hundreds of different vulnerabilities to SAP. We have reported over a thousand to both SAP and Oracle. So this team is very knowledgeable and very experienced around the technologies that support ERP applications. And that’s what lead this team to the continuous discovery of different issues that ultimately report are reported to SAP and Oracle and and ERP vendors to close those security vulnerabilities and and improve the the security of these applications. So that’s that’s something I’m very proud of because, ultimately, through the periodic release of security notes and and security patches, both on APSIS and SAP work together to secure improve the security of these applications. Right? And and that’s not just for our joint customers. That’s for all SAP customers. And that’s that’s something that really makes me very proud because we we share mission of of running more more and more secure applications. And in terms of numbers, if we wanna quantify this a little bit, well, we can quantify from the side of security vulnerabilities reported to SAP and patched by SAP. On the left side of the screen, you can see the graph highlighting the critical and high vulnerabilities from twenty seventeen to twenty five released by SAP. So those are all the the ones that are released by SAP that have been released by SAP over time. And on the right side is the OnAxis contribution. Right? So we’re talking about twenty five percent of SAP’s most critical vulnerabilities. We’re talking about hot news critical highs. Right? So the OnAxis research labs was directly involved in the discovery of these these issues. But overall, over two hundred and eighty tolerable vulnerabilities lead to two more than two hundred and ten SAP security nodes since twenty twenty. And I believe this is from twenty twenty to twenty four. I think it’s not inclusive of twenty five. But in in twenty five, that’s another thing that I’m very proud of is the analysis research labs was directly involved in the discovery of more than fifty percent of these patches that led to critical and high security nodes. So if we think about the the contribution, right, that’s that’s a significant contribution to the security of this technology and these applications directly through resource disclosure, through security research, through joint collaboration between SAP and Anapsis on this in this demo. So, again, we can talk about numbers, but what I wanna emphasize is this objective that we both share that is securing SAP applications. And and we do that in in many different ways. Right? And with that, I’m gonna pass it over to Vic for introduction of the security response team and and his side of this. Thanks, JP. So on my side, I also want to say a few words about our responsible disclosure program. SAP does welcome external submissions of any known security vulnerabilities. We work hand in hand with different stakeholders to resolve these security vulnerabilities and release to customers. For example, we we do have internal bug bounty program, which actually welcome security researchers to join, as well as for some of the security research companies like Onapsis. We also work very closely with them in terms of submissions, classifying security vulnerabilities being submitted. And in this particular case that we are going to see, we also work through some of the deeper dives into a particular scenario. Between SAP and ONEPIS, the responsible disclosure relationship is rather unique, and I think it’s also worth highlighting in in a particular slide deck. Like JP have said, we also recognize that ONEP has have a very deep technical expertise across different ERP systems, including SAP. And we have also been observing over the years a very persistent effort in working alongside with SAP on different security vulnerabilities, scenarios, some of the theories in how to secure the SAP applications. We also want to recognize the effort and also from our side to say thank you to helping securing SAP applications. Back to you, JP. If do you have anything else to add in terms of our collaborative response model? Yeah. Absolutely. Thanks, Vic. Thanks for your kind words. Yeah. And I think, on this slide, what we can, visualize is really the the two different sides of the coin, right, how the these two sides work together with the ultimate objective of securing SAP applications. On one side, SAP releasing the patches with rapid development, testing, emergency security notes release, all of those processes that that you know very well, Big. On our side, we capture threat intelligence. We maintain and develop a threat intelligence network with the objective of being able to understand what threat actors do around SAP applications when they attack these systems, attack reconstruction and forensics. We we do that with our network of threat intelligence, but also when customers are have incidents that we that need help. Right? Incident responses, identify the root causes of of vulnerabilities, generate IOCs and TTPs, and and share IOCs with the community like we did with the man with together with Mandiant in the CV twenty twenty five three one three two four, which we released two tools to help organizations being able to identify IOCs of potentially malicious activity through open source tools. Right? So together, working on with the same objective with different capacities, but all amounting to more security and better better collaboration. So thank you as well. And let’s let’s talk about the this specific CVE, twenty twenty five three one three two four. This this was a vulnerability that popped up last year. And the vulnerability specifically is actually, when it was actively exploited, it was a a combination of two vulnerabilities that we’ll we’ll get into the details. But the core of this, the issue that that led to the exploitation of this was a deserialization. Right? And when we talk about deserialization, it’s important to understand what it is because this is a vulnerability that is not affecting only SAP technology stacks. These are vulnerability affecting Java stacks. Right? Any type of Java application. Actually, the concept of this civilization could affect many other technology stacks, but it’s very well known specifically affecting Java because there’s been research, and there’s been different vulnerabilities reported on on specific Java libraries and Java applications that led to a lot of post exploitation gadgets and and exploits that that were used and and can be potentially used with visualization inputs. So just to summarize this is, basically, the visualization vulnerabilities happen when there is no proper validation of an input that is controlled by the user, and that input is used to reconstruct specific SAP sorry, Java classes. Right? In the case of Java, it’s, like, a specific Java classes and objects that are serialized and put in a in a specific packet that can be sent over the network or even saved into a file. When when that’s reconstructed, if it’s not properly validated, that could lead to really serious consequences like, for example, common execution. How this happens is almost like an art from from the attacker’s perspective. Right? Because the exploitation of this happens through a gadget chain. So the the deserialization, when the object is red, that object is typically a combination of multiple classes, multiple objects that only by itself just deserializing deserializing one object is not a problem. But this chain of objects eventually leads to potentially a negative outcome like command execution. Ultimately, the last option in that chain is an object that allows to receive a command and execute that on the on the underlying operating system. So that’s that’s a flow. Right? And that’s the the key of these vulnerabilities. The key of CV twenty twenty five three one three two four was this new gadget. This new gadget that was known by by threat actors and was unknown to the public. Right? It wasn’t publicly known, but this there was a group of one or many threat actors that knew how to exploit this, and they were using it. So in terms of deserialization, untrusted input from a specific endpoint that could lead to remote command execution. And in terms of the timeline for this vulnerability, I I mentioned this was twenty five. This started actually, we saw through our threat intelligence network reconnaissance of this specific vulnerability with very specific non malicious payloads back to January twenty five. So once this whole attack developed and and the threat we saw threat actors using this, Well, going back in time, we’re able to unfold that, well, January twenty, is the the soonest we saw that initial reconnaissance. But then active exploitation, once they started using the this well known gadget, was around March. Between March and April, that’s when we saw this active exploitation unfolding and leveraging this vulnerability. The first public disclosure of this incident was in April twenty second through a blog post by ReliQuest that provided information about this still wasn’t clear if this was a zero day or if this was another vulnerability on on this Visual Composer, which was the the vulnerable component. Because some years ago, there was a specific vulnerability patched by SAP in twenty seventeen affecting the Visual Composer. So because of that, it wasn’t really clear. Wasn’t clear in the blog post either what type of vulnerability this was. Very close, very soon after this public disclosure by RelayQuest, we saw the first batch released by SAP, security note three five nine four one four two, basically restricting authentication into the Visual Composer, effectively stopping any any exploitation on that. Right? So this was the first patch very effective at preventing active exploitation because that was blocking through authentication, through specific authentication on that endpoint, the ability for anyone to connect to it. So that was effectively preventing any further exploitation of the deserialization vulnerability. Soon after that, we released an open source scanner to the community, to be able to identify if organizations have potentially vulnerable systems. That was on April twenty seven. Soon after, on April twenty ninth, CISA added the CV to the catalog of non exploited vulnerabilities, which is another good data point for organizations to understand that this this type of CV is is important to address. Right? Some days later on May second, we released again another open source tool in in collaboration with Mandiant. This was a more advanced IOC scanner that was basically focused on analyzing the the systems, analyzing the the files of the operating system, and looking for IOCs, well known the let’s say, Right? These IOCs were looking for JSP files and logs of the visual composer on the Java logs. So by using these IOC scanner, organizations were able to actually do additional forensics on the potentially compromised systems. Some days after that, SAP on the following patch day released another note. This is based on collaboration with on APSIS, the note three six zero four one one nine, CV twenty twenty five four two nine nine nine. So these effectively removed the on that component, which was another step into the right direction from a defense in-depth perspective. Right? Even though if organizations patched already, with the initial patch, they were effectively blocking any potential unauthenticated expectation. From a defense in-depth perspective, this this was a good improvement to prevent any potentially authenticated abuse. Right? Again, CVE twenty twenty five, a few days later, Fortune nine ninety nine was added to Sisaqueb because of how tightly tightly correlated, it was with the active exploitation. And then, we started seeing some additional global alerts like the Canadian Center for Cybersecurity, Belgium CCB, and other computer emergency response teams also released alerts around the these vulnerabilities. So it was a very packed timeline with many events. I’m sure SAP as well as us, we had a lot of activity and and really hard work around this to to be able to help organizations really address this and and, also stressing the fact from day one, from the very first batch, from the day that the very first batch was released, highlighting to organizations, hey. This is important. You need to address this. You need to patch, because there’s active exploitation around this. Right? So that and that’s, that’s what made this, this whole incident in in twenty five different from other cases. In other cases, we have seen vulnerabilities being exploited by threat actors, but, after the patches were available. Right? So, in this case, this the the active exploitation started before the patch was available because this was effectively a vulnerability that was known by these threat actors and no one else. And that’s that’s why it’s so important, responsible disclosure, so important, security research and security collaboration to to be able to effectively close this this potential. And I wanted to touch base on the also very related to the close collaboration we had with SAP because what happened soon after CV twenty twenty five three one three two four became actually noted and and and and widely exploited, we realized, hey. And this was actually our conversations with the research team. We realized there’s someone out there that knows this gadget that has this understanding of how to exploit combined very specific classes, including some classes of specific SAP libraries to ultimately achieve common execution through a deserialization endpoint. So our rationale behind this was we have an almost like an obligation to go and analyze all of these, potential endpoints that could lead to the deserialization attacks. And we work very close to SAP. We reported all of the different endpoints that we found, which led to different CVs. Right? Close collaboration, patches in May, patches in July, patches in September, but leading to ultimately a broader solution coming from SAP, which was blocking specific classes at at a global filter at the JVM level. Right? So now if there is another endpoint that comes into play, right, there’s another deserialization potential endpoint, well, this gadget is not possible to be used anymore, right, because this JVM deserialization filter now includes, well known classes used for standard exploitation gadgets in WISO serial framework and other frameworks, but also this new gadget that that was observed in May. So I think this is a good a good sequence of how threat actors started exploiting something. The close collaboration between Onapsis and SAP effectively came into play to strengthen the security of these applications, ultimately leading to a defense in-depth approach. Whereas now, this gadget that is known by threat actors is no longer possible to be used outside. So it it’s a it’s a good good story and and with a good outcome, ultimately, which we’re gonna enforce organizations to make sure that that note is properly applied to effectively block potentially any other visualization. Let’s go into some of the details of actually how threat actors exploited this vulnerability. Right? What happened? Some of these data points actually are not coming from our from our insights. Right? This is coming from publicly available information. There were threat actors actively exploiting this vulnerability, looking for, exploiting systems, and this led into organizations actually working with different firms, like EclecticIQ, four Forescout, TNT five, ReliaQuest, Palo Alto, Rapid7, many different cybersecurity firms were involved into different incidents or or exploitation events where they had to go and and analyze what happened and saw different type of threat actors leveraging this. And we can see some specific China Nexus related threat actors, some ransomware threat actors were mentioned as well. And, you know, being able to put specific names behind these actions is very hard. It’s I’m I’m not gonna say we are experts on that because we’re not. So I will I leave we leave that part to the incident responders that are always working on specific incidents affecting different vulnerabilities, different technologies. They have much more experience, with pulling a name to to whoever is behind those type of incidents. Just wanted to highlight some of the publicly available information here, some of the, targets that were mentioned in the media, and the and some of the specific, victims that were mentioned in, in those publicly available sources. Right? So this, this wasn’t, just, the SAP security community talking about it or or mentioning it. This was really, the broader cybersecurity community involved into many different, capacities and and aspects. What I wanted to, cover as well is the the exploit because we were able to capture specific intelligence back in that we shared earlier in the year with with SAP, for example, the the exploit that was used to ex achieve common execution on these systems. Right? This exploit was not publicly known, and and, really, that was a a key for us to be able to understand how these redactors were exploiting. And we were able to do that because of our threat intelligence network being able to capture this activity. Right? But then in August in August fifteen of twenty five, there was actually a public release of this in in a telegram group supposedly managed and and used by hunters. Shiny hunters. This is was a combination of of different threat actors. And that’s when we were able to actually see the other side. Right? They they released the the the code that generated this exploit. On the other hand, we actually had the the payload that was used, and we were able to see that they matched it very well. Right? So this was actually this the same exploit that was used back between March and April. We were able to see that this exploit had specific the script to generate the exploit had specific parameters to work make it work on different versions of Netweaver, which made us think that, hey. These directors do have, specific knowledge on the SAP technology, in in a way that they can craft a very specific gadget using SAP classes, but also making it work across different versions of of SAP applications. So that talks about a specific sophistication around the the knowledge that they have on on SAP technology. So we observed when when we did incident responses and work with the incident response firms helping different SAP customers, we’re able to see the type of actions that were executed when using this exploit, like extracting specific SAP configuration files, SAP key stores, and and different type of very specific post exploitation activities. But this was all enabled by by these specific experts. So it became more widely known in August of last year. And after that, we started seeing an uptake of exploitation attempts as you would expect following the release of an, hopefully, with organizations and SAP systems being patched and and more secure back then. Just some additional details on what we observed back in April, March, April, but also what we could correlate with the exploit that was released in August. The version, as I mentioned, some specific, let’s say, techniques. They used apparently some of the classes from y so serial, which is a well known framework to basically craft and use serialization exploits. But they modify some of these classes to make it look like customs or very, very typical of to prevent specifically being detected by by signatures or or other IT security products, right, like generic signatures for those specific texts. Yeah. So just some highlights on the on the exploits. But let’s continue with the strategies behind this. Right? What should organizations do in order to prevent this type of incidents from happening? So in the end, it’s sort of all patching. And we’re gonna talk about the patching process. This process that takes place is actually a a living process. Right? So you build a patching process in your organization, and you react typically monthly, right, on patch Tuesday, second Tuesday of every month. But it’s a living process. You get new patches from SAP, and you react to them. Now I I wanted to make a clarification. There is the best case, which is what we all recommend is, like, if possible, go and address all of the patches. Right? If you have the capacity, the bandwidth, if that’s an option for you, make sure that you apply as soon as possible all the patches released by by SAP in a timely fashion. Right? If that’s not an option, at least prioritize the most critical ones. Right? So those hot news, those high priority, let’s make sure that you timely apply those because those are especially the hot news, those are the ones that tend to be exploited afterwards by by threat actors. That those are the ones that follow public exploits and that that are added to the cover of known exploiting vulnerabilities by CISA, and and threat activity follows that. So, again, like, the the recommendation here is if you have the the bandwidth and the process and and the capacity to absorb absorb as much as possible, apply and patch as much as possible. But if you need to prioritize, make sure you prioritize on on the from from by criticality. Right? From the most critical to the least critical, so matching your capacity and your ability to react. There are different sources that you can that you can leverage, SAP security notifications. There are there is a blog provided by SAP as an analysis to the recently released patches. There’s a blog provided by Anapsis as well as an analysis on the recently provided patches. There’s there’s different resources you can use, but also you need to be able to maintain this program and this process and know that it’s not just second Tuesday of every month. There could be emergency patches as as it was CVE twenty twenty five three one three two four. So if that’s the case, at least you need to have a process in place. So you need to have you you need to understand who’s taking point on on that, how you’re gonna be addressing those, how you’re gonna be making decisions when you see these type of critical patches. Some additional resources I wanted to share with you, security notes in the SAP for me, formerly known as the SAP Launchpad. There’s the security notes. There’s the notes and the security notes as well. Of course, in this case, we’re focusing on the security nodes, which are the ones that have security impact. There may be other nodes related as well. So in general, nodes are a good resource to to keep at hand and and and use. The SAP trust center as well with guidance and advisories. From the synopsis side, the thread research blog, as I mentioned, we release a blog following the release of security notes every patch Tuesday. But, also, we release note blogs about different type of threats that we see, security best practices, and many other topics that that are useful for organizations to follow. We also release whenever there is a critical issue that needs timely, let’s say, timely attention, we release IOC scanners and open source tools to to work with that. So, of course, we publish that content in our solution for our customers, but that’s not just all we do. When there is time is of essence, we open source information for all SAP customers to to be able to consume. And all of the research that we released as white papers, as advisories, as blog posts, as as I mentioned before. And then there are other resources from government agencies. I mentioned the catalog from CISA, the catalog of non exploited vulnerabilities. So it’s important to stay on top of that because sometimes SAP vulnerabilities are added to that catalog, and then it becomes really, really important to to react. Alerts from CISA as well, and there are many other certs as well that are important to follow depending on on the the country your organization operates in, if it’s in Europe, ANISA, if it’s use USA, CISA, but there are other country specific certs as well that, that we can follow. Alright. Just wrapping up a little bit on the on the content. We need to be proactive. What what is the difference between CV twenty twenty five three one three two four? Well, there is a before and after because that’s the first that was the first time threat actors actively exploited an issue before there was a patch available because that that demonstrated that threat actors also have the capacity to build this type of exploits and identify these type of vulnerabilities. That’s why being proactive is important. From the analysis side, our way of being proactive is really proactive security research, analyzing those components, working with SAP, closing those gaps, and and really enhancing our telemetry into our customers. And when when this is an urgent matter, also, we open source that knowledge. But, yeah, from from an SAP customer or an an organization perspective, it’s really cloud transformations. No longer the case that, the the organizations keep their systems behind the firewall. Now more and more, it’s some of our systems are on premise, some of our systems are in private clouds, some in public clouds, some in platform as a service. All of these interconnected. So it’s important to be proactive to have a process in place to address security on our, mission critical systems as SAP applications are. Some additional resources for for all of you in our GitHub, LinkedIn, patch Tuesday blogs, but blogs in general. There’s a third research available if you can scan the QR code. But we are here to help and just wanted to stress to say thanks to Vic for joining me on this session. Thanks for the close collaboration we have and the the trusted partnership we have had for for several years. And, yeah, just to reinforce the the fact that we are we share that mission of securing SAP customers in overall. Right? And with that, I think, we have some time for questions. Perfect. Thank you very much to both of you. That was a lot of information and it generated also a few questions. I’m just going to read out a few of them. Let’s start with the first one. From your perspective, what made CVE twenty twenty five-three thousand one and twenty four particularly dangerous compared to other SAP vulnerabilities we have seen so far? JP, I think we can’t hear you right now. Oh, yeah. Sorry. My bad. I muted myself. It, yeah, it happens, happens quite often. Okay. I I I was saying I was saying that this is the the difference between this CV and others is that this was the first time that we saw this vulnerability being exploited before a patch was available, and that was because threat actors had this knowledge, before anyone else. Right? And that made a before and after because, that reinforces the fact that if threat actors have the resources and have the capacity and the means to do this, they can do it. So, we, as the security community, and the and SAP customers as customers, we all need to be, aware that we need to be proactive. Right? So we need to address cybersecurity, and we need to make sure that our systems are properly taken care of. Right? So that’s that’s a for me, the biggest difference is is that. It’s really, these redactors prove they they have the the capacity and the knowledge, which is actually, something that we have many conversations with, with many pros prospects and and customers in in the past. I mean, the past, I mean, like, for the past fifteen years, whereas, hey. Like but attackers or threat actors don’t don’t know about this technology. Right? They they don’t have the the the knowledge on on how to target this this technology. Well, they do. Right? So it’s important that we we stay focused on and and proactive to and focus on securing our mission critical applications. And, JP, I think I will also agree with I will also agree with you. I think from from a vendor side, our perspective, of course, is ERP vulnerability management is not a easy task in it by any means. In this particular case, the CVE is is rated as CVSS ten point o. So one of the core message, of course, we say, you know, affected customers should have applied the patch by now. But, you you know and and like JP, like you said, you know, if if the patch is still not applied on the customer side, the threat will still continue. Absolutely. And that’s a good point, Big. And that that may be a a key takeaway as well. If if there is a CVSS ten, that’s as critical as it could be. So our responsibility as customers is to react to that. Right? So make sure that we we have the we follow the process. We timely react to it and and and follow recommendations and apply those patches because we know that those those type of CVSS can can be weaponized very quickly. Thank you. Then let’s get to the next one. How did Onassis discover threat actors had working get just chain? Sorry. Yeah. We we did that, because of the, threat intelligence network that we have. Right? So we capture real attacks to SAP applications with the purpose of understanding what threat actors do when they target SAP applications. Right? So be because of our as well proactive approach towards understanding activity, we really had a very good piece of threat intelligence in this case that was crucial to understand what was going on there. So, yeah, I think and and we we maintain and operate that threat intelligence network periodically with that specific purpose of understanding what threat actors do. Okay. And then, Vic, it looks like the next one might be for you. Did the collaboration between SAP product security response team and Onapsis actually work in practice during those initial critical days? I I will take a crack at it and then JP can add on to other details he may remember. I I remember during the early days, we do appreciate Onapsis a a lot, especially in in them proactively reaching out to us. On our side, of course, we are aware of the the informations and also the threat intelligence that we are receiving. Hey. Something seems to be wrong. And and like JP have mentioned in the early days, it seems to be like, oh, something is Visual Composer, and then, okay, there seems to be a patch, and then there was just a lot of information not really provided in any consolidated manner. So in the early days, Onapsis reached out to us proactively because of our existing responsible disclosure relationship, and we were able to work together to kind of analyze, okay, you know, what kind of what what kind of observations are we having. And in addition to that, Onapsis, like, also mentioned, they they have other IOCs that they are monitoring. They they they also sharing rather transparently with us on what is going on. That definitely has helped SAP to develop a corresponding patch to to protect our customer base. And for that, we SAP does appreciate Olepses’ assistance in that regard. Yeah. And I can take a crack at it. Those early days were definitely very busy days where I recall long nights of of teams working to understand, hey. What what’s going on? What what can we do? Like and and really in collaboration with SAP as well, really trying to put things together in a way that was, most helpful. We did that, with the releasing the the open source scanner as well and and then the IOC scanner. But, but, yeah, that, the ability to be able to see what was happening, I think, was very important, and we share, of course. And and and to me, the other important part was really realizing, hey. Like, this is something that could be potentially used in other serialization endpoints, and that’s why we we had work on that. We we had a lot of projects and everything. We literally dumped everything, and we started looking those areas and started reporting SAP and working with SAP on on these other additional potential potential vectors. So and and eventually leading to this JVM ultimate fix. Right? So so, yeah, that’s that was definitely a a close collaboration and a good good outcome from my side. Actually, you just said JVM. Maybe one question that came in as well picking up this one. Can you explain the thinking behind JVM wide hardening? Good. I I will defer, then to to Vic if you want to comment. But, the the rationale behind that is basically preventing any the the so to exploit a deserialization vulnerability lead two things. One is the deserialization endpoint. Like, some some way where an application receives user input that is deserialized. And the other one is that malicious gadget chain that is very, very hard to build, very, very difficult. And so we knew that threat actors had this this gadget chain, but then we knew that this potentially could be used in other endpoints. So that’s why we started looking into other endpoints. But then how do you patch that once and for all, not depending on analyzing all of the endpoints? That’s basically with a global filter that no matter which endpoint enters, which endpoint is being used to deserialize deserialize malicious potentially malicious input, then that gets filtered independently. Right? So that’s with a filter at the JVM at a very under underlying core, let’s say, primitive, which which that’s the right way to to address this. Right? Because you you address this once and for all independently of how it’s being serialized in which endpoint. So I think that was a very good move in in the right direction from a from a security in-depth perspective. I think from SAP side, I think to reiterate again, we also appreciate Onapsis’ persistence on the topic because oftentimes, like I also mentioned earlier, Onapsis sometimes will well, actually, not not sometimes, but more than once, they will come up with questions and also theory of attack. And in this particular case, I think that illustrate a good example of what happened. Because beyond just fixing the immediate threat and and also looking at at the at the at the IOCs, I think Olepsis comes back and and and start asking questions. We also have internal security controls and validation steps who also discover something similar, which kind of yield to digging deeper into the issue. And on that and on that, I think I think we also appreciate on nepsus in in asking questions, which actually leading to what what we can call, like, a once and for all approach to the security problem rather than just being transactional and focusing particular vulnerability on one piece. So, yeah, I think that that is what I would say for the JVM wide hardening. Great. Thank you. I would say let’s get to the last question to finish on time. How should SAP customers be thinking differently about their vulnerability management and monitoring strategy after this zero day? I I I will I’ll take it first. I’ll go ahead, JP. Yeah. I’ll take it first because my message is my message is quite simple. SAP strongly recommends our customers to patch immediately or and as possible. I think one of the good slide that that that was shown is, you know, the security the best security was yesterday, and the next best is today. Right? With the changing threat landscape, the expectation is there will always always be patchings coming out. And I think JP also go through some of the some of the his observations in terms of trying to create a vulnerability management protocol for for their customers. And and I think we we also would would support that. But overall, the message is, of course, is patch as soon as you can. Over to you, JP. Absolutely. I I couldn’t agree more. And I think, to me, it summarizes as being purposeful. It’s like, we cannot just try to check the box when it comes to security. We need to be purposeful. We need to be proactive. We need to make sure that we are addressing security properly. Right? And that means apply the patches timely. That means monitor your systems. That means addressing many different areas of security. One of those really, really important being patch management. But to me, it’s really it’s all about being purposeful, about security, especially in this world where we are transitioning to RISE, where we’re we are, really embracing new technologies and and and extending our cloud applications, integrating with our on premise systems, we need to be considering security. If we didn’t consider it yesterday, we need to consider it today as as big sell, but but that’s important. Right? Patch your systems and and address security. Be proactive around security. Great. I would say that brings us to time. For any other questions in the chat, we will be reaching out to you individually to get those answered as well. Also, just a brief reminder to everyone listening that this session has been recorded and the link to the recording will be emailed to you. With that, thanks again to Vik and JP and everyone joining the session today. Have a great day. Bye.