Skip to content
HACKTECH
IsraelReported Published 2 sources

Israel's cyber directorate logged about 26,500 incident reports in 2025, up 55%

In its annual report for 2025, Israel's National Cyber Directorate (INCD) said its 119 National Cyber Emergency Center handled about 26,500 incident reports in 2025, a 55% increase on 2024, according to the Jerusalem Post and Israel Defense. The directorate issued about 2,480 alerts, a 2.5-fold increase, of which 2,304 were proactive notifications to organisations based on indicators of targeted attacks. Phishing accounted for 52% of reported incidents. Reports peaked in June 2025, during the 12-day war with Iran, at 3,650.

  • Israel
  • INCD
  • annual report
  • phishing
  • infostealers
  • supply chain

What the sources report

  • The INCD issued about 2,480 alerts, a 2.5-fold increase. Of these, 2,304 were proactive notifications based on specific indicators of targeted attacks, sent even when the organisations were not necessarily aware of the attacks, and 93% of alerts were targeted at specific organisations.
  • Phishing made up 52% of reported incidents, followed by influence and psychological operations (13%), account breaches on social media, email and cloud services (11%) and system intrusions (9%) (Israel Defense).
  • Activity peaked in June 2025, during the 12-day war with Iran, with 3,650 reports, 75% above the monthly average for the rest of the year (Israel Defense). The Jerusalem Post reports the same 75% surge.
  • The INCD named initial access vectors including phishing and credential theft via spoofed emails, infostealer malware, supply-chain compromises through third-party vendors, exploitation of unpatched legacy systems, security products and VPN/RDP remote-access services, and vulnerable IoT devices (Jerusalem Post).
  • Major incidents included an attempted disruption of operations at Shamir Medical Center during Yom Kippur, an attack on a software provider whose management systems serve institutions including nursing homes, and a wiper attack that deleted client servers at a cloud-service provider.

What it means for your organisation

Most of the directorate's alerts were proactive notifications based on specific indicators of targeted attacks, so an organisation may first hear about an intrusion from the INCD rather than from its own monitoring. The runbook should name who receives that warning, who verifies it and who acts on it, and the entry points the INCD lists (spoofed emails, infostealers, third-party vendors, unpatched legacy systems, security products, and VPN and RDP services) are the ones to test first.

What we check

  • Check the patch level and internet exposure of VPN, RDP and security appliances, including legacy systems that can still be reached from outside.
  • Confirm SPF, DKIM and DMARC are enforced, and run a simulated phishing campaign against staff.
  • Search for corporate credentials and session tokens leaked by infostealers, and confirm MFA covers email, cloud and social media admin accounts.
  • List which suppliers hold remote access, what privileges they have and how their sessions are monitored.
  • Test the incident response runbook step for receiving, verifying and acting on an external notification such as an INCD alert.

Sources

Services that cover these checks

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • Social engineering assessment

    Phishing, vishing and physical pretexting run against your staff, help desk and finance team, only under written authorisation that names the targets, pretexts and limits. Results are reported by channel and pretext, never by name: how far a convincing approach got, how many people reported it and how long the first report took to reach someone who acted.

    Duration: 2 to 4 weeks including campaign preparation

  • Network & infrastructure testing

    Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.

    Duration: 5 to 12 working days

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Threat modelling

    Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works