What We Found Scanning 6 Israeli Insurance Companies Before OpIsrael 2026

Why we ran this

OpIsrael is the annual coordinated cyber operation against Israeli infrastructure. April 7. Every year. It is the closest thing the cybersecurity industry has to a fire drill with a known date, and most enterprise defenders treat it that way: they tighten configurations the week before and relax them the week after.

We wanted to know what the actual posture looked like before the drill, not after. So in the run-up to OpIsrael 2026 we audited six Israeli insurance companies. None of them are named here. Most of them are still customers of CDN and WAF vendors that publicly claim DDoS resilience. The audit covered their customer-facing portals, agent systems, claims APIs, mobile backends, and corporate sites.

The findings were not about how much traffic these companies could absorb. The findings were about how much of their attack surface was reachable in the first place.

How we measured

Each insurer was scanned through DDactic's six-stage reconnaissance pipeline:

We were looking for three things:

1. Subdomain inventory — how many internet-facing assets actually exist under the parent domain, including ones the company itself may have forgotten about.
2. Protection coverage per asset — which subdomains actually sit behind a CDN with WAF rules, versus which expose the origin directly.
3. Reachable attack vectors — for each exposed asset, which classes of L4 and L7 DDoS attacks could land successfully without first having to bypass an upstream protection layer.

The pipeline is mostly passive: certificate transparency logs, DNS, HTTP fingerprinting from a single GET, TLS handshake observation. Three checks include lightweight active probing from a single source IP — a TLS-handshake throttling test (10 rapid handshakes), an HTTP/2 PING-frame rate test, and a 429-response check on the homepage. We do not run any sustained attack traffic, application-level fuzzing, or auth bypass attempts. The same methodology runs at ddactic.net/free-scan on any domain you point at it.

Of the 843 subdomains discovered across all six audits, 422 resolved to live infrastructure at audit time. The rest were defensive registrations, abandoned legacy assets, or DNS-only entries with no live host. The 68% exposure rate below applies to those 422 resolvable assets.

The main finding: discovery is the breach

Of 422 resolvable HTTP-serving assets, 287 (68%) were directly reachable at L7 without any meaningful upstream protection. Some companies hit 92% exposure. These assets resolved to origin IPs that were not behind a CDN with WAF rules, did not have rate limiting visible in headers or behavior, and would accept the kind of malformed or rapid-fire requests that constitute a basic L7 DDoS.

Honest caveat: this is "rate limiting visible at our probe volume from a single IP." An asset whose rate limits are set high enough to absorb a 10-handshake burst would not trip our probes even if it has rate limiting configured. So 8 of 422 is a lower bound on the number of rate-limited assets, and 414 is an upper bound on the number with no protection. But the gap matters less than it sounds: an attacker with a single source IP and modest request volume would face no resistance on those 414. That's a baseline failure regardless of whether deeper limits exist.

This is not a story about WAF vendor selection. It is a story about coverage. Most of these enterprises had a CDN. Most had a WAF policy on their primary domains. The exposure was concentrated in the long tail: staging environments that should have been firewalled, regional subdomains that were spun up for a campaign and never decommissioned, mobile API gateways that were exempted from CDN routing for latency reasons, and partner-facing portals that were treated as low-traffic and therefore low-risk.

The pattern repeats: the customer-facing app sits behind Cloudflare or Imperva. Looks solid. Everything else — corporate sites, internal portals, API endpoints — sits on direct IPs with a security WAF (Checkpoint, FortiGate, similar) in front. A security WAF does application-layer policy enforcement. It was never designed for volumetric DDoS. Under load, connection tables fill up and the WAF becomes the failure point, not the defense.

The protection gaps were not where defenders were looking. They were everywhere defenders had stopped looking.

The three most common gap categories

We observed three patterns repeatedly across the six audits. The aggregate is that 2,158 viable DDoS attack vectors were reachable across the 575 exposed subdomains. We are not publishing per-category breakdowns here because we do not want to give attackers a heatmap of where to focus. The patterns themselves are public knowledge to anyone running the same recon.

Gap 1: Origin IPs leaked via legacy DNS records

Many subdomains still had legacy A records pointing directly at origin IPs in the company's owned ASN, while the parent CNAME pointed at the CDN. Anyone running dig against these names gets the origin in one query. The CDN protection in front is decorative.

This pattern usually originates from a migration to CDN-fronted hosting that was done at the parent zone but never rolled out to staging, dev, or partner-specific subdomains. The migration succeeded for www.example.co.il. It never happened for staging-eu.api.example.co.il.

Gap 2: Mobile API endpoints excluded from CDN routing

Every one of the six enterprises had at least one api.* or m.* subdomain that was deliberately not CDN-fronted. The reason given internally is always latency: developers do not want their mobile API to add 30ms of CDN edge latency on each call.

The result is that the mobile API is the single most attractive DDoS target in the entire estate. It is unprotected, it is well-known to authenticated attackers (the mobile app reveals it on first launch), and it is often the slowest backend in the architecture. We observed mobile API endpoints with no rate limiting, no authentication on health-check paths, and no request-size validation, meaning a single attacker could exhaust connection pools with one machine and a Python script.

Gap 3: TLS posture rotation gaps

A meaningful share of subdomains had TLS configurations that suggest the certificate is reissued automatically (Let's Encrypt or DigiCert ACME) but no one is monitoring the result. We observed mixed cipher suites within the same enterprise, deprecated TLS 1.0/1.1 still negotiable on internal-facing subdomains, and SAN entries on certificates that revealed the existence of subdomains the recon pipeline had not yet discovered through any other source. Certificates leak topology.

This is not directly a DDoS vector, but it is a high-value reconnaissance vector for the attacker who is planning a DDoS. We mention it because it shows up in every audit and almost no defender team is responsible for it.

What surprised us

First, the absolute count of viable attack vectors across just six enterprises (2,158) is dramatically higher than what most enterprises think they have, even individually. The mental model is "we have a CDN, so we are protected." The empirical reality is that protection coverage is uneven, with hundreds of distinct paths to the origin. Each path is a separate vector that has to be independently mitigated.

Second, the gap between primary-domain protection and long-tail-subdomain protection was wider than we expected. For most of the six enterprises, the parent domain (example.co.il) was well-defended. The fortieth subdomain down the inventory was not. Protection effort had been concentrated where the marketing team is, not where the attack surface is.

What this means for an Israeli enterprise CISO

If you read this and you are responsible for the DDoS posture of an IL enterprise, three things are worth doing this week:

1. Discover your own surface. Your CDN dashboard does not show you the subdomains that bypass it. Pull a fresh CT log query for your parent domain and count the SLDs you do not recognize.
2. Audit your api.* and m.* endpoints specifically. They are the most likely to be excluded from CDN routing. Verify they have rate limiting that survives a single-IP attacker generating 10k requests per second.
3. Decommission what you can. Half of the long-tail subdomains in our audit were attached to projects that ended years ago. They are still serving traffic, still resolvable, and still exploitable.

OpIsrael 2026 has already passed. OpIsrael 2027 is in eleven months. The defenders who do well in the next one are the ones who fix this between now and February 2027, not the ones who tighten configurations the week of.

Run the audit on your own domain

If you want the full per-asset breakdown including the list of viable attack vectors and our recommended remediation order, contact us and we will run a deep audit with you. Israeli enterprises get priority scheduling through OpIsrael season.

DDactic is a Tel Aviv-based DDoS resilience testing platform. We map enterprise attack surfaces, simulate the specific attack vectors that would land against your real defenses, and track remediation over time. Built by an offensive-security engineer with three years in the field.