Scary stories come in all forms. For system administrators, late night outages and network attacks can cause nightmares.

It's been a year since my last big distributed denial-of-service (DDoS) attack. I had been holding off about blogging about this for a few reasons. First, I wanted to make sure it was over. Second, I didn't want to tip off the attackers about what I learned about them. (I had been quietly telling other people about the attack details. It's even helped some other victims of the same attack.) And finally, I wanted to see if they would come back and trigger any of my traps. (Nope!)

The First Wave

On Wednesday, 23-Oct-2024 at 3pm local time (21:00 GMT), my servers came under a massive distributed denial of service attack.

My servers are physically located in a machine room, about 20 feet away from my office. When my servers come under any kind of load, their fans rev up. Even though they are a room away, I can hear the fans pick up. (It sounds like a jet engine.) When the attack started, I heard two servers ramp up.

My first thought was that one of my customers was probably analyzing videos. That always causes a higher load, but it usually lasts a minute. When the sound continued, I checked the servers themselves. None of the virtual machines had any high-load processes running. In fact, the loads were all hovering around 0.1 (virtually no use). It took me a few moments to find the cause: my server was rejecting a huge number of packets. It was definitely a DDoS attack.

I don't know the exact volume of the attack. My servers were logging a sustained 300Mbps and over 150,000 packets per second. (The logging and packet rejections were enough to cause the fans to ramp up.) However, I'm sure the volume was more than that -- because the upstream router was failing. I later learned that it was even larger: the upstream router to the upstream router was failing. The 300Mbps was just the fraction that was getting through to me. The attacker wasn't just knocking my service offline; they took down a good portion of Northern Colorado. (I grabbed some sample packet captures for later analysis.)

I first confirmed that my servers had not been compromised. (Whew!) Then I called my ISP. They had already noticed since the attack was taking down a few hundred businesses that used the same router.

My ISP did the right thing: they issued a black-hole for my impacted IP address. This droped the traffic long before it reached my server or even the impacted routers.

The First Mitigation

Since the attackers were only going after one IP address, my ISP and I thought I could get away with changing my DNS and moving my impacted services to a different address. On that single IP address, I had a handful of services.

• I first moved FotoForensics. No problem. Usually DNS records are cached for a few hours. Long before any of this happened, I had configured my DNS to only cache for 5 minutes (the minimum time). Five minutes after changing my DNS record, the service came back up and users were able to access it.


• I then moved some of my minor services. Again, after 5 minutes, they were back up and running.


• I could have moved all of my services at once, but I wanted to know which one was being attacked. The last service I moved was this blog. After 5 minutes, the DDoS returned, hitting the new address.

This told me a couple of things:

1. The attack started at precisely 3:00pm and it lasted exactly 12 hours. This appeared to be a schedule attack.


2. They were explicitly targeting my blog and Hacker Factor web service. (Why? What did I do this time? Or maybe, what did I write recently?)


3. They were repeatedly checking DNS to see if I moved. They knew this was a logical step and they were watching for it. That's a level of sophistication that your typical script kiddie doesn't think about. Moreover, it appeared to be an automated check. (Automated? I might be able to use that for a counter attack.)

Looking over the network logs, I saw the packets that were doing the attack:

• It was a flood over UDP. With UDP, you can just shoot out packets (including with fake sender IP addresses) and overwhelm the recipient. This attack varied from targeting port 123/udp (network time protocol) and 699/udp (an unknown port). Neither of these existed on my server. It wasn't about taking down my servers; it was about taking down the routers that lead to my servers.


• Every UDP packet has a time-to-live (TTL) value that gets decremented with each router hop. The TTL values from the attack packets didn't match the sender's address in the UDP packets. That tells me that the sender IP addresses were forged. I run a bunch of honeypots that benchmark attacks year round. The packet TTLs and timings were consistent with traffic coming from Europe and Asia. I then tracked the attack to AS4134 (China).


• They were only attacking over IPv4, not IPv6. That's typical for most bulletproof hosting providers. (These are the types of companies with high bandwidth and no concerns about their customers causing massive network attacks.)


• When the network address was blocked (black hole), the DDoS stopped shortly afterwards. When my DNS changed, the attack restarted. This tells me that they were monitoring my address in order to see when it went down.


• After I changed IP address, I noticed something. Buried in the logs was a single IP address at a university (not in China). It was continually polling to see if my server was up. Blocking that one IP address caused the DDoS against the new IP address to turn off. The attackers appeared to be using this as a way to decide when to disable the attack. (Finding this needle in the 150,000 packets-per-second haystack was the hard part.)

All of this tells me the how, but not the who or why.

Who and Why?

I turned the IP addresses, packet captures, and logs over to some of my, uh, friends. I do not know the details of their methods, but they are very effective.

• They tracked the bulk of the DDoS attack to servers often associated with attacks from North Korea.


• They found that the university system was in a specific university lab. The lab members mostly had Korean names. We suspect that either (A) at least one of the students was North Korean posing a South Korean, or (B) one of the students had downloaded or clicked something that allowed North Korea to compromise the system.

Then I looked back at my blog. Eight days before the attack, I had blogged about C2PA and used AI-generated pictures of North Korea's leader, Kim Jong Un, as my example. Here's the opening of the blog:

There's nothing worse than a depressed, drunk man who has his finger on the nuclear button.

It appears that this was enough to upset the North Korean government and make me a target for a massive network attack.

Hiding For Safety

Since I'm not taking down my blog, I decided to take additional steps in case the DDoS started up again.

There are some online services that provide DDoS protection. I looked into them and decided to switch to CloudFlare. What they provide:

• Domain fronting. When you connect to hackerfactor.com or fotoforensics.com, you actually connect to one of CloudFlare's servers. They forward the request back to my services. If there is a network attack, then it will hit CloudFlare and not me.


• DDoS protection. I kind of felt bad for setting up CloudFlare for an attack. However, this is one of the things they explicitly offer: DDoS protection, even at the free account level.


• Content caching. By default, they will cache web content. This way, if a hundred people all ask for my blog, I only have to provide it once to CloudFlare. This cuts down on the network volume.


• Filtering rules. Even at the free tier, you can create filtering rules to stop bots, AI-scrapers, block bullet-proof hosting providers, etc. (I'm using their paid tier for some of my domains because I wanted more filter options.)

Setting up an account and moving my main domains took hours -- not days or months.

The downside of using CloudFlare is that I like to monitor my network attacks. Since CloudFlare gets these attacks instead of me, I don't have that insight. However, I still run some honeypots outside of CloudFlare so I still have baseline attack metrics.

The Second Wave

Even though my servers had been hit by a massive attack, I decided to slowly move them to the new service. (I'd rather be slow and cautious and get everything right, than to rush it and make a different problem.)

On 28-Oct-2024 (five days after the first attack) at almost exactly 1:00 AM, the attack started again. Although I had moved my servers behind CloudFlare, they appeared to be directly attacking my previously-known location.

Unfortunately, they guessed correctly. Even though CloudFlare was protecting me from incoming attacks, CloudFlare was forwarding valid requests back to my servers. And my servers were still at the old IP addresses. By attacking the old addresses, the DDoS managed to take down my service again.

I called my ISP's emergency 24/7 support number to report the problem, but nobody answered so I left a message. I repeatedly called back every 30-60 minutes until I was able to reach a person -- at 7:20am. (I spoke to the head of my ISP's IT department. They will make sure the 24/7 support will actually be manned next time.) They issued another IP address black hole to stop the attack, and it stopped 20 minutes later.

At this point, I decided to switch around network addresses and bridge in a second ISP. If one ISP goes down, the other one should kick in.

The Third Wave

On 30-Oct-2024, the third wave happened. This one was kind of funny. While my servers were dual homed and on different IP addresses, I still had some equipment using the old addresses. I was working late at night and heard the server fans start up again...

It took me a moment to check all of my diagnostics and determine that, yes, it was the DDoS again. It only took a minute for me to look up the ISP's 24/7 support number. However, as I picked up the phone, I heard the fans rev down. (Odd.) A few seconds later, a different server began revving up. After a minute, it spun down and a third server revved up.

That's when I realized what the attacker was doing. I had a sequential block of IP addresses. They were DDoS'ing one address and checking if my server went offline. After a minute, they moved the DDoS to the next IP address, then the next one. Here's the problems they were facing:

• I had moved my main services to different addresses. This meant that the attacker couldn't find me.


• My services were behind CloudFlare and they cache content. Even if the attacker did find me, their polling to see if I was down would see cached content and think I was still up.

Later that day, CloudFlare posted about a massive DDoS that they had prevented.

Cloudflare
@cloudflare@noc.social

We recently thwarted a massive UDP Flood attack from 8-9K IPs targeting ~50 IP addresses of a Magic Transit customer. This was part of a larger campaign we covered in our Q3 2024 report. Check out the full details here: https://blog.cloudflare.com/ddos-threa...

5.6 terabits per second. Wow. When I wrote to CloudFlare asking if this was related to me, I received no reply. I'm certainly not saying that "this was due to me", but I kind of suspect that this might have been due to me. (Huge thanks to CloudFlare for offering free DDoS protection!)

Keep in mind, CloudFlare says that they can handle 296 terabits per second, so 5.4Tbps isn't going to negatively impact them. But I can totally understand why my (now former) ISP couldn't handle the volume.

Tricks, Treats, and Terabits

I did lay out a couple of detectors and devised a few ways to automatically redirect this attack toward other targets. However, it hasn't resurfaced in a year. (I really wanted to redirect North Korea's high-volume DDoS attack against Russian targets. Now that I've had time to prepare a proper response, I'm sure I can do the redirection with no impact to my local network. I mean, they watch my DNS, so I'd just need to change my DNS to point to Russia. I wonder if this redirected attack would cause an international incident?)

Halloween stories usually end when the monster is vanquished. The lights come back on, the hero breathes a sigh of relief. But for system administrators, the monsters don't die; they adapt. They change IPs, morph signatures, and wait for a moment of weakness.

Some people fear ghosts or ghouls. I fear the faint whine of server fans spinning up in the middle of the night. A sound that means something, somewhere, has found me again. The next time the servers ramps up, it might not be an innocent workload. It might be the North Korea bot army.

What do you do when you find a flaw in a piece of computer software or hardware? Depending on the bug, a legitimate researcher might:

• Report it to the vendor. This is the most desirable solution. It should be easy to find a contact point and report the problem.


• Publicly tell others. Full disclosure and public disclosure, especially with a history showing that you already tried to contact the vendor, helps everyone. Even if there is no patch currently available, it still helps other people know about the problem and work on mitigation options. (Even if you can't patch the system, you may be able to restrict how the vulnerable part is accessed.)


• Privately tell contacts. This keeps a new vulnerability from being exploited publicly. Often, a vendor may not have a direct method of reporting, but you might know a friend of a friend who can report it to the vendor through other means.


• Privately sell it. Keeping vulnerabilities quiet also permits making money by selling bugs privately to other interested parties. Of course, you don't know how the others are going to use the new exploit... But that's why you should try to report it to the vendor first. If the vendor isn't interested, then all bets are off. (You can get a premium if you can demonstrate a working exploit and show that the vendor is not interested in fixing it.)


• Keep it to yourself. While there is a risk of someone else finding the same problem, sometimes it's better to keep the bug handy in case you need it in the future. (This is especially true if compromising systems is part of your job description, such as professional penetration testers or hired guns.)


• Do nothing. This option is unfortunately common when the reporting method is unidentified or overly complicated. (I'm trying to report a bug, not build a desk from Ikea. I don't want pages of instructions and an Allen wrench.)

Reporting to the vendor, or at least trying to report to the vendor before resorting to some other option, falls under the well-known best practices of responsible disclosure and full disclosure.

Incentives

Some vendors offer incentives in order to receive bugs. These bug bounty programs often include financial rewards in exchange for informing the vendor and working with them to resolve the issue.

In the old days, bug bounties worked pretty well. (I've even made some money that way.) However, over the years, some companies have perverted the incentives. Rather than paying for the information so they can fix it, they pay for the information and require an agreement to legal terms. For example, some companies have attached stipulations to the payments, such as "by agreeing to this transaction, you will not make it public without coordinating the disclosure with us." (And every time you ask, they will say that they have prioritized it or are still working on it, even years later.) More than a few vendors use bug bounties as a way to bury the vulnerability by paying for silence.

I have personally had too many bad experiences with bug bounties and vendors paying for the privilege of being non-responsive. I don't think bounty programs are worth the effort anymore. Additionally, I won't do bug bounty programs if they require enrolling into any service or are associated with some kind of legal agreement. (If they want me to agree to legal terms, then they need to pay for my attorney to review the terms before I sign it.)

In contrast to bounties, some companies send very nice "thank you" response to people who took the effort to report a bug. Often, these are swag and not financial. I've received t-shirts, hats, mugs, stickers, and very nice thank-you letters. Unlike bounties, I've found that each time a vendor sends me an unsolicited "thank you" (even if it's just a nice personalized email), they are responsive and actively fix the bug.

While some people report bugs for the money or swag, I have a different incentive. If I found a bug and it impacts me or my clients, then I want it fixed. The best place to fix it is with the vendor, so I try to report the problem. This is very much a self-serving purpose: I want their code to work better for my needs. Then again, many vendors are incredibly responsive because they want to provide the best solution to their customers. My bug reports help them and me.

Jump Through Hoops

When it comes to bug reporting, the one thing I don't want to do is jump through hoops. The most common hoops include closed lists, scavenger hunts, strict reporting requirements, and forced legal terms.

• Hoop #1: Closed Lists
  Many open source projects want bugs reported to their mailing list, discord channel, IRC server, private forum, or some other service that requires signing up before reporting. For example, Gentoo Linux wants to you sign up with their Bugzilla service in order to submit a bug, and to keep any discussions in their "forums, IRC or mailing lists". Their various discussion lists also require signing up.
  
  For me, this is the same as a vendor who is unreachable. When I want to report a bug, I don't want to join any lists or forums; I just want to report a bug.


• Hoop #2: Scavenger Hunts
  Some organizations have turned "where to report" into a scavenger hunt. The Tor Project used to be a good example of this. Prior to 2019, they wanted you to search through all of their lists and try to find the correct contact point. If you contacted the wrong person, or gave up because you couldn't find the right person, then that's your fault.
  
  However, after years of complaining, the Tor Project finally simplified the reporting process. Now you can easily find multiple ways to report issues to them. (I still think they usually don't do anything when you report to them, but it's a step in the right direction.)


• Hoop #3: Strict Requirements
  Some companies and organizations have strict requirements for reporting. While I'm fine with providing my name and contact information (in case they have questions or need more details), some forms require you to provide the device's serial number, software version, and other information that the reporter may not have.
  
  For example, many years ago I found a problem with a standalone kiosk. (I'm not naming names here.) The vendor only had one way to report problems: use their online form. Unfortunately, the reporting form absolutely would not let me report the problem without providing a valid serial number and software version for the device. The problem is, it's not my kiosk. I don't know the serial number, software version, or even the alphanumeric location code. Moreover, the exploit appeared to work on all of their kiosks. But due to their strict requirements, I was unable to report the problem. (I ended up finding a friend of a friend who had a contact in the company.)
  
  Some software providers only want reports via their Bugzilla service. Bugzilla often has fields for additional information. (Other bug tracking services have similar features.) Unfortunately, I've had some software groups (again, not naming names) eagerly close out the bug report because I didn't have all of their required information. (It's not that I intentionally didn't supply it; I just didn't have that information.) Beyond an automated message telling me that the bug was closed, they never contacted me. As far as I can tell, they never even looked at the bug because the form wasn't complete enough for them. Keep in mind: my bug reports include detailed step-by-step instructions showing how to do the exploit. (In a few of these cases, I ended up selling the exploits privately to interested parties since the vendors were non-responsive.)


• Hoop #4: Mandatory Terms
  Some companies, like Google, don't have a means to report vulnerabilities without agreeing to their terms. Years ago, Google would accept vulnerability reports with no strings attached. But today, they direct everything to their "Bug Hunters" page. Before reporting a bug, you must agree to their terms.
  
  For me, any kind of non-negotiable mandatory agreement is a showstopper. Even though their terms seem simple enough, I cannot agree to them. For example, they expect "ethical conduct". I expect to act ethically, but since it's their terms, they get to determine what is and is not ethical conduct.

I can understand signing up if you want to be paid a bounty. (Google promises some very large payouts for rare conditions.) But often, I'm not looking for a bounty -- I just want to report a bug.

Interestingly, language barriers have never been a problem in my experience. Most companies auto-translate or accept reports in English. This makes the remaining hoops (legal terms, closed lists, etc.) stand out, because they are entirely self-imposed.

The Bug Bounty Scam

As a service provider, I also receive a lot of inquiries from people posing as potential bug reporters. Here's a sample email:

From: EMX Access Control Sensors <no-reply@[redacted]>
To: [redacted]@[redacted].com
Subject: Paid Bug Bounty Program Inquiry enquiry

Name:
Email: yaseen17money@hotmail.com
Message: Hi Team, I’m Ghulam Yaseen, a security researcher. I wanted to ask if you offer a paid bug bounty program or any rewards for responsibly disclosed vulnerabilities. If so, could you please share the details.

Yaseen writes to me often. Each time, from a different (compromised) domain. (I'm not worried about redacting his email since dozens of forums list this entire email in its entirety.) This isn't a real inquiry/enquiry. A legitimate query would come from their own mail server and use their own name as the sender. I think this is nothing more than testing the mail server to see if it's vulnerable.

In contrast, here's another query I received, and it seems to be from real people (names redacted):

Date: Thu, 21 Aug 2025 05:47:47 +0530
From: [Redacted1] <[redated1]@gmail.com>
Cc: [redacted2]@gmail.com, [Redacted1] <redacted1@gmail.com>
Subject: Inquiry Regarding Responsible Disclosure / Bug Bounty Program

Hello Team,

We are [Redacted1] and [Redacted2], independent security researchers specializing in vulnerability discovery and organizational security assessments.

- [Redacted2] – Microsoft MSRC MVR 2023, with prior vulnerability reports to Microsoft, SAP, BBC, and government entities in India and the UK.
- [Redacted1] – Experienced in bug bounty programs, penetration testing, and large-scale reconnaissance, with findings reported to multiple high-profile organizations.

We came across your organization’s security program information and are interested in contributing by identifying and reporting potential vulnerabilities in a responsible manner.Given our combined expertise in deep reconnaissance, application security, and infrastructure assessments, we believe we could contribute to uncovering critical security issues, including hidden or overlooked vulnerabilities.

Before conducting any form of testing, we would like to confirm the following:

1. Does your organization have an active responsible disclosure or bug bounty program?
2. Could you please define the exact scope of assets that are permitted for testing?
3. Are vulnerabilities discovered on assets outside the listed scopes but still belonging to your organization eligible for rewards?
4. Any rules of engagement, limitations, or legal requirements we should be aware of?
5. Bounty reward structure (if applicable).

We follow strict ethical guidelines and ensure all reports include clear technical detail, reproduction steps, and remediation recommendations.

Looking forward to your guidance and confirmation before initiating any further testing.

Best regards,
[Redacted1] & [Redacted2]

There's no way I'm going to respond to them.

• If I'm going to have someone audit my servers, it will be someone I contact and not who contacts me out of the blue. As covered by Krebs's 3 Basic Rules for Online Safety, "If you didn’t go looking for it, don’t install it!" The same applies to unsolicited offers for help. I didn't go looking for this, so I'm certainly not going to allow them to audit my services.


• Responding positively to any of their questions effectively gives them permission to attack your site.

These are not the only examples. I receive this kind of query at least weekly.

• Some of these inquires mention that my server has a known vulnerability. However, they don't want to tell me what it is until after they confirm that I have a bug bounty program. If I don't respond, or respond by saying that I don't offer any bounties, then they never tell me the bug. Assuming they actually found something, then this feels like extortion. (Pay them or they won't tell me.)


• A few people do point out my vulnerabilities. So far, every single case has either been from one of my honeypots or due to my fake /etc/passwd file. (They asked for a password file, so I gave them one. What's the problem?)

The best thing to do if you receive an unsolicited contact like this? Don't respond. Of course, if they do list a vulnerability, then definitely investigate it. Real vulnerabilities should receive real replies.

Sample Pre-reporting Requirements: Google

In my previous blog entry, I wrote about some significant failures in the Google Pixel 10's C2PA implementation. Before writing about it publicly, I tried multiple ways to report the issue:

1. Direct contact: I repeatedly disclosed my concerns about C2PA to a Google representative. Unfortunately, I believe my concerns were disregarded. Eventually the Google contact directed me to report issues through Google's Bug Hunters system. (That's right: the direct contact didn't want to hear about bugs in his own system unless it came through Google's Bug Bounty service.)


2. Google Bug Hunters: Google's Bug Hunters system requires agreeing to Google's vulnerability reporting terms before I could even submit the bug. I wasn't looking for a bounty; I simply wanted to report a serious problem. For me, being forced to accept legal terms before reporting is a showstopper.


3. Private outreach: After I confirmed the flaws in Pixel 10's C2PA functionality, I reached out to my trusted security contacts. In the past, this network has connected me directly to security teams at Amazon, Facebook, and other major vendors. Since Google's C2PA team was non-responsive, I wanted to contact someone in Google's Android security team or legal department; I suspected that they had not independently reviewed the C2PA implementation for its security, trust, and liability implications. (If they had, I doubt this would have shipped in its current form.) Unfortunately, no one had a contact who could receive a report outside of Google's Bug Hunters. (It's really weird how Google directs everything through Bug Hunters.)

At that point, I had exhausted my options. For me, a reporting process that requires accepting legal terms just to submit a vulnerability -- especially when I am already in direct contact with the team responsible -- is a hoop too many. This is why I posted my blog about Pixel 10's C2PA flaws. (Don't be surprised if I eventually post about more Pixel 10's problems without telling Google first. And if someone inside Google reaches out to me, I'd be happy to discuss this directly, without agreeing to any terms.)

Sample Reporting Hoops: Nikon

Around the same time the Pixel 10 was released, Nikon rolled out C2PA support for the Nikon Z6 III camera. Within days, researcher Horshack discovered that he could get any file signed by the camera, which is a serious flaw in the authenticity system. He even released a signed forgery as a demonstration:



If you upload this picture to Adobe's Content Credentials service, it reports that it is a genuine picture from a "Nikon Z6 3" camera, with no indication that it was altered or forged.

To Nikon's credit, the day after DP Review published an article about this, Nikon temporarily suspended their C2PA signing service, saying they had "identified an issue" and would "work diligently" to resolve it. That's a strong response.



Two weeks after disabling the signing service, Nikon announced that they were revoking their signing certificate. (As of this writing, 2025-09-19, the C2PA and CAI have not revoked Nikon's certificate from their list of trusted certificates. Right now, Every Content Credentials service still says the pictures that are signed using a revoked certificate are still valid and trusted.)

It's unclear if Horshack ever tried to report directly to Nikon. When I searched for a security contact point, Nikon only listed HackerOne as their reporting mechanism. HackerOne is a bug bounty system that requires enrollment, personal information, and banking details. If you aren’t seeking a bounty, then this is a major hoop that discourages reporting.

The community response to Horshack's public disclosure was mostly positive, with many people alarmed and grateful that the issue came to light. However, a few commenters criticized the public release, suggesting it might hurt Nikon's reputation. While lawsuits are always a theoretical risk, I would argue that a vendor that only accepts reports through gated programs effectively pushes researchers toward public disclosure as the only viable reporting path.

In this case, Nikon acted quickly once the problem went public. This demonstrates that they can respond, but the process could have been much smoother if they provided a simple, open reporting channel.

When one problem is reported, it's not unusual to see other people identify related problems. In the comments to the original reporting, other people detailed additional issues. For example:

• patrol_taking_9j noted that "NX Studio is completely unable to export JPEG's at all for any RAW or RAW+JPEG NEF files shot with C2PA enabled."


• Horshack replied to his own posting, noting that pictures appear to be signed hours after capture.


• Pierre Lagarde remarked that "The only thing I can say is C2PA still looks like a problem by itself, not that much like a solution to anything. At least, I think the inclusion of this feature at this stage seems premature." (I fully agree.)


• To further demonstrate the problem, Horshack created a second signed forgery:
  
  
  
  As with his first forgery, the Content Credentials service reports that it is a photo from a "Nikon Z6 3" camera.

These additional problems show the power of public disclosure. Had Horshack not made the initial problem public, other people may have not looked as closely and these related concerns may not have been brought to light.

Lower Barriers, Better Security

Bug reporting should not feel like running an obstacle course. Every extra hurdle, whether it's mandatory legal terms, scavenger hunts, closed lists, or bounty-program enrollment, increases the likelihood that a researcher will give up, go public, or sell the exploit privately.

The Google and Nikon cases highlight the same lesson: if you make responsible reporting difficult, then you drive researchers toward public disclosure. That might still result in a fix, but it also increases the window of exposure for everyone who uses the product.

The vendors who handle vulnerability reporting the best are the ones who make it simple: a plain-text email address, a short web form, or even a contact page that doesn't require more than a description and a way to follow up. Many of these vendors don't pay bounties, yet they respond quickly and even say "thank you", which is often enough to keep security researchers engaged.

The industry doesn't need more hurdles. It needs frictionless reporting, fast acknowledgment, and a clear path from discovery to resolution. Good security starts with being willing to listen: make it as easy as possible for the next person who finds a flaw to tell you about it.

IT threat evolution in Q2 2025. Non-mobile statistics
IT threat evolution in Q2 2025. Mobile statistics

The statistics in this report are based on detection verdicts returned by Kaspersky products unless otherwise stated. The information was provided by Kaspersky users who consented to sharing statistical data.

The quarter in numbers

In Q2 2025:

• Kaspersky solutions blocked more than 471 million attacks originating from various online resources.
• Web Anti-Virus detected 77 million unique links.
• File Anti-Virus blocked nearly 23 million malicious and potentially unwanted objects.
• There were 1,702 new ransomware modifications discovered.
• Just under 86,000 users were targeted by ransomware attacks.
• Of all ransomware victims whose data was published on threat actors’ data leak sites (DLS), 12% were victims of Qilin.
• Almost 280,000 users were targeted by miners.

Ransomware

Quarterly trends and highlights

Law enforcement success

The alleged malicious actor behind the Black Kingdom ransomware attacks was indicted in the U.S. The Yemeni national is accused of infecting about 1,500 computers in the U.S. and other countries through vulnerabilities in Microsoft Exchange. He also stands accused of demanding a ransom of $10,000 in bitcoin, which is the amount victims saw in the ransom note. He is also alleged to be the developer of the Black Kingdom ransomware.

A Ukrainian national was extradited to the U.S. in the Nefilim case. He was arrested in Spain in June 2024 on charges of distributing ransomware and extorting victims. According to the investigation, he had been part of the Nefilim Ransomware-as-a-Service (RaaS) operation since 2021, targeting high-revenue organizations. Nefilim uses the classic double extortion scheme: cybercriminals steal the victim’s data, encrypt it, then threaten to publish it online.

Also arrested was a member of the Ryuk gang, charged with organizing initial access to victims’ networks. The accused was apprehended in Kyiv in April 2025 at the request of the FBI and extradited to the U.S. in June.

A man suspected of being involved in attacks by the DoppelPaymer gang was arrested. In a joint operation by law enforcement in the Netherlands and Moldova, the 45-year-old was arrested in May. He is accused of carrying out attacks against Dutch organizations in 2021. Authorities seized around €84,800 and several devices.

A 39-year-old Iranian national pleaded guilty to participating in RobbinHood ransomware attacks. Among the targets of the attacks, which took place from 2019 to 2024, were U.S. local government agencies, healthcare providers, and non-profit organizations.

Vulnerabilities and attacks

Mass exploitation of a vulnerability in SAP NetWeaver

In May, it was revealed that several ransomware gangs, including BianLian and RansomExx, had been exploiting CVE-2025-31324 in SAP NetWeaver software. Successful exploitation of this vulnerability allows attackers to upload malicious files without authentication, which can lead to a complete system compromise.

Attacks via the SimpleHelp remote administration tool

The DragonForce group compromised an MSP provider, attacking its clients with the help of the SimpleHelp remote administration tool. According to researchers, the attackers exploited a set of vulnerabilities (CVE-2024-57727, CVE-2024-57728, CVE-2024-57726) in the software to launch the DragonForce ransomware on victims’ hosts.

Qilin exploits vulnerabilities in Fortinet

In June, news broke that the Qilin gang (also known as Agenda) was actively exploiting critical vulnerabilities in Fortinet devices to infiltrate corporate networks. The attackers allegedly exploited the vulnerabilities CVE-2024-21762 and CVE-2024-55591 in FortiGate software, which allowed them to bypass authentication and execute malicious code remotely. After gaining access, the cybercriminals encrypted data on systems within the corporate network and demanded a ransom.

Exploitation of a Windows CLFS vulnerability

April saw the detection of attacks that leveraged CVE-2025-29824, a zero-day vulnerability in the Windows Common Log File System (CLFS) driver, a core component of the Windows OS. This vulnerability allows an attacker to elevate privileges on a compromised system. Researchers have linked these incidents to the RansomExx and Play gangs. The attackers targeted companies in North and South America, Europe, and the Middle East.

The most prolific groups

This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS during the reporting period. In the second quarter, Qilin (12.07%) proved to be the most prolific group. RansomHub, the leader of 2024 and the first quarter of 2025, seems to have gone dormant since April. Clop (10.83%) and Akira (8.53%) swapped places compared to the previous reporting period.

Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)

Number of new variants

In the second quarter, Kaspersky solutions detected three new families and 1,702 new ransomware variants. This is significantly fewer than in the previous reporting period. The decrease is linked to the renewed decline in the count of the Trojan-Ransom.Win32.Gen verdicts, following a spike last quarter.

Number of new ransomware modifications, Q2 2024 — Q2 2025 (download)

Number of users attacked by ransomware Trojans

Our solutions protected a total of 85,702 unique users from ransomware during the second quarter.

Number of unique users attacked by ransomware Trojans, Q2 2025 (download)

Geography of attacked users

TOP 10 countries and territories attacked by ransomware Trojans

	Country/territory*	%**
1	Libya	0.66
2	China	0.58
3	Rwanda	0.57
4	South Korea	0.51
5	Tajikistan	0.49
6	Bangladesh	0.45
7	Iraq	0.45
8	Pakistan	0.38
9	Brazil	0.38
10	Tanzania	0.35

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.

TOP 10 most common families of ransomware Trojans

	Name	Verdict	%*
1	(generic verdict)	Trojan-Ransom.Win32.Gen	23.33
2	WannaCry	Trojan-Ransom.Win32.Wanna	7.80
3	(generic verdict)	Trojan-Ransom.Win32.Encoder	6.25
4	(generic verdict)	Trojan-Ransom.Win32.Crypren	6.24
5	(generic verdict)	Trojan-Ransom.Win32.Agent	3.75
6	Cryakl/CryLock	Trojan-Ransom.Win32.Cryakl	3.34
7	PolyRansom/VirLock	Virus.Win32.PolyRansom / Trojan-Ransom.Win32.PolyRansom	3.03
8	(generic verdict)	Trojan-Ransom.Win32.Crypmod	2.81
9	(generic verdict)	Trojan-Ransom.Win32.Phny	2.78
10	(generic verdict)	Trojan-Ransom.MSIL.Agent	2.41

* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.

Miners

Number of new variants

In the second quarter of 2025, Kaspersky solutions detected 2,245 new modifications of miners.

Number of new miner modifications, Q2 2025 (download)

Number of users attacked by miners

During the second quarter, we detected attacks using miner programs on the computers of 279,630 unique Kaspersky users worldwide.

Number of unique users attacked by miners, Q2 2025 (download)

Geography of attacked users

TOP 10 countries and territories attacked by miners

	Country/territory*	%**
1	Senegal	3.49
2	Panama	1.31
3	Kazakhstan	1.11
4	Ethiopia	1.02
5	Belarus	1.01
6	Mali	0.96
7	Tajikistan	0.88
8	Tanzania	0.80
9	Moldova	0.80
10	Dominican Republic	0.80

* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.

Attacks on macOS

Among the threats to macOS, one of the biggest discoveries of the second quarter was the PasivRobber family. This spyware consists of a huge number of modules designed to steal data from QQ, WeChat, and other messaging apps and applications that are popular mainly among Chinese users. Its distinctive feature is that the spyware modules get embedded into the target process when the device goes into sleep mode.

Closer to the middle of the quarter, several reports (1, 2, 3) emerged about attackers stepping up their activity, posing as victims’ trusted contacts on Telegram and convincing them to join a Zoom call. During or before the call, the user was persuaded to run a seemingly Zoom-related utility, but which was actually malware. The infection chain led to the download of a backdoor written in the Nim language and bash scripts that stole data from browsers.

TOP 20 threats to macOS

* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)

* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.

A new piece of spyware named PasivRobber, discovered in the second quarter, immediately became the most widespread threat, attacking more users than the fake cleaners and adware typically seen on macOS. Also among the most common threats were the password- and crypto wallet-stealing Trojan Amos and the general detection Trojan.OSX.Agent.gen, which we described in our previous report.

Geography of threats to macOS

TOP 10 countries and territories by share of attacked users

Country/territory	%* Q1 2025	%* Q2 2025
Mainland China	0.73%	2.50%
France	1.52%	1.08%
Hong Kong	1.21%	0.84%
India	0.84%	0.76%
Mexico	0.85%	0.76%
Brazil	0.66%	0.70%
Germany	0.96%	0.69%
Singapore	0.32%	0.63%
Russian Federation	0.50%	0.41%
South Korea	0.10%	0.32%

* Unique users who encountered threats to macOS as a percentage of all unique Kaspersky users in the country/territory.

IoT threat statistics

This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.

In the second quarter of 2025, there was another increase in both the share of attacks using the Telnet protocol and the share of devices connecting to Kaspersky honeypots via this protocol.

Distribution of attacked services by number of unique IP addresses of attacking devices (download)

Distribution of attackers’ sessions in Kaspersky honeypots (download)

TOP 10 threats delivered to IoT devices

Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)

In the second quarter, the share of the NyaDrop botnet among threats delivered to our honeypots grew significantly to 30.27%. Conversely, the number of Mirai variants on the list of most common malware decreased, as did the share of most of them. Additionally, after a spike in the first quarter, the share of BitCoinMiner miners dropped to 1.57%.

During the reporting period, the list of most common IoT threats expanded with new families. The activity of the Agent.nx backdoor (4.48%), controlled via P2P through the BitTorrent DHT distributed hash table, grew markedly. Another newcomer to the list, Prometei, is a Linux version of a Windows botnet that was first discovered in December 2020.

Attacks on IoT honeypots

Geographically speaking, the percentage of SSH attacks originating from Germany and the U.S. increased sharply.

Country/territory	Q1 2025	Q2 2025
Germany	1.60%	24.58%
United States	5.52%	10.81%
Russian Federation	9.16%	8.45%
Australia	2.75%	8.01%
Seychelles	1.32%	6.54%
Bulgaria	1.25%	3.66%
The Netherlands	0.63%	3.53%
Vietnam	2.27%	3.00%
Romania	1.34%	2.92%
India	19.16%	2.89%

The share of Telnet attacks originating from China and India remained high, with more than half of all attacks on Kaspersky honeypots coming from these two countries combined.

Country/territory	Q1 2025	Q2 2025
China	39.82%	47.02%
India	30.07%	28.08%
Indonesia	2.25%	5.54%
Russian Federation	5.14%	4.85%
Pakistan	3.99%	3.58%
Brazil	12.03%	2.35%
Nigeria	3.01%	1.66%
Germany	0.09%	1.47%
United States	0.68%	0.75%
Argentina	0.01%	0.70%

Attacks via web resources

The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. Cybercriminals create malicious pages with a goal in mind. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.

Countries that served as sources of web-based attacks: TOP 10

This section gives the geographical distribution of sources of online attacks blocked by Kaspersky products: web pages that redirect to exploits; sites that host exploits and other malware; botnet C2 centers, and the like. Any unique host could be the source of one or more web-based attacks.

To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).

In the second quarter of 2025, Kaspersky solutions blocked 471,066,028 attacks from internet resources worldwide. Web Anti-Virus responded to 77,371,384 unique URLs.

Web-based attacks by country, Q2 2025 (download)

Countries and territories where users faced the greatest risk of online infection

To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location who experienced a Web Anti-Virus alert during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.

This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

	Country/territory*	%**
1	Bangladesh	10.85
2	Tajikistan	10.70
3	Belarus	8.96
4	Nepal	8.45
5	Algeria	8.21
6	Moldova	8.16
7	Turkey	8.08
8	Qatar	8.07
9	Albania	8.03
10	Hungary	7.96
11	Tunisia	7.95
12	Portugal	7.93
13	Greece	7.90
14	Serbia	7.84
15	Bulgaria	7.79
16	Sri Lanka	7.72
17	Morocco	7.70
18	Georgia	7.68
19	Peru	7.63
20	North Macedonia	7.58

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by Malware attacks as a percentage of all unique users of Kaspersky products in the country.

On average during the quarter, 6.36% of internet users’ computers worldwide were subjected to at least one Malware web-based attack.

Local threats

Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.

Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media. The statistics are based on detection verdicts from the On-Access Scan (OAS) and On-Demand Scan (ODS) modules of File Anti-Virus. This includes malware found directly on user computers or on connected removable media: flash drives, camera memory cards, phones, and external hard drives.

In the second quarter of 2025, our File Anti-Virus recorded 23,260,596 malicious and potentially unwanted objects.

Countries and territories where users faced the highest risk of local infection

For each country and territory, we calculated the percentage of Kaspersky users whose devices experienced a File Anti-Virus triggering at least once during the reporting period. This statistic reflects the level of personal computer infection in different countries and territories around the world.

Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.

	Country/territory*	%**
1	Turkmenistan	45.26
2	Afghanistan	34.95
3	Tajikistan	34.43
4	Yemen	31.95
5	Cuba	30.85
6	Uzbekistan	28.53
7	Syria	26.63
8	Vietnam	24.75
9	South Sudan	24.56
10	Algeria	24.21
11	Bangladesh	23.79
12	Belarus	23.67
13	Gabon	23.37
14	Niger	23.35
15	Cameroon	23.10
16	Tanzania	22.77
17	China	22.74
18	Iraq	22.47
19	Burundi	22.30
20	Congo	21.84

* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers Malware local threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.

Overall, 12.94% of user computers globally faced at least one Malware local threat during the second quarter.
The figure for Russia was 14.27%.