Thank you everyone. Welcome to this session, Such great talks today. I'm very happy to be here and I'm gonna talk about five things every C should consider. My name is Natavo Vial, I'm the director of threat research in Imperva. And let's start with this distributed denial of service attack. I'm sure everyone here know about DDoS. So what we're seeing is increasing numbers not only in security incidents but also in the volume of traffic that we're seeing if once attacks over one TE per second. Were considered to be rare today we're seeing this all almost on a monthly basis. So not only the number of incidents and the volume of the incidents, but also the duration of the incidents that we're seeing. So last month we saw an attack that classed four hours long with that record of 25 billion requests. That's huge, huge amount. So the reality is that more than 50% of organizations will be hit with DDoS attack and not only will they be hit once, there's a very good chance that that if they're being targeted, they'll be hit more than once.
So it's not only about the numbers, it's also about the sophistication. If once where we used to see, we used to see huge, huge botnets with a hundred of thousands of devices used by hackers to launch DLA attacks. What we're seeing today is that even small nets with just a few thousand devices can create a big, big impact. The way that they do it is by using different type of protocols, different type of amplifications, changing the velocity of of the attack to cause a lot of impact in the, in the screenshot here, you can see if you can see a charter from a hacker Telegram channel discussing how they can bypass imper solution by changing the velocity, also changing the protocols. They didn't succeed in their mission. But this is something that we're seeing when talking about the evolving threat of datas. You cannot forget about ransom datas.
So this is an example of a ransom note that one of our customers received a while ago stating when the attack is going to happen, that they the, the attacker can bypass the solution that the customer have and obviously the amount that they need to pay in order to avoid the attack. Following this note comes a very small demonstration, low rate attack, accompanied with another note saying, We're able to do this. This is like just a demonstration of our capabilities, you need to pay us. And if they fail to pay, then comes a much bigger attack for a longer duration. Also accompanied with a message from the attackers the saying, You are on our list even if you stop us now, we'll be keep targeting you until we get you to pay us. So what should you consider regarding the DDoS threat? First of all, you need to build a solid incident response plan.
You don't want to be caught off guard when you are being hit by ados or when your services are down and make stuff up as you go along. Second thing is you need to ensure you have business continuity plan, a disaster recovery plan to deal with these threats. And the last thing is you need to choose a DDoS protection service that require no prior knowledge about your network, your topology, and no manual configuration. So very often we see network topology change, new services go up near some services go down and you need a solution that is able to know your network, learn it automatically and create the best possible mitigation. So we talked about DDoS, what we know about DDoS ERs that are very quick to adapt. So if there are, if they see that they are being stopped in one place, they're very quickly will shift to another place.
And one of these places that we know attackers shift to is API servers and API endpoints. And today we're looking at the statistic that more than 80% of organization use APIs with a minimum of 300 APIs on average per organization. And this is a very big number. It's very difficult for the security teams to deal with this number. And what we're seeing is actually a growing uncontrolled exposure of APIs. And according to the data that we see around 50% of API traffic is what we could we consider shadow api. Meaning that either the API was deprecated or never removed from the production services or that the developer published a new API developers published new API but didn't add to the inventory. Or it was a mistake that some developer took an existing hidden api, made some changes and by mistake exposed it to the public.
So when we're talking about API risk, there are typically two main risks that you need to know about. First there is a known patterns or vulnerabilities that attackers are using. And you can see in the chart here a 90% spike in incident in security incidents in API sites during December and January of 2022 when the look for J vulnerability was discovered. And this is in line. So what we know is that although the log for J vulnerability didn't directly affect APIs, we know that attackers will look for any kind of attack surface to try and exploit these kind of non vulnerabilities. The second type of API attacks are the one that are using completely valid API calls. So these type of attacks are not trying to exploit non patterns of vulnerabilities, but they are real trying to manipulate legitimate business logic that you have in your APIs. So it's very difficult and cannot be detected or stopped because the api, because the API call actually confirms with the way it's supposed to be. And today what we're seeing is that almost 30% of APIs are exposed to broken object level authorization, which is the number one risk at the OS API top 10.
So what should you consider when we're talking about API security first? And this is a recurring theme, you need to know your assets. You can protect what you don't know. If you don't know which API service you have, which API endpoints you have, it's impossible to protect them. Second thing is dynamic. In this dynamic business reality, you need to have a solid, robust change management for publishing and controlling your APIs. Any kind of change should be, should go through different set of approvals. And last thing is you need to choose an API protection service that requires no prior knowledge of your application and can offer you automatic mitigation based on what what we see and no manual configuration.
So I talked about the APIs that organization exposed, but what about APIs that you consume or the tools that you use inside your organization? And this is an example. This leads me to the next topic of supply chain risk. And this is a very nice example of a recent vulnerability discovered by Imperva and a security tool called cc. So many organization use CC to actually scan third party tools that they are using. So they using it either as part of the ci cd pipeline or as part of code development environments like VS code. So this vulnerability that we discovered actually allow attackers to run malicious code in those environments, which is obviously a big risk to the organization. So talking about supply chain attack or risk, we're also talking about web application supply chain risk or also known as client side risk. The reason it's called client side risk is because web application resources are mainly JavaScript libraries, JavaScript resources. And this is a necessity for any kind of web application because JavaScript libraries bring a lot of functionality, edit functionality to your website and it's impossible to run a website these days without any kind of JavaScript resources. And according to what we're seeing is that 70% of web application resources are consumed from third parties, which is a really, really big risk because you have no visibility or control over those libraries.
So this is an example of typical supply chain risk for web applications. The scenario is the following. You have an attacker that gains access either directly to the website by explaining some known vulnerability or to a third party library that your, that your web application uses. Then the attacker injects a malicious JavaScript code. It can be a skimmer that steals data that is entered into sensitive forms, forms like logging page forms, like checkout pages, Those are typical forms that we see that are being targeted. Then after the skimmer is injected, all the data gets directed to the attacker servers. And from that point on, the attackers can either sell the data or conduct other type of attacks like carding or account takeover. So what do you need to consider when we're talking about web application supply chain risk? So again, you need to know your assets, you need to know which resources your application is using. Once you know that you need to identify malicious libraries and according to their risk. So you can, so you can identify so you can stop them and block them if necessary. And last thing is you need to choose a client side protection that has again, no prior knowledge of your application and can offer you the right mitigation to do with no manual configuration.
So I talked about supply chain risk and one of this risk that I highlighted in the example before is attackers trying to steal sensitive data including data in login forms. So this kind of data can quickly escalate to account takeover attacks. And account takeover attacks can happen in multiple ways. It can be either a brute force attack or a dictionary attack, credential stuffing attack or as an example before information still still malware in your application. So what we're seeing in 2022 is more than a hundred percent increase in account take over incidents, which is is a huge, huge increase and 30% of attacks are actually targeting financial services. And also 30% of attacks are targeting European web services with uk, Spain and Germany at the top. And I want to talk about a little bit about the impact of this of attack. So beside the obvious online fraud that account takeover brings with it, there's also an impact on latency and cost because when you are being attacked with this type of attack, it usually comes like in a very big volume which obviously has impact on latency and legitimate users are having trouble to connect and authenticate your application.
And also if you're using any kind of auto scale service or cloud service, there is, it's also come with a high cost at the end of the month.
So these type of attacks are usually being carried out by bots. And according to the data that we have, 25% of the bad bot traffic that we're seeing is generated by advanced bot. And when I'm talking about advanced bot, I'm talking about bots or softwares that can mimic human behavior by automating browsers. They can rotate between different proxies going through thousand of proxies going through thousand of ips very, very quickly. I'm talking about anti detection mechanisms and tools that can flood any kind of multifactor authentication service. So it will be useless. This is an example of a tool called open bullet, which is being used by attackers to conduct account cover attacks. And what you can see here that they have the attacker have special place to enter the configuration of the victim and special place, special place to enter a very huge list of proxies to rotate between them and a special place to to set all kind of acapture solutions to bypass.
So what should you consider regarding the account takeover threat? First again, you need to know your assets. If you only, if you're only aware about one login endpoint, you cannot, you cannot stop the attack cause attackers will use any kind of login functionality that you might have. Either if it's in your web application, in your mobile application, in your APIs, they will use whatever they can. Second thing is that rate limit or multifactor authentication are a good starting point, but there are not enough. Again, advanced bots will bypass those protections. Last thing is that you need to choose an account service that understand the context of the authentication in your application. And this is crucial to understand how the normal behavior of the authentication occurs in your application. Once you have that, you can very quickly detect any kind of malicious activity in the authentication.
So if an account over attack is successful, it leads the way to another risk which is compromised or malicious insider and this type of attack, either the, the user is maliciously doing some kind of damage or it's being used to do some kind of damage. And from a research that we did in Imperva analyzing more than a hun 100 data breaches from past years, what we saw is that attackers are usually targeting PII or intellectual property as their main goals. This is an example of a compromise internal database that that we saw. So in this, in this example, what the attacker did once he got into the into the organization network, he deleted all the databases that he could find, created a new one with a warning to pay a big amount of money just in order to restore the data that they deleted. And out of this example, another example that we saw and analyzed, what we know is that the following techniques that the attackers are using, they're using administrative tools to hide malicious operations.
In the example before, what we saw is that the attacker used a tool called SQL dump, which is usually being used by administrator to do database backups. We're also seeing users, sorry, attackers abusing service account to hide access to sensitive DA user data. So this is also something that we see a lot trying to shrink, prevent or go bypass existing security solutions. And the last thing is that about data exfiltration attackers will often try to use critical services and protocols to hide the way that they exfiltrate data out of their, your organization for example, using DNS protocol. So it's a very known technique for attackers to take data out of your organization without being noticed. So what should you consider about this type of threat? Again, saying this for the fourth time, you need to know your assets. If you don't know which databases you have, which file survey you have, you cannot protect them. Second thing is zero trust. You need to build your defense strategy under this, the assumption that your network is already compromised. And the last thing is if you are choosing a data protection service, you need to choose one that understand the normal behavior of your organization, user and services. And this is crucial because if you don't have that, it's impossible to alert or catch any kind of malicious behavior.
So this is it. If you have any questions, I'll be happy to take it Now.
Any questions? I think none. I've raised five very good points there. I mean surely there are some questions in the room we have, I know we're running over, but if there's a burning question in the room, it would be great to take it now. Yeah, sorry. Sorry. So
In the research you've done, is there any evidence to show that if the end user has tools like yours that it makes a difference and what difference it makes?
What, what was the first part?
If, if the, if the end user uses tools like yours, solutions like yours, is there any evidence to show that it makes any difference?
That's a nice provocative question, sir.
So you know, we cannot predict everything, but you know, we have to do everything that we can to protect against these type of risks. We cannot control what the users are doing. But if you have at least one of these points that are raised, you are, you are in a good position to reduce the risk as much as possible. I hope that answers your question.
Do we have any other questions in the room while you're thinking, if I may, Given that nothing really changes, why is it that organizations continue to be unprepared for cyber attacks and what is, what is key to using the five points that you raised?
So organization will keep, you know, will, there will keep being a target just because it's lucrative or beneficial for attackers to, to keep attacking either if it's for money purposes or if it's a competition purpose purposes. So these type of attacks won't go away. Just you need to be able, what you can control is how you are handling those attacks and how you are preparing for those attacks.
Okay. So in other words, you need to be aware and just know what's coming down the track. Okay, well that takes us two time. Thank you very much.
Thank you.
