Phoenix Financial DDoS: 522 Errors Disrupt Israeli Website

A Phoenix Financial DDoS campaign pushed the public website of Israel’s Phoenix Holdings group into repeated error states on September 14, 2026, according to screenshots and monitoring links posted by the hacktivist crew RipperSec. The site at phoenixfinancial.co.il returned Cloudflare 522 and 502 responses, connection timeouts and a few very slow 200 replies from probes around the world.

The posts tie the activity to #OpZionistV2 and show three rounds of traffic over about two hours. Nothing in the material points to stolen data or a network intrusion. The evidence covers the availability of a corporate and investor relations website, and nothing beyond that.

How RipperSec Announced the Target

The opening post carries a #OpZionistV2 banner and a “NEW TARGET RELEASED” header. It names Phoenix Financial and describes it as the official investor relations and corporate site of The Phoenix Holdings Ltd., a financial services group listed on the Tel Aviv Stock Exchange.

A second block sets the schedule. The order time reads 2000, the time zone line says 08:00GMT, and the date is 14/09/2026. The post also lists the target URL, ports 80 and 443, and Cloudflare, Inc. as the ISP. The IP address and a custom message are blacked out. It ends with thanks to allies and a prompt to follow for updates, and it showed 19 views and 10 comments when captured.

Naming the ports and the CDN tells defenders what the crew aimed at. This was the web front end, not a payment system or a database.

RipperSec and the OpZionistV2 Banner

The logo shows a skull framed by crescent moons, with RipperSec written in Latin letters and in Arabic script around the ring. The same emblem is stamped on the Cloudflare error screenshot, which links the later evidence to the same group. The “V2” in the campaign name points to a second run of the operation. https://cyberasia.io/article/ddos/rippersec-ddos-hits-max-co-il/: RipperSec MAX IT Finance DDoS report] covers another target from the same campaign date.

Phoenix Financial DDoS Timeline: Three Rounds in Two Hours

Round one arrived at 19:23 with a check-host.net report listing dozens of probe locations. Most rows show red connection timeouts, while a few return 200 OK only after very long waits. Ten minutes later a “Proof” post added a terminal window with a “PHANTOM” attack banner, a method field set to CDN and a duration of 120 seconds. Beside it, an HTTP check shows several locations returning 522 after about 19.5 seconds, others timing out at 0 ms, and one 200 OK after more than 15 seconds.

The second round is labeled “Ronde 2” and appeared at 20:12. Its report is dominated by “Connection timed out” across Europe, the Americas and Asia. Jakarta returned a 503 Service Unavailable, and one Iranian node reported a connection reset by peer. A second post from the same minute shows a console filled with “context deadline exceeded” request errors, plus a phone browser displaying “This site can’t be reached” with ERR_CONNECTION_ABORTED.

The third round came at 20:58 with a console banner for a tool called MegaMedusa V3. The output lists the target URL, a run time of 3600, a rate of 30, ten threads, a SOCKS5 proxy file and ten numbered engines, ending with a line that reads “MegaMedusa Attacking…” At 21:08 the last post showed phoenixfinancial.co.il in a browser, answering with a Cloudflare “Bad gateway” page, error code 502, stamped 2026-09-14 14:03:21 UTC.

What the 522, 502 and 503 Errors Mean

The codes show where the chain broke. On the 502 page, the visitor’s browser and Cloudflare’s Singapore edge are marked as working, while the origin host is marked in red. Cloudflare was online but could not get a usable answer from the web server behind it. A 522 means the connection from Cloudflare to the origin timed out, and a 503 means the service was unavailable.

That pattern fits a flood of requests that drains the origin while the CDN edge stays up. Sites behind a CDN can still fall over when traffic bypasses the cache, for example through requests for pages that cannot be cached. Cloudflare’s 5xx error documentation explains each code in detail.

Reading the Screenshots Carefully

Every image comes from the attackers’ own channel, so the captures show the group’s best moments, not a continuous uptime record. The check-host.net service probes from many nodes, and a timeout from one distant node can also come from routing or geo-filtering. The mix of 200 replies and errors in round one suggests a degraded site rather than a full outage.

The captures do not show how long the disruption lasted, whether the site recovered between rounds, or whether customer portals or trading links were touched. The material reviewed contains no response from Phoenix Holdings.

Defensive Steps for Sites Behind a CDN

• Accept origin traffic only from the CDN’s published IP ranges, and keep the real origin address out of DNS history.
• Cache what can be cached, and set rate limits on login, search and other dynamic paths.
• Switch on challenge modes at the edge before the origin saturates.
• Run external probes from several regions and alert on spikes in 5xx responses.
• Keep a short holding statement ready for the investor relations page.

FAQ

Q1 : Was customer or investor data exposed in the Phoenix Financial DDoS?

Nothing in the screenshots shows that. A DDoS floods a service with requests and does not by itself open a database. The captures show only availability errors on a public website, so affected people should wait for an official notice from the company.

Q2 : Why did Cloudflare show errors if the site sits behind a CDN?

The CDN protects the edge, but it still has to fetch uncached content from the origin. When the origin stops answering in time, Cloudflare returns 522 or 502 pages even though its own network is healthy.

Q3 : What should an admin do first when the origin starts failing?

Confirm the origin is locked to CDN addresses, then raise edge protections and rate limits on the busiest paths. Check logs for the most requested URLs and block abusive patterns. Post a status note so investors know the outage is under control.

Q4 : Can check-host results prove a site is down?

They show what a set of probes saw at one moment. Several nodes failing at once is a strong hint of trouble, but only the site owner’s own logs can confirm duration and impact.

Research Notice

This article is published for cybersecurity research and education. CyberAsia.IO does not support or encourage any cyberattack, and readers must not test or disrupt systems without written authorization. The information comes from public screenshots and does not represent an official statement by the organization named.