I have configured a Signature Profile. When configuring it, if I have two attribute types like you do, the operator should be AND, correct? So, the request must match both attribute types before it is blocked, right?

And would you recommend how I should configure the Signature Profile, as well as the other DDoS profiles, according to the recommended best practices?

Thanks all

Mr Hung

Germany ranked ahead of Israel, France, Romania, and the US.

I’m curious to hear what you think: Why is Germany being targeted so heavily? Are you seeing the same trend in other threat reports or data you follow?

If you have seen other research that supports or challenges this trend, please share it in the comments.

Read the full July report here: link

A mobile gaming company we work with — 250M+ registered players, the kind of loyalty most products would kill for (40% of players still active after five years) — had their login page hit by a UDP flood. Peak: 53 Gbps, 5.6 million packets per second. Baseline traffic on that endpoint is roughly 500 Mbps. So for a few minutes, this login page was absorbing over 100x its normal load.

Here's the part that actually made me pay attention: the attacker didn't just throw volume at them. Every packet had a randomized source port, a randomized size, and randomized header fields — deliberately, to avoid ever repeating a pattern a signature could lock onto. The traffic came from 1,000+ source IPs across a globally distributed botnet, including a cluster we've been tracking out of Brazil that's been active on other targets too.

That's not brute force. That's someone who understands exactly what static, signature-based defenses look for, and engineered traffic specifically to never give them one.

It worked, in the sense that the traffic genuinely looked random — no two packets alike. It didn't work in practice. Two things happened almost simultaneously: the sources we already had flagged — via our Active Attackers Feed — were blocked on sight, no analysis needed. Everything else went through our Behavioral DDoS Protection (BDoS), which isn't looking for a known pattern at all. It's comparing what it sees right now to what this specific endpoint's traffic normally looks like. And 5.6M pps of engineered noise doesn't resemble 500 Mbps of real player logins, no matter how "random" each individual packet is.

Signature generation on our side typically kicks in within seconds — though full convergence, where the system fine-tunes to minimize false positives without letting attack traffic through, takes a few seconds more. In this case, there were no reports of player impact, which tells its own story: whatever happened, it happened fast enough that nobody noticed.

But here's what I keep coming back to: login pages are the one page almost every user touches, every session, on every platform. If you're running anything with a login flow — gaming, fintech, e-commerce, doesn't matter — ask yourself honestly:

If someone sent your login endpoint traffic specifically engineered to never repeat a pattern, would your defenses even notice? Or would you only find out from your users?

That's the question this attack actually answers. Worth checking.

On August 4, 2026, npm was hit by a new wave of an attack called Shai-Hulud. Within hours it spread to hundreds of packages with billions of monthly installs. Here's what happened, in order, with a source for each step.

Why the name Shai-Hulud 🙂

Shai-Hulud is what the Fremen call the giant sandworms of Arrakis in "Dune": ancient creatures that move silently beneath the surface until the ground opens up and swallows you whole. Fitting name - the attackers picked it themselves, for their own data-leak repo

How it happened

• An attacker took over the GitHub account of the maintainer behind the popular package keyv (about 127 million downloads a week).

• Through that account, the attacker published a new version with hidden malicious code. Because the release went through the maintainer's own normal build process, the infected version looked fully signed and trustworthy - tools that rely on signatures would not have caught it.

• The moment a developer or a CI/CD system installed the package, malicious code ran automatically in the background - before the install even finished.

• The code scanned the environment and stole tokens and secrets: access to npm, GitHub, AWS, and other cloud services.

• For every npm token it found, the worm checked which additional packages it had publish access to, and spread itself to them automatically. That's how, within a few hours, the infection jumped from a single maintainer to hundreds of other packages.

• Affected packages include keyv, cacheable, flat-cache, file-entry-cache, and others - together over 2 billion monthly installs, including as an internal dependency of common tools like ESLint.

• Organizations whose code was affected include Deliveroo, OneReach, ServiceTitan, Picsart, and Qlik.

• As of this writing, this is still a live event - the numbers keep climbing as the infection continues to spread.

Where Radware fits in

Modern web applications rely on dozens of embedded third-party services many of which are built on open-source ecosystems that can be quietly compromised by supply chain attacks like Shai-Hulud.

Organizations must use dependency firewalls and secure pipelines to stop the actual malware from infecting their own source code.

They must also defend against the toxic byproduct of this campaign: a wake of compromised external vendor scripts running breached in the wild and  this is where a WAF with client-side protection becomes essential, acting as a zero-trust browser barrier that neutralizes malicious payloads like Magecart, formjacking, and DOM XSS at the glass, ensuring your end users remain insulated even when an upstream open-source dependency has been actively weaponized.

Stay safe and protected

Sharon

The new QKS AI Maturity Matrix examines how vendors embed AI across Application Protection, API Security, bot and agent management, DDoS protection, LLM and agentic AI protection, and security operations. QKS positioned Radware as the Most Valuable Pioneer, noting:

“No other vendor in this evaluation has advanced as comprehensively into both the Web & API Economy and the emerging Agentic Economy.”

For me, one of the report’s most important points is that AI maturity cannot be based on an isolated detection feature. It requires AI to work across the full security lifecycle, from understanding behavior and identifying risk to enforcing protections, investigating incidents, and supporting response.

As your organization adopts more APIs, LLM applications, or autonomous agents, where do you see the biggest security challenge: visibility, controlling access and behavior, protecting agent-to-API interactions, or responding to incidents quickly?

I’d be interested to hear what you are seeing in your own environments.

Read the full QKS AI Maturity Matrix Here.

That minute is the whole problem.

A new global survey from Osterman Research, commissioned by Radware, put a number on something security teams have felt for years: the average time to fully resolve an application security incident is 2.8 hours. Only 1.1% of organizations resolve an incident in under 15 minutes. Meanwhile, the average breakout time of an attacker is often shorter than that resolution window.

Read that again. The people defending are, on average, structurally slower than the people attacking. This is not a story about bad security teams. It is a story about a fight where the clock was never set fairly.

Why the clock is broken

For years, "good enough" security meant having the right tools and trusting people to make the right call when something looked wrong. That worked when attacks were slower than defenses. It stops working the moment the attacker's side has automation that can find a vulnerability, chain it into an exploit, and execute, all without a human pausing to think.

The survey backs this up: 63.4% of security leaders are highly or extremely concerned about AI-driven cyberattacks, but only 21.2% say they have the highest level of readiness to manage them. Everyone sees the wave coming. Most people know they are not ready for it.

And the reason is not a lack of effort. It is simple math. A human reading an alert, checking context across several tools, and deciding if it is real, cannot move at the speed the other side now moves at. Not because they are bad at their job. Because the job was never designed to run at that speed.

What actually closes the gap

Here the conversation usually jumps straight to "buy more AI tools," and that is too easy an answer. Organizations are already doing that: 58.1% now use AI-based security tools, up from 7.6% a year earlier. But adoption is not readiness. Across twelve measures of security maturity, only 21% of organizations on average report the highest level for any single control.

In other words, the tools are showing up faster than the trust in them.

The real shift is not another dashboard. It is deciding, deliberately, which decisions still need a human, and which ones cost you the fight if you insist on making them yourself. Spotting a real attack, correlating signals across a WAF, an API layer, and bot management, blocking a source in real time: these are exactly the decisions taking hours, and exactly the ones attackers no longer wait for. Automation is not there to replace judgment. It is there to buy back the minutes that judgment needs.

The uncomfortable question

If your resolution time is measured in hours, and the thing attacking you does not need hours, you are not really defending in real time. You are defending after the fact, and calling it real time out of habit.

The organizations in a different position a year from now will not be the ones with the most tools. They will be the ones honest enough to ask which minutes cost them the most, and build automation around exactly those, not around the ones that are easy to sell in a slide deck.

The full report breaks this down across twelve areas of AI, API, and application security posture, with the industry-by-industry numbers, charts, and comparisons that didn't make it into this post, the kind of data worth having on hand the next time you need to make the case for AI security investment.

Configuring security settings application by application might work when you have just a few. But as your environment grows, setting them up manually one by one becomes a major time-sink—and increases the risk of inconsistencies across your setup.

A Security Policy fixes this by acting as a single, comprehensive template. You define your protection parameters once and apply them across multiple applications instantly. It doesn't just save you hours of manual effort; it makes your entire security posture completely uniform and standardized.

We set up a quick, free training to show you how to build and apply these policies step-by-step:

Link to Free Training: https://deeplinks.mindtickle.com/LM2PKTg9c3b

A globally distributed botnet of more than 4,000 source IPs generated peaks of 670,000 HTTPS requests per second, nearly 100 times the carrier's normal traffic. Throughout the attack, the attackers continuously changed their techniques, making it much harder to distinguish malicious traffic from legitimate users.

Incidents like this are a good reminder that defending against modern HTTPS floods is not just about blocking high traffic volumes. The real challenge is recognizing malicious requests that closely resemble legitimate user activity while the attack continues to evolve.

A simple tabletop exercise for your team:

Imagine your main customer-facing application suddenly receives 100 times its normal HTTPS traffic.

• How would your team determine whether this is a DDoS attack, a successful marketing campaign, or an unexpected traffic spike?

• Who makes that decision?

• If the attack changes techniques while it is already in progress, does your mitigation adapt automatically, or does someone need to manually update the protection?

The answers often reveal operational gaps long before a real attack does.

In this incident, Radware's Web DDoS Protection automatically adapted as the attack evolved, allowing legitimate users to continue accessing services without interruption.

Best,

Haim