RIPE 92. Side room. 4pm
Security:
BRIAN NISBET: Hello, good afternoon. And welcome to the RIPE 92 security working group. My name is Brian Nisbet and with me also are my co‑chairs, Marcus de Brun and Tobias Knecht. I am worried that my weak joke is the font size is too small, but Sasha may or may not have been here. Marquees abound.
So, yes, welcome to the working group, thank you for joining us this afternoon, we have quite a null agenda so we'll be.moving through it all. Before I begin just some announcements, PC election has opened as of now and will close on Thursday at 17:00. There will be a session on diversity, equity and inclusion and tech today at 18 :00 in the main room. And just as a reminder, there's no buses to the social tonight unless you have accessibility needs. There's a bus leaving from the Moxi at 20:45. Please bring your badge. And possibly mention that again, at the end.
So, we did the welcome. There is a scribe, thank you. We are monitoring chat on Meetecho, so if you are online, you can enter your questions into the Q&A, if you really want to, you can join the mic queue there and we have our wonderful stenographers recording every word we say. If you are asking a question, please state your name and some affiliation, it would be nice if it was an actual affiliation. I can't stop you making stuff up, but remember that all interactions in the working group and mailing list are covered by the RIPE code of conduct. You can rate the talks today, it's a working group, it's not just talks, but your feedback is really useful, both via the rating system and the mailing list from the point of view of what we are doing as a working group and what content is useful on the mailing list and at meetings.
So, minutes from RIPE 91 were circulated. Are there any questions or objections at this point in time? Hearing and seeing nothing. We shall assume they are all good and move on.
I mentioned pre‑talks, we have all transitioned to using the new system and thank you to it the various presenters and working group who interacted with it and the NCC folks who managed the system for us. This was the system, but more me interacting with the system, why the draft agenda was so late going to the mailing list, we'll be doing better next time and not trying to make it all perfect before we send any things out.
So before we kick off anything else that people need added to the agenda, any AOB we can talk about later? Again seeing nothing, we shall continue and indeed we are continuing now, we are moving onto the first piece of interaction, which is from the RIPE NCC and it's the LEA transparency report so Franca, hopefully you are there and can share.
FRANCA BOSOMPIM: Yes, I am here, hello everybody.
BRIAN NISBET: The slides are up so please go ahead.
FRANCA BOSOMPIM: Yes, hi everyone and thank you for taking the time to join this presentation. I will be giving you an update on the LEA transparency report for 2025 and then explain what the e‑evidence regulation is all about.
May name is Franca Bosompim and I am a senior legal council at the RIPE NCC.
So to start with, I will provide you with a short background and then we have dive into the actual report.
So the reference you see is a require administers both publicly available and ... which LEAs sometimes seek access. So, currently, the RIPE NCC never shares public information unless backed by a Dutch court, but they will look at the changes that are going to happen during the second half of this presentation.
In 2025, the RIPE NCC received a total of 99 requests down from the previous year's 115, eight of the requests were binding and from Dutch LEAs.
Now, we will dive into the actual numbers for 2025. So for non‑public information, we received eight legally binding requests from Dutch LEAs, which we complied with and two non‑binding requests from non‑Dutch LEAs which we didn't comply with.
We also received a total of six requests from public information which we then shared with the LEAs and a total of 81 requests for identification of internet users of the particular IP addresses which we could not comply with.
The RIPE NCC also received a request for information not at all related to the RIPE NCC, and in that case we explained the RIPE NCC's role as a region internet registry and finally received a request for a specific action which we did not comply with. But if you need more information on these requests or if you would just like to see the actual legal breakdown, then it can ‑‑ that can be found on the website in the LEA report for 2025.
As you can see from the graph here, the majority of requests relate to individual users and so information which the RIPE NCC does not have. Most requests come from France, we had 32 in 2025 and obviously from the US and we had 28. We actually observed an increase in requests after 2022, peaking with 200 requests in 2023. The trend has actually been declining since and most requests, as I have explained, generated from France and related to data not held by the RIPE NCC. But the numbers have been declining to 32% in 2025, compared to 66% in 2022.
Binding Dutch LEA requests reached a record high with eight received compared to previous high of two.
But we find that generally LEAs are receptive when unable to provide the information requested, and this is likely due to the information provided within the trust portal and also as a result of the engagement and education activities. And I will let my colleague expand on this a bit more.
BRIAN NISBET: We are not sure if our colleague was expecting to expand on this more, but it's good for the cardio.
SPEAKER: Thanks. Dick ... from the RIPE NCC. Just to expand on what Franca is saying and the reports and the requests we get from law enforcement. We have been doing a lot of outreach recently, as we try to reduce the number of requests that we get that are out of scope for the RIPE NCC and educate law enforcement with what we do have and what we can and cannot share. And recently with the help of Europol, who is in the room somewhere, we ran a webinar educational three‑hour session for law enforcement and we had roughly 700 law enforcement officers from 37 countries in attendance, and they sat through the whole presentation from Gerardo, from our training, explaining what it is we do and don't do and what information we have and what information we don't have. So hopefully, continuing that ‑‑ this is that is the biggest ‑‑ I have been doing engagement with law enforcement for a long time, that's the biggest one we have had by far, normally it's in the 20s, 30s; we had 700.
Two things I take away from that, there's an interest in the RIPE NCC, at the same time it's great outreach for us to explain to them what it is that we do and don't do, which is really really important, and what information we have and we don't have.
Hopefully, that will reduce the number of requests that are out of scope. So like France and I have been speaking to Arran about trying to do the same for the USA because we need to reduce those, we don't mind the requests that we get, they have to be in scope because it's efficiency and it saves Athena and her team, and Franca and her team. That's with all I wanted to say on that. Antything else, Franca?
FRANCA BOSOMPIM: No, thank you.
SPEAKER: Any questions on that? OK, good. (APPLAUSE.)
FRANCA BOSOMPIM: Thank you. We can now move on to the second part of the presentation and it's about the e‑evidence regulation. So we are going to be looking at the background of the regulation and also how it applies to the RIPE NCC. The regulation is going to be implemented in 2027.
The e‑Evidence package consists of both the e‑Evidence regulation and the e‑Evidence directive. Neither has been transposed into law in the Netherlands yet, but we expect this to take place in 2027. And the Dutch government has unfortunately missed the February deadline, but the legislation is actively progressing through parliament. We still have limited information about the e‑Evidence directive and so this presentation is going to focus on the regulation, which establishes the conditions within which law enforcement authorities can directly order companies to hand over or preserve digital evidence for criminal investigations or to execute sentences. And it doesn't matter where the company or the data is located.
So what is the e‑Evidence regulation? Well, it comprises of a European production order and European preservation order. And European production orders which one once issued become European production order certificates, allow a judicial authority in one member state to directly compel a service provider in another member state to produce electronic evidence for criminal proceedings. European preservation orders, which once issued become European preservation order certificates, allow judicial authority in one member state to directly compel a service provider in another one to preserve data.
Why does the regulation apply to the RIPE NCC? Well, it does so because of two main reasons, one being the RIPE NCC is an internet registry with IP numbers and IP address assignment related services within the union. And one thing to note which also mentioned previously but it's important to know is is that the regulation applies regardless of the location of the data.
What are the types of e‑Evidence. The regulation identifies three types of e‑Evidence data. But only one is applicable to the RIPE NCC within the meaning of the regulation and that is subscriber data. Because it relates to basic account information that a service provider holds about a customer and in the case of the RIPE NCC, this is information it holds about members and it's things like name, address, contact details, payment and billing information and the type of service that they sign up for.
The RIPE NCC does not hold traffic data or content data within the meaning of the regulation because it does not provide communication services but only internet resource allocation and registration.
IP addresses, they are not explicitly defined within the regulation, but in the case of the RIPE NCC, it can be part of subscriber data in the form of information about a RIPE NCC member to whom an IP address is registered. But not as part of traffic data which identifies the individual actually using a specific IP address.
So there are key differences between preservation orders and yes, between preservation orders and also when LEAs ask us to provide information to them, and that's because there are different risk thresholds apply. So this means that there are different ‑‑ there's a different outline to respond to orders and it's ten days or eight hours in the case of emergencies for preservation orders and for preservation orders the data should be preserved for 60 days.
Emergency orders can only be treated if there is imminent threat to the life or safety of a person or the disruption and destruction of critical infrastructure. We think it's unlikely that the RIPE NCC would receive such requests because subscriber data is hardly that critical, but we are monitoring the implementation of the directive to to better understand how the government is going to implement the system that will allow us to receive such orders.
And all orders must be accompanied by certain information. And if not present, it can provide the RIPE NCC with grounds to object. If, for example, an order is incomplete or not validated but they require authority, or if the data is not held by the RIPE NCC.
Confidentiality is really important because we would have to keep secret and confidential any orders that we receive even if we cannot act upon them, and so we cannot notify any members if we ever received an order.
We are now working towards implementing the e‑Evidence package and we will update the extended procedure of the RIPE NCC for handling those requests once the government has fully implemented the package and we have a better understanding of how it would all work. In the current moment we are monitoring the developments within that government and we will continue to liaise with LEAs.
So in summary, the regulation applies from August 2026 but it will come into force in 2027 in the Netherlands. The RIPE NCC is using scope because it provides IP numbers services and so subscriber data and IP data falls within the scope of the RIPE NCC but not traffic and content data, there are two instruments within the regulation to either produce or preserve data, and there are objection rights for incomplete or invalid orders, and the and the RIPE NCC must not notify any members of the orders received.
OK, so I have now come to the end of the presentation, and if you have any questions or comments I will be happy to answer those.
(APPLAUSE.)
BRIAN NISBET: Thank you very much. We have a question.
SPEAKER: I have a comment. Alex... from come six. I am part of the expert group of e‑Evidence in Brussels and Brussels is of the opinion that the starting date is August 18th, and if the Netherlands hasn't implemented everything on the 18th, then it's a problem of RIPE, or whoever receives a notice, so do not expect that you have some extra time for the Dutch documentation. Thank you.
LEO VEGODA: Hi, Leo Vegoda, not speaking for anyone else. You mentioned the confidentiality requirement, does that mean that you can't share the details of a request or you can't include requests in your transparency report in the future?
FRANCA BOSOMPIM: That's a good question, actually, because it's possible that we may not be able to report in the same way that we have done in the past but we are actively trying to understand how that will look like.
LEO VEGODA: OK, well, I hope you can report on what the answers to that is at the next meeting.
FRANCA BOSOMPIM: Yes, yes. We'll make sure to do that. Thank you.
BRIAN NISBET: Or indeed via the mailing list if the answer comes before October.
FRANCA BOSOMPIM: Yes, I am sure it will.
SPEAKER: Another comment. The EU wants to have visibility on what companies receive, so there is a transparency obligation, you cannot tell who was the subject of a request but the amounts like your currently doing, that's fully possible.
FRANCA BOSOMPIM: Yes, indeed, it's just that we don't know exactly how we are going to be able to report but not that we wouldn't not report again when it comes to the e‑Evidence.
BRIAN NISBET: OK. Cool, anything else folks? In which case, thank you very much Franca. (APPLAUSE.).
Moving on. The global cyber alliance held a round‑table discussion meeting piece on Monday and Lesley will now give us a report on that around acting and ‑‑ infected, infecting infrastructure and things like that and words which are apparently now hard for me. So please, Lesley.
LESLIE DAIGLE: I like it, I like being able to see over the podium.
Thank you very much. My name is Lesley Daigle, and as Brian said, I am here mostly to report on the round‑table that we held yesterday morning. I appreciate that nobody wants to hear a meeting that they missed, but hopefully I will stay focused on the things actionable going forward.
I would like to thank everybody who did participate in the meeting and shared their thoughts and their learnings. This particular presentation will not go into great detail on the technicalities of all of the types of infected systems, but I know there's going to be an excellent talk in a little bit by Jerrome who will go into it in great detail.
First, why we were having the discussion. The main topic was infected and infecting infrastructure and residential proxies and this heat map graph shows you some notion of how prevalent the problem is. This is a heat map of normalised attack ‑‑ well, effectively normalised attack traffic from across the global cyber alliance sees in its honey farm. And a thing to note about this is the key areas of interest and the key areas of infecting interest are in the larger population centres for fairly obvious reasons, it turns out that hackers and another attack campaigners like to have good infrastructure to use.
And certainly the problem exists here on this set of islands, no one is immune.
It impacts infrastructure of all types, the kinds of things that we are sharing here are demonstrating infected infrastructure based in terms of frequency of attacks from individual IPs, persistence of attacks from those IPs and those different dimensions of attack.
A key thing to note from our current information, we did a look back over the last few years to see what kind of attack traffic we have seen in our honey farm and whereas the attack traffic had been fairly stable for the, for a few of those years, it largely started to hockey stick in late 2024. This is further evidence of the fact that attacks are getting more prevalent and scaling up. And this is perhaps why it's getting everybody's attention.
So in terms of the workshop, the discussion had a fairly ambitious agenda starting from reconstructing the elephant. I think there was a fair understanding in the room that there were ‑‑ individuals had very deep understanding of a part of the elephant that they work with, but it was useful to hear about the problem space from other perspectives as well. It's a global problem and the only way we are going to be able to address it is by looking at systemically and not just by going down individual paths of problem identification and addressing.
The next chunk of the agenda was focused on mitigation, what works and what does not. Spoiler alert, not a whole lot that works just yet.
But realistically what are things that can and should be tried systemically now, and which actors can r meaningfully take action on addressing infected infrastructure. We hoped to get towards a concrete action, a small but concrete collective actions that could be pursued in the next six to twelve months and I will say more about that later.
So, first, I am talking about infected infrastructure, largely individual hosts that get owned or that have software on them that are doing things that are not condoned by the owner of the infrastructure of the host. But there's a particular type of situation that has been getting attention lately and that is in terms of residential proxies, which a residential proxy is a bridge that routes third party traffic through a legitimate home IP address and that bit is important, and the traffic may be either coming from a compromised IoT device but in some cases it actually is brought into the home innocuously; it may be built into the SDK used to build a controller for your "Smart" ‑ have to use the scare quotes ‑‑ Smart TV. It may be involuntary deployment of these infected hosts, of these residential proxies through traditional malware approaches or maybe you going to the store and buying a new TV or doorbell, and there's over two hundred million of them deployed and they are used for any number of different activities, which is part of what makes it hard to track them down and stop them.
They are not two hundred million individually acting entities, these proxies, there's an industry that is actively farming these things, building them into t SDK kits and sharing them in applications. There are organisations that are corralling all of those individually farmed proxies into aggregated exit pools, and that's where you start to see the impact of large scale attacks because suddenly there's a network within the network that is spewing the DDoS attacks around the world.
I am not going to go into this in a lot of detail, I think Jerome probably will in much better words. A key point here I mentioned underscoring the residential IP address space, if you look VPNs, they are pretty easy to detect in data centres and there's a pretty low risk from them, they are not ones that are easy to, if necessary, block; the IP infrastructure is harder but not as bad. When you get to the mobile and residential networks, they are really very hard to detect. And the risk is pretty high. As I said, they could be an SDK that was used to build your IoT device, and that makes blocking individual hosts really difficult.
And you know, residential traffic is pretty hard to source and identify the realistic from the unrealistic at the best of times.
AI is featured here, AI is featured everywhere, isn't it?
Whereas before there was a large use of AI for exploiting these things, the use cases were considerably more innocuous than they are now, well to the extent that anything is innocuous in this space.
But now you see that these things are used for a lot of different activities, such as front‑ends for web scraping activity, for model training data, for anti bot invasion, and this leads to sustained traffic at considerable volumes, this literally you will get the attention of ISPs that have these residential proxies being active in their networks.
So this is ‑‑ this leads into the whole ecosystem, leads into the whole supply chain and economic question which is driving the use of these.
So where normal mitigation strategy might focus on detecting and blocking and throttling, targeting the control plane, there are limitations of each of these aspects, whether at the level of detecting and, blocking. For instance, identifying what device in a user's home is actually the source of the problem is beyond the scope of your average ISP. It's probably beyond the scope of any ISP we would like to be a customer of.
Because how do you know if it's a Smart TV or a refrigerator as opposed to something that you condoned in the network.
So blocking IP addresses to address this problem doesn't scale and it doesn't ‑‑ it's not fast enough and it is what has led to the blocking of /24s and taking out large swathes of network, this tends also to get the attention of ISPs. So the traditional approaches to trying to address this have some limitation as well as some opportunities. Targeting the supply chain, as always, going for the money, is probably the most promising, and going up the food chain instead of trying to take it out on individual and infected end hosts.
I probably don't need to say any of this, it's pretty obvious why simply blocking exit nodes doesn't work, from finding them to the collateral damage to legal constraints with net neutrality, etc.
So the preferred approach is to look at control plane disruption, and looking at the ‑‑ yeah, looking at those six to eight backbone ‑‑ the back connect operators versus all of the 200 million deployed residential proxies.
Yeah. So I am going to skim over a lot of this because I am running out of time and I I am told the session is really, really packed. But I wanted to share that perhaps next steps including gauging ISPs because as I said, now that this is actually costing significant bandwidth, maybe there is a financial case to look at the problem collaboratively, and in terms of what the workshop reported out, there are six ideas that might work from piloting an intelligence feed if we collaborate where these things are‑ and I mean the six to eight operators. Maybe we can do something more constructive together and again going for the economic perspective, as well as awareness campaigns within ISPs, as well as individual end users, so there are potentially concrete actions that can be taken and from the perspective of a workshop, we will produce a report that says all of this in more coherent fashion and can be turned in just over 24 hours, we think there's an important need for continued conversation and engagement, potentially a pilot again with collaboration with interested parties. So if you are an interested party, we'd love to talk.
And establish broader co‑ordination and alignment to address the problem.
So it's not the end. It is probably not even the end of the beginning but this was a brief read out from yesterday's work session, we'd like to continue the conversation, we are all here this week, please do reach out and let us know how you'd like to engage.
Thank you.
BRIAN NISBET: Thank you very much. (APPLAUSE.)
We have time, perhaps, for a question or comment indeed.
SPEAKER: I am the co‑chair of the net sec working group in the first group, it's incident responders. And we have been working with this and a lot of folks have joined, for like the last six to eight months. And so it will probably be useful to collaborate with first and a lot of ISPs globally are part of that initiative and discussion.
LESLIE DAIGLE: Yes, thanks.
SPEAKER: Stephen... you said major AI companies are the largest funders. I don't want you to name them, but what type of major AI companies did you mean? It wasn't clear.
LESLIE DAIGLE: I am not going to name them. And in part it's the whole notion of attempting to circumvent blocks of large scale scraping of content. I mean, if you were around 40 years ago ‑‑ maybe not 40, but 20 to 30 years ago when the indexes were being built of the worldwide web, it's the same concerns over what are you doing with my data and what's happening. So circumvention.
SPEAKER: I also got the problem with residential proxies in addition to unintentional use, intentional use where there are services you can sell your bandwidth and we got some interesting abuse messages in the university setting and we were able to pinpoint some services as one users blabbed about this unintentionally to us, I also make a case where you are more research is...
LESLIE DAIGLE: More research and collaboration, once you identify it what do you do with it.
BRIAN NISBET: Indeed those services break all of the AUPs of the universities and national research, he says authorities, OK, excellent, thank you Lesley.
(APPLAUSE.)
Next up we are mixing it up, instead the exciting copyright in cyber crime.
LEE KENT: We can't sling in a bit of residential proxy as well. Hi everybody, I thought it would be useful to give an update what we have been doing over the last 12 months. And some of the research that we have taken on board.
Just a reminder, me name is Lee Kent, I work for BM media group, we are a broadcaster across the globe, 43 countries, eight languages, and we hold most, if not all, of the premium sports and entertainment content. So why am I here and why am I talking to you.
Just as a reminder, non‑compliant hosting providers cause a significant issue, not just BM, but the audio visual industry and music industry. I should have put like one of those little move around ones on.
So when we identify content, we identify the source and we also identify the passage of traffic around it. And we look for where we can have the greatest impact. And try and identify those that are sitting in that ecosystem and those that we can reach out and talk to. And ask to do something about it.
Which comes in with the notice and take down process. So it's part of that ecosystem. We look at the hosting infrastructure.
And within that, we collect a huge amount of data, as part of that data collection, we collaborate and work closely with other industry partners, one particular organisation that we work with, that are around about 23 members, within that we have regular meetings, we share information and share ideas. That kind of gives us a bit of a global perspective. And I am not just from BM but as an industry which then indicates sort of where are bottleneck is really, and where we get a significant amount of non‑compliance and when we say non‑compliance, this is where we send our take‑down requests and we either don't get anything in response to the email or there is no action on that you were or domain name hosting the content.
I am sure you are aware in doing this and not just us but the hosting industry as well have started to use the acronyms or names of bulletproof or offshore. We have just adopted them along with it. We see those organisations actually advertising those particular words as well and some have gone as much as to put in long paragraphs of why they will not comply with DMC notices which I am sure as many of you know is the US acronym, we have the DSA in Europe. That then drives customers to them who want to host or make available to the public a nefarious content and other disruptive stuff.
So in doing this, what we wanted to do was demonstrate the nexus between copyright infringement and other cyber criminality or other cyber abuse around this. So we have looked in detail at the varying IP addresses, the ASNs that are out there and as I have mentioned in my previous presentations, it is very much a small group that we have been able to narrow this down, who also only use a small number of IP addresses.
And this is the environment and the area that we are looking to collaborate with and work with.
So, what did we discover in doing this little piece of analysis.
So we looked and this is really just a snapshot across a number of ASNs that as an industry we have collated together and kind of got a list of, a very small list, of what we would consider bad actors.
So this one particular ASN looking at IP ranges, as you can see live sports infringement, kind of sits fairly low down on the list; however, they are responsible for a huge amount of other cyber abuse, which we were quite sort of surprised about to a degree. And we wanted to know more but we also wanted to know what was the ‑‑ when you see live sport sitting down there and it's fairly low down on the list, what is the proportion of that in amongst this. So this is not to say that some of the IPs being used by this ASN don't carry legitimate traffic, just found the majority of what this ASN was hosting we felt was levels of abuse.
So digging down a bit deeper. We looked at another ASN and again looking at the IP addresses again also carrying a very small range of IPs and we wanted to look at the distribution of those particular copyright infringing services. And again, it wasn't just a small bunch, it wasn't just one or two domain names, it was a large proportion where they had the TLD and multiple sub domains and that's more down to the fact that they have the ability to correctly swap and move across domain names as and when they either get disrupted through blocking orders, which are happening in three European countries at the moment and can just move around very quickly or quite topically talking back to a residential proxy and that causes additional issues. So why am I talking to you and why am I presenting this and giving you an update.
So ongoing discussions at the moment, at European Commission level, have taken this as a serious issue. And on top of Digital Services Act, they are currently looking at a number of options to be able to mitigate these issues. And these risks. So ongoing discussions with the European discussion who have just called for an evidence gathering exercise, which we will participate in and through that process we will demonstrate the number of ASNs that we have tried to interact with, the number of ASNs we have out reached with and the result of those outreach programmes. As part of that outreach, we have had some really, really good success, some of the most notable and large ASNs we have worked with them and we have very swift and succinct take down processes with them where they have failed or there have been shortcomings on both side, again we worked with them and we have a successful outcome.
And that's what we ultimately want to achieve. That collaboration and where we can't collaborate, where we can't get meaningful information and we can't reach out to the actual owners or those that are responsible for the ASN or the IP range, this is where we need additional support and additional help.
Failing that then the next step is for looking to the European Commission to legislation late and bring in those regulations EU‑wide so yes, this is why I am talking to you today and we are looking for collaboration and help across the ecosystem. And hopefully I am keeping it short to help a little bit.
BRIAN NISBET: I mean absolutely, we are ‑‑ now suddenly we have time. Thank you. Are there any questions, comments queries? It all makes perfect sense to everybody?
LEE KENT: This is great, the last time I got loads. I am either making more sense or people are bored.
BRIAN NISBET: Or no one is going to admit to the streaming they are doing. OK. Thank you very much.
LEE KENT: Thank you very much. Thank you. (APPLAUSE.)
BRIAN NISBET: Now we are definitely returning to residential proxies and so Jerome is going to talk to us about the 30 euro attack box, please.
JEROME MYER: Hi everybody, my name is Jerome Myer, I focus more on DDoS, we will talk about DDoS with a side of residential proxies, to get us started, is maybe a quick show of hands, does anyone remember this domain name from last year? Anyone? So it was notable in that it was the number one domain queried from the Cloudflare public resolver standpoint, it is also it happens to be a doxing domain from one of the DDoS botnet operators as they often tend to dox each other, competitively. And for a time at least for a few days under Cloudflare level they were seeing this domain getting more queries than Google.com which is interesting in it itself. How did we come to that. This botnet, this domain was a situ that was from one of the clusters, which we'll talk about and I mentioned this in the context of the DDoS our our side on the Nokia side, when we look at the DDoS traffic and from attacks what we see from your customers, for the better part of the last few years up until 2024, this is what DDoS looked to us and this is a list of the top source IP addresses with some Meta data we collect to be able to characterise traffic, orange is when we know that this particular IP address has a vulnerable device or service that can be exploited for DDoS bot nets, in red this is when we have actually seen this particular IP address involved in a recent DDoS attack. So it was, it's almost all looked like this for a couple of years and then 2025 happened and this is, it it started to look like that which is purple, residential proxies and at first, for the first few months of 2025, we had no idea really what was happening. We were seeing those new IP addresses that we had never seen before; that we couldn't find any particular IoT device, whether it is a router or camera that's easily compromisable, it was all inoffensive residential proxy addresses that were starting to attack and to launch volume metric DDoS attacks which is not layer seven HTTPS type of attack but the massive flows we see in customer's networks.
So this really changed the way that we looked at things starting least year for the past ten years and that really increased throughout to 24, most of DDos was coming from IoT devices that were compromised and that were ‑‑ that we could actually scan, for example, with senses does by scanning the internet and monitoring what's happening behind each IP dress, we could actually figure out that in this particular IP address, there is a camera, we know this is something that can be exploited, so it was relatively attractable problem to monitor.
And it was more or less a non‑problem, so it was around one million active DDoS bots through the past couple of years. And then this, so in 2025, what we really saw is that with this new proxy sort of proxy pool, we had a whole bunch of new exploitable devices. And just to give you a bit of an idea of the size, as Lesley mentioned, it's an estimated 100 to 200 million, hard to quantify exactly, they use a lot of churn, but there is a bunch more devices that can be exploited, and as we saw at the end of 2025, started to get exploited. And women wolf started to exploited.
A picture is worth a thousand words. This is what it looks to us when we look back at DDoS traffic with each one being one of the major attacks we saw, for the past 20 years, it was pretty rare to hear about terabytes better second type of accounts, at the beginning of 2025 we started to see some are 11 bots and rabber bots and in the middle of the year, early September, we started to see all hell break loose with Kim wolf. I am probably going to skip a bit over the sort of technical details for Kimwolf here but the main thing is it was kind of new about Kimwolf aside from the fact it was compromising new type of devices that it is using ENS is a way to communicate the information which is more take down resistant than traditional DNS that other operators have been using and since then other bot nets have been copying this method, whether it is DNS, using the duck chain or also on the... chain a bit more recently. Kimwolf had somewhere north of three million devices, there has been some law enforcement action since then, it's still somewhat active with a much, much lower footprint and what was really new about Kimwolf and that one also is this is a real simple I have cation of the way that it exploited the devices, I really encourage you to have a look at the original research on this particular exploits, basically botnet operators were operating capacity and exploiting vulnerable implementation of the proxy wear to get route access on the devices and they have their, there are millions of devices that can be exploited and even today if you spend some time on some of those telegram channels where the operators hang out, you can see that they are, it's trivial now to be able to compromise 100,000 devices by just spending a few, minute ten, 15 dollars on those proxy providers.
So this is really what enabled this new size, the new torrent of those botnets, the new capacity also that we saw with botnet sizes we had never seen that large before until last year it was extremely rare to have DDoS botnet that was larger than a few tens of thousands of sources. And then ‑‑ so the conventions, the norms completely challenged with Kimwolf, and then all that followed with this massive hundreds of thousands or in the case of Kimwolf, millions of devices that were a part of the botnet, of course they were never attacking the target all at the same time, it was not necessary, because even if a few hundred of thousands, you have a 30 terabyte per second attack, there was plenty of capacity for the operator no to the burn the entire infrastructure on a single attack.
To illustrate and come back briefly on the proxy problem, so what was also new with the Kimwolf and to some extent with Aisuru, problems last year is that it was, there was definitely a volume metric DDoS complement which is what we see here on the right with those typical UDP flaws that we see a lot, especially attacking either gaming providers or gamers themselves or in some cases also what see attacking entire networks with those floods but on the left this is one of the other capabilities of Kimwolf which basically entered the home through a proxy service, so for example IP idea was one of the providers that was vulnerable to this exploits and once Kimwolf got on to the device through the initial proxy layer, they were installing their own proxy service that were then selling through another front‑end. And their operation was mostly criminal. So it, was for example, what you can see here, just credential stuff happening all the time, just you were launching Kimwolf and you saw this type of attacks, either credential, attempts against Microsoft live or some account on Instagram and a lot of other things, it is also, so there was this dual use model for at least some of the of the botnets we saw emerge from this proxy vulnerability.
So something also that I started to discuss with some of our customers in the ISP space is that really we started to see the impact of the DDoS not just when it was arriving into the targets but also when it was leaving the network and that something that at least I had been talking about with some customers for a while, but at least now we are really seeing the actual impact of... and that started really in Latin America and more specifically in Brazil in particular, where there is a high concentration of those proxy or vulnerable proxy signals and also the ‑‑ that were used in these volume metric DDoS attacks and that were creating at least when we saw those attacks, those were creating service availability issues in the network of those ISPs, which is not ‑‑ I am not aware of this in Europe. There have been similar type of situations because the concentration is different, the networks are different, but it has started to create really an issue of availability on the network because of the impact of the... on DDoS not just the start of the attack with the or the destination but also the transit, even the tier one transit providers are issues, maybe it's on the backbone, it doesn't matter as much as for tier one, on the ingress routers it hurts and this is where the collateral damage can be enormous for completely unrelated targets.
I won't have time to go into the full details of this. Yes.
BRIAN NISBET: You have a little extra time.
JEROME MYER: We started really with Kimwolf, it was the initial botnet that exploited this residential proxy vulnerability, of course after the initial discovery and the research from Sintia, there was of course a lot of discussion within the community, the security of the community of course but also the botnet documented community that suddenly got aware that there was a way to suddenly get access to millions of vulnerable devices and that's what we started to see happen sometime in January, after Kimwolf was exposed, then there was a bunch of new additional botnets following the same path with varying degrees of success of course because some of them have let's say a bit more capability than others but we have observed a bunch of new botnets that emerged from the same vulnerability, some of them existed before and that adapted their deliverly mechanism to leverage the proxy path but some of them that were completely new, of course with some amount of source code we use as is also very common practice within this botnet operator community, that's why we see sometimes entire authentication were used between different botnets, we see some of the methods that are common across different families, there is of course the history with Mirai and all its works that is there, but really we saw a couple of interesting things emerge, and some of that was related to the increased use of AI assisted coding, we saw for example Katana, that initially had a root kit that was included in the pay load to achieve persistence on this device, there was the more interesting one to us from a purely research standpoint which was CECbot, the first one we aware of that is stalk the HDMI CEC protocol to understand if the TV was on or off, it was kind of interesting in itself. And also maybe something I don't mention here specifically but we have a, so there are botnets are that questions specific commands to scan the local network which of course raises the issue beyond just DDoS because this is also a problem with LAT earl movement, some of the botnet, even the vulnerability for the residential proxy exploits are last to gain a foothold in the local network and this is majority in a lot of homes. So maybe most people are not aware at least, may not appreciate the risk of these kind of intruder in the home network. There are a lot of these type of boxes in enterprise and in government and research networks which of course increase ‑‑ I mean, puts a bit of a different risk in this case of lateral access.
So there is more details and I'm happy to talk later about those botnets but there has been a ton of development over the past six months since Kimwolf started really this initial access capability and now there are at least ten, 12 different botnets competing for the same android TV boxes, it's kind of interesting actually to see sometimes they try to kill each other when they detect that there is already another one on the box, they will try to issue those kill commands, and then you have some counter measure commands to stop the killing from them, it's a whole thing.
So really it's really a field day out there and there are just tons more devices that can still be exploited so Lesley mentioned the scale of the issue, I think this is really a huge issue of course from the proxy side and then we see one of the consequences is this DDoS activity, and of course it's ‑‑ so we have been also engaged in addressing the botnet operators themselves, but the root cause of the issue here is the vulnerable proxy services that allow those operators to operate a wide number of vulnerable devices.
So to close, I just mention again that there are ‑‑ those divisions are everywhere, there is not, no network is really spared from this. Of course, there is different concentration, we see a lot in Brazil, a lot in the US. The motivation also to install those devices different depending on the countries. The profitability of the proxy providers also different for example US IP address will be more valuable on the proxy market than other countries. It is something that, I mean, we have been also encouraging and working with our customers to really start looking at the traffic, this is something that makes a difference, of course for the internet itself because you can protect, you can try and contain the attacks that will be affecting others in the internet but also your own network, so this is what's been happening for example in Latin America, we have been starting to block those C2 IP addresses so we can really stop the flow of DDoS on those networks. So really ‑‑ we have some relatively effective ways to do it, there needs to be motivation and the will to do it, I know that Lesley also talked about the regulatory aspect, large blocking IP addresses is not always practical, at least permitted in some jurisdictions but there is some work and some discussions to have and yeah, happy to take any questions.
(APPLAUSE.)
BRIAN NISBET: Thank you very much.
SPEAKER: Hi. We noticed that by getting out of. ..problem, we introduced a very short timeframe full catch of all traffic headers and look for packets which are sent out but are not responding back, so we do not have an active connection, and make a little bit statistics about who has such re‑occurring packets sending out without response and that helps us to track down the route device in the customer networks, I am interested in experience from others how did it take such, which devices in local networks, thanks.
JEROME MYER: On the residential proxy side, so we touched also a bit on that in the discussion yesterday with ‑‑ to prepare the earlier presentation, so the way that at least with what we have observed is for the proxy exit notes, a lot of them are very, very chatty, so they will look up what is my IP address, sometimes several times per minute and they will have long live connection towards back connects network, back connect infrastructure, so the combination of the two usually is a good sign that there is proxy note operating and so that of course the detection is part of it. Then we have talked about the... this is where it gets difficult, even if you know the subscriber has a proxy exit note in their network, then it is also about finding out by device it is which is not always straightforward and in the case of mobile devices which is also a possibility here, it is even harder because figure out which of your apps has a proxy ‑‑ it's not straightforward, so the detection, at least to get a sense of how many other network, it's relatively trackable, to figure out the device application, this is where it gets harder.
SPEAKER: We are an MSB. We are suffering these kind of things from the other side. You are talking about the connectivity and the networking piece, we are suffering these on the server side. We have large customers running ecommerce in Europe. We have seen very large traffic coming from Brazil as you have mentioned. We suffered that last suggest August, this is when we started to see this kind of traffic, it doesn't have any customers in Latin America, so we blocked traffic from Latin America, but after that they started hitting us from Africa, so they made a lateral movement. My question here is: Do you have any idea on how we can detect the pattern before they hit the server? Because we are able to block the traffic once we have at least one ping to our servers because they are crafting their URLs that they are growing in their websites because they are trying to hit at the backbone connectivity, but the server and the database and the resources of the server, we are able to block once we have the first ping but before that we are not able so if they produce, say ‑‑ I remember the last time it was around 30 K different IPs in less than five minutes. So you can add more services but it's impossible to deal with that in an effective way. So I am open to ideas.
JEROME MYER: Yes, maybe just as a Professor, I mentioned Brazil, of course, not to single the country out, really because it is one of the top sources of traffic, and of course it is really everywhere. So I think to your point, once you have a hundred or two hundred million exit nodes, most of them I mean quarter of them maybe are in Brazil but you have plenty to choose from this other places, it's super trivial to select, not to rotate over tens of thousands ever IP addresses, so to your point, it's a bit less in my field but I know there have been efforts to characterise some of the traffic that is proxied through nodes and especially with some J4 measurement to differentiate the TCP latency layer and the application agency, there may be a way to at least have something from J4 and to do some detection there.
BRIAN NISBET: OK. Thank you very much.
(APPLAUSE.)
I am sure if people people need to talk to you, you are around.
And so we come to the last, almost last piece of our agenda. So yes, all these things are out on the internet. Potentially the data feeds and everything else like that. It's trusting verify, so please go ahead, Szu‑Chun Huang
SZU‑CHUN HUANG: Hi everybody, I am Szu, from TUDelft, it's my pleasure today to present our work, trust but verify. An assessment of vulnerability tagging services.
So our study focuses on three commercial scanning services, including Shodan, Onyphe and LeakIX, these three services mainly provide the vulnerability landscape on the internet, they periodically scan the internet and report what kind of CVEs or vulnerability might exist out there and in our study we use independent tool called Nuclei, it's a community developed Github repository, there are a lot of templates we can use to scan the internet point to detect. To the main goal of this study is we want to understand how accurate and incomplete are these scanning services.
First I want to introduce you there to methods to detect the vulnerability on the internet.
The first method is through banner based detection through interaction with the server and we can retrieve banner information, that kind of services or version of services that are run on that end point.
And based on this information we can trace back what kind of vulnerability might exist on the server.
And the second method is through payload based detection, which is more reliable because this payload based detection is specifically designed per CVEs. Through payload interaction with server and they can decide if a certain vulnerability existed on the remote host. This is our methodology, we have two phases, the first phase is we want to select a set of CVE list we want to focus on. We focus on Shodan, Shodan they have two types of CVEs, one part of CVEs that we support with payload based check and one part of CVEs they support with banner based checks. When we intersect these CVEs supported by Shodan with Nuclei template, so we can know what are the CVEs that we can actually detect. And we ran a validation on this available Nuclei template and we end up with 37 CVEs that we can validate. For the second phase, we run the vulnerability scan. First, we collect a list of vulnerable IP port end points from Shodan data set and we periodically scan these vulnerable end points with Nuclei template.
And in the last phase, we compare all of the scanning report from Shodan only and LeakIX with your Nuclei data set. So we can compare the vulnerability might be reported differently or it's overlapped.
First we compare the Nuclei detection result with Shodan banner based detected CVEs, and surprisingly, there are a lot of false positives, for 18 out of 21 CVEs, Nuclei contracted the detection result.
For the payload based CVEs they are more overlap between Shodan and Nuclei, but interestingly we found there are a lot of underreporting CVEs.
Nuclei scans fine 30,000 more detection than Shodan.
Next we compare the scanning result with Onyphe and the same pattern emerged. We compare Onyphe with Nuclei and Onyphe with Shodan, and it turns out both figures shows that there are more disagreement than agreement.
And there we compare them with LeakIX is the same pattern, there are disagreements between all these scanning services.
Even they are happening at the same time for the same set of end point. Further, we ran a ground truth valuation. To run a ground truth valuation, we set up vulnerable tacker containers, they have vulnerable version and non‑vulnerable version and each tacker container, they have a unique IP port end point exposed to the internet, we exposed this tacker container for one week to collect all of the scanning data from Shodan only and LeakIX. This is the result of our valuation, we can see from the table, Nuclei achieved the highest accuracy detect, 39 out of 43 Docker instances, for Shodan it has less correct detection, it has two false positive detections that they incorrectly detect patched or mitigated version to vulnerable.
And interestingly there are four false negative cases, we further investigated the vulnerability report, why are these false negatives being formed and it turned out Shodan sometimes detected a correct port but not detect a correct services running on that port or sometimes they detect a correct version but that CVE tags with the vulnerability report was wrong.
We further analysed the traffic that we collect through this Docker containers and it turns out that for Shodan and Onyphe, they tend to perform large scale of the scan across internet. And all these scans are more non‑CVE specific scanning.
And in contrast, Nuclei performed IPv4 extensive CVE specific detection, that's why we got the result that Shodan and Onyphe this kind of commercial services they might have more false positive and false negatives.
This is the end of my presentation, our study, we performed independent valuation against three commercial scanning services against, Shodan Onyphe, and LeakIX. The main finding of the study is we want to raise the concerns about reliability of this vulnerable report. If you are interested in our work, feel free to scan this QR code and check out our paper. Thank you.
(APPLAUSE.)
BRIAN NISBET: Thank you very much. Do we have any questions? Comments or otherwise? No, in which case, thank you.
So that is largely that, unless, as mentioned, anybody has any other business they wish to raise or talk about? And again, seems all good.
I was sure I had changed that to 93. Anyway. No one noticed until I said it.
Yes, agenda for RIPE 93. Again, as always, if anyone has anything they wish to talk about, burning issues. And again we have a mailing list which is very quiet and I am sure there's a million security mailing list in the world, there must be some things we want to discuss on that as well, I remind you it is all there.
So yes, thank you very much to all of our speakers and contributors. Thank you to my co‑chairs. And thank you to all of you for spending your time with us today.
As a reminder, social event this evening. No buses unless you have accessibility or ability issues, but it's a lovely walk through Edinburgh. I have no idea if it it is raining or not, I have no idea. It will stop again soon. There is a BoF in the session ‑‑ rather on diversity equity and inclusion in the main room starting at 6. But hopefully see lots of you at the social and in Sofia in the autumn.
Thank you all very much.
(APPLAUSE.)
End of session.