Hacktivists moved well beyond their traditional DDoS attacks and website defacements in 2025, increasingly targeting industrial control systems (ICS), ransomware, breaches, and data leaks, as their sophistication and alignment with nation-state interests grew. 

That was one of the conclusions in Cyble’s exhaustive new 2025 Threat Landscape report, from which this blog was adapted. 

Looking ahead to 2026 and beyond, Cyble expects critical infrastructure attacks by hacktivists to continue to grow, increasing use of custom tools by hacktivists, and deepening alignment between nation-state interests and hacktivists. 

ICS Attacks by Hacktivists Surge 

Between December 2024 and December 2025, several hacktivist groups increased their focus on ICS and operational technology (OT) attacks. Z-Pentest was the most active actor, conducting repeated intrusions against a wide range of industrial technologies. Dark Engine (Infrastructure Destruction Squad) and Sector 16 persistently targeted ICS, primarily exposing Human Machine Interfaces (HMI). 

A secondary tier of groups, including Golden Falcon Team, NoName057 (16), TwoNet, RipperSec, and Inteid, also claimed to have conducted recurrent ICS-disrupting attacks, albeit on a smaller scale. 

HMI and web-based Supervisory Control and Data Acquisition (SCADA) interfaces were the most frequently targeted systems, followed by a limited number of Virtual Network Computing (VNC) compromises, which posed the greatest operational risks to several industries. 

Building Management System (BMS) platforms and Internet of Things (IoT) or edge-layer controllers were also targeted in increasing numbers, reflecting the broader exploitation of weakly secured IoT interfaces. 

Europe remained the primary region affected by pro-Russian hacktivist groups, with sustained targeting of Spain, Italy, the Czech Republic, France, Poland, and Ukraine contributing to the highest concentration of ICS-related intrusions. 

The Intersection of State Interests and Hacktivism 

State-aligned hacktivist activity remained persistent throughout 2025. Operation Eastwood (14–17 July) disrupted NoName057(16)’s DDoS infrastructure, prompting swift retaliatory attacks from the hacktivist group. The group rapidly rebuilt capacity and resumed operations against Ukraine, the EU, and NATO, underscoring the resilience of state-directed ecosystems. 

U.S. indictments and sanctions further exposed alleged structured cooperation between Russian intelligence services and pro-Kremlin hacktivist fronts. The Justice Department detailed GRU-backed financing and tasking of the Cyber Army of Russia Reborn (CARR), as well as the state-sanctioned development of NoName057(16)’s DDoSia platform. 

Z-Pentest, identified as part of the same CARR ecosystem and attributed to GRU, continued targeting EU and NATO critical infrastructure, reinforcing the convergence of activist personas, state mandates, and operational doctrine. 

Pro-Ukrainian hacktivist groups, though not formally state-directed, conducted sustained, destructive operations against networks linked to the Russian military. The BO Team and the Ukrainian Cyber Alliance conducted several data destruction and wiper attacks, encrypting key Russian businesses and state machinery. Ukrainian actors repeatedly stated that exfiltrated datasets were passed to national intelligence services. 

Hacktivist groups Cyber Partisans BY (Belarus) and Silent Crow claimed a year-long Tier-0 compromise of Aeroflot’s IT environment, allegedly exfiltrating more than 20TB of data, sabotaging thousands of servers, and disrupting core airline systems, a breach that Russia’s General Prosecutor confirmed caused significant operational outages and flight cancellations. 

Research into BQT.Lock (BaqiyatLock) suggests a plausible ideological alignment with Hezbollah, as evidenced by narrative framing and targeting posture. However, no verifiable technical evidence has confirmed a direct organizational link. 

Cyb3r Av3ngers, associated with the Islamic Revolutionary Guard Corps (IRGC), struck critical infrastructure assets, including electrical networks and water utilities in Israel, the United States, and Ireland. After being banned on Telegram, the group resurfaced under the alias Mr. Soul Team. 

Tooling and capability development by hacktivist groups also grew significantly in 2025. Observed activities have included: 

• Notable growth in custom tool creation (e.g., BQT Locker and associated utilities), including the adoption of ransomware as a hacktivist mechanism. 

• Actors are increasingly using AI-generated text and imagery for propaganda and spreading misinformation and disinformation. 

• Tool promotion and marketing is becoming an emerging driver fueling hacktivism. 

 Hacktivist Sightings Surged 51% in 2025 

In 2025, hacktivism evolved into a globally coordinated threat, closely tracking geopolitical flashpoints. Armed conflicts, elections, trade disputes, and diplomatic crises fueled intensified campaigns against state institutions and critical infrastructure, with hacktivist groups weaponizing cyber-insurgency to advance their propaganda agendas. 

Pro-Ukrainian, pro-Palestinian, pro-Iranian, and other nationalist groups launched ideologically driven campaigns tied to the Russia-Ukraine War, the Israel-Hamas conflict, Iran-Israel tensions, South Asian tensions, and the Thailand-Cambodia border crisis. Domestic political unrest in the Philippines and Nepal triggered sustained attacks on government institutions. 

Cyble recorded a 51% increase in hacktivist sightings in 2025, from 700,000 in 2024 to 1.06 million in 2025, with the bulk of activity focused on Asia and Europe (chart below). 

Pro-Russian state-aligned hacktivists and pro-Palestinian, anti-Israel collectives continued to be the primary drivers of hacktivist activity throughout 2025, shaping the operational tempo and geopolitical focus of the threat landscape. 

Alongside these dominant ecosystems, Cyble observed a marked increase in operations by Kurdish hacktivist groups and emerging Cambodian clusters, both of which conducted campaigns closely aligned with regional strategic interests. 

Below are some of the major hacktivist groups of 2025: 

India, Ukraine, and Israel were the countries most impacted by hacktivist activity in 2025 (country breakdown below). 

Among global regions targeted, Europe and NATO faced a sustained pro-Russian campaign marked by coordinated DDoS attacks, data leaks, and escalating ICS intrusions against NATO and EU member states. Government & LEA, Energy & Utilities, Manufacturing, and Transportation were consistent targets. 

In the Middle East, Israel remains the principal target amid the Gaza conflict-related escalation, Iran-Israel confrontation, and Yemen-Saudi hostilities. Saudi Arabia, UAE, Egypt, Jordan, Iraq, Syria, and Yemen faced sustained DDoS attacks, defacements, data leaks, and illicit access to exposed ICS assets from ideologically aligned coalitions operating across the region. 

In South Asia, India-Pakistan and India-Bangladesh tensions fueled high-volume, ideologically framed offensives, peaking around political flashpoints and militant incidents. Activity concentrated on Government & LEA, BFSI, Telecommunication, and Education. 

In Southeast Asia, border tensions and domestic unrest shaped a fragmented but active theatre: Thailand-Cambodia conflicts triggered reciprocal DDoS and defacements; Indonesia & Malaysia incidents stemmed from political and social disputes; the Philippines saw attacks linked to internal instability; and Taiwan emerged as a recurring target for pro-Russian actors.  

 Below are some of the major hacktivist campaigns of 2025: 

Most Impacted Industries and Sectors 

2025 witnessed a marked expansion of hacktivist focus across multiple industries. Government & LEA, Energy & Utilities, Education, IT & ITES, Transportation & Logistics, and Manufacturing experienced the most pronounced growth in targeting, driving the year’s overall increase in operational activity. 

The dataset also reveals a broadened attack surface, with several new or significantly expanded categories, including Agriculture & Livestock, Food & Beverages, Hospitality, Construction, Automotive, and Real Estate. 

Government & LEA was the most impacted sector by a wide margin, followed by Energy & Utilities (chart below). 

The Evolution of Hacktivism 

Hacktivism has evolved into a geopolitically charged, ICS-focused threat, continuing to exploit exposed OT environments and increasingly weaponizing ransomware as a protest mechanism. 

In 2026, hacktivists and cybercriminals will increasingly target exposed HMI/SCADA systems and VNC takeovers, aided by public PoCs and automated scanning templates, creating ripple effects across the energy, water, transportation, and healthcare sectors. 

Hacktivists and state actors will increasingly employ financially motivated tactics and appearances. State actors in Iran, Russia, and North Korea will increasingly adopt RaaS platforms to fund operations and maintain plausible deniability. Critical infrastructure attacks in Taiwan, the Baltic states, and South Korea will appear financially motivated while serving geopolitical objectives, complicating attribution and response. 

Critical assets should be isolated from the Internet wherever possible, and operational technology (OT) and IT networks should be segmented and protected with Zero Trust access controls. Vulnerability management, along with network and endpoint monitoring and hardening, is another critical cybersecurity best practice. 

Cyble’s comprehensive attack surface management solutions can help by scanning network and cloud assets for exposures and prioritizing fixes, in addition to monitoring for leaked credentials and other early warning signs of major cyberattacks. Get a free external threat profile for your organization today. 

The post Critical Infrastructure Attacks Became Routine for Hacktivists in 2025 appeared first on Cyble.

Cyble – ​Read More

Millions of IT systems — some of them industrial and IoT — may start behaving unpredictably on January 19. Potential failures include: glitches in processing card payments; false alarms from security systems; incorrect operation of medical equipment; failures in automated lighting, heating, and water supply systems; and many more less serious types of errors. The catch is — it will happen on January 19, 2038. Not that that’s a reason to relax — the time left to prepare may already be insufficient. The cause of this mass of problems will be an overflow in the integers storing date and time. While the root cause of the error is simple and clear, fixing it will require extensive and systematic efforts on every level — from governments and international bodies and down to organizations and private individuals.

The unwritten standard of the Unix epoch

The Unix epoch is the timekeeping system adopted by Unix operating systems, which became popular across the entire IT industry. It counts the seconds from 00:00:00 UTC on January 1, 1970, which is considered the zero point. Any given moment in time is represented as the number of seconds that have passed since that date. For dates before 1970, negative values are used. This approach was chosen by Unix developers for its simplicity — instead of storing the year, month, day, and time separately, only a single number is needed. This facilitates operations like sorting or calculating the interval between dates. Today, the Unix epoch is used far beyond Unix systems: in databases, programming languages, network protocols, and in smartphones running iOS and Android.

The Y2K38 time bomb

Initially, when Unix was developed, a decision was made to store time as a 32-bit signed integer. This allowed for representing a date range from roughly 1901 to 2038. The problem is that on January 19, 2038, at 03:14:07 UTC, this number will reach its maximum value (2,147,483,647 seconds) and overflow, becoming negative, and causing computers to “teleport” from January 2038 back to December 13, 1901. In some cases, however, shorter “time travel” might happen — to point zero, which is the year 1970.

This event, known as the “year 2038 problem”, “Epochalypse”, or “Y2K38”, could lead to failures in systems that still use 32-bit time representation — from POS terminals, embedded systems, and routers, to automobiles and industrial equipment. Modern systems solve this problem by using 64 bits to store time. This extends the date range to hundreds of billions of years into the future. However, millions of devices with 32-bit dates are still in operation, and will require updating or replacement before “day Y” arrives.

In this context, 32 and 64 bits refer specifically to the date storage format. Just because an operating system or processor is 32-bit or 64-bit, it doesn’t automatically mean it stores the date in its “native” bit format. Furthermore, many applications store dates in completely different ways, and might be immune to the Y2K38 problem, regardless of their bitness.

In cases where there’s no need to handle dates before 1970, the date is stored as an unsigned 32-bit integer. This type of number can represent dates from 1970 to 2106, so the problem will arrive in the more distant future.

Differences from the year 2000 problem

The infamous year 2000 problem (Y2K) from the late 20^th century was similar in that systems storing the year as two digits could mistake the new date for the year 1900. Both experts and the media feared a digital apocalypse, but in the end there were just numerous isolated manifestations that didn’t lead to global catastrophic failures.

The key difference between Y2K38 and Y2K is the scale of digitization in our lives. The number of systems that will need updating is way higher than the number of computers in the 20^th century, and the count of daily tasks and processes managed by computers is beyond calculation. Meanwhile, the Y2K38 problem has already been, or will soon be, fixed in regular computers and operating systems with simple software updates. However, the microcomputers that manage air conditioners, elevators, pumps, door locks, and factory assembly lines could very well chug along for the next decade with outdated, Y2K38-vulnerable software versions.

Potential problems of the Epochalypse

The date’s rolling over to 1901 or 1970 will impact different systems in different ways. In some cases, like a lighting system programmed to turn on every day at 7pm, it might go completely unnoticed. In other systems that rely on complete and accurate timestamps, a full failure could occur — for example, in the year 2000, payment terminals and public transport turnstiles stopped working. Comical cases are also possible, like issuing a birth certificate with a date in 1901. Far worse would be the failure of critical systems, such as a complete shutdown of a heating system, or the failure of a bone marrow analysis system in a hospital.

Cryptography holds a special place in the Epochalypse. Another crucial difference between 2038 and 2000 is the ubiquitous use of encryption and digital signatures to protect all communications. Security certificates generally fail verification if the device’s date is incorrect. This means a vulnerable device would be cut off from most communications — even if its core business applications don’t have any code that incorrectly handles the date.

Unfortunately, the full spectrum of consequences can only be determined through controlled testing of all systems, with separate analysis of a potential cascade of failures.

The malicious exploitation of Y2K38

IT and InfoSec teams should treat Y2K38 not as a simple software bug, but as a vulnerability that can lead to various failures, including denial of service. In some cases, it can even be exploited by malicious actors. To do this, they need the ability to manipulate the time on the targeted system. This is possible in at least two scenarios:

• Interfering with NTP protocol data by feeding the attacked system a fake time server
• Spoofing the GPS signal — if the system relies on satellite time

Exploitation of this error is most likely in OT and IoT systems, where vulnerabilities are traditionally slow to be patched, and the consequences of a failure can be far more substantial.

An example of an easily exploitable vulnerability related to time counting is CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) in Dover ProGauge MagLink LX4 automatic fuel-tank gauge consoles. Time manipulation can cause a denial of service at the gas station, and block access to the device’s web management panel. This defect earned its own CISA advisory.

The current status of Y2K38 mitigation

The foundation for solving the Y2K38 problem has been successfully laid in major operating systems. The Linux kernel added support for 64-bit time even on 32-bit architectures starting with version 5.6 in 2020, and 64-bit Linux was always protected from this issue. The BSD family, macOS, and iOS use 64-bit time on all modern devices. All versions of Windows released in the 21^st century aren’t susceptible to Y2K38.

The situation at the data storage and application level is far more complex. Modern file systems like ZFS, F2FS, NTFS, and ReFS were designed with 64-bit timestamps, while older systems like ext2 and ext3 remain vulnerable. Ext4 and XFS require specific flags to be enabled (extended inode for ext4, and bigtime for XFS), and might need offline conversion of existing filesystems. In the NFSv2 and NFSv3 protocols, the outdated time storage format persists. It’s a similar patchwork landscape in databases: the TIMESTAMP type in MySQL is fundamentally limited to the year 2038, and requires migration to DATETIME, while the standard timestamp types in PostgreSQL are safe. For applications written in C, pathways have been created to use 64-bit time on 32-bit architectures, but all projects require recompilation. Languages like Java, Python, and Go typically use types that avoid the overflow, but the safety of compiled projects depends on whether they interact with vulnerable libraries written in C.

A massive number of 32-bit systems, embedded devices, and applications remain vulnerable until they’re rebuilt and tested, and then have updates installed by all their users.

Various organizations and enthusiasts are trying to systematize information on this, but their efforts are fragmented. Consequently, there’s no “common Y2K38 vulnerability database” out there (1, 2, 3, 4, 5).

Approaches to fixing Y2K38

The methodologies created for prioritizing and fixing vulnerabilities are directly applicable to the year 2038 problem. The key challenge will be that no tool today can create an exhaustive list of vulnerable software and hardware. Therefore, it’s essential to update inventory of corporate IT assets, ensure that inventory is enriched with detailed information on firmware and installed software, and then systematically investigate the vulnerability question.

The list can be prioritized based on the criticality of business systems and the data on the technology stack each system is built on. The next steps are: studying the vendor’s support portal, making direct inquiries to hardware and software manufacturers about their Y2K38 status, and, as a last resort, verification through testing.

When testing corporate systems, it’s critical to take special precautions:

• Never test production systems.
• Create a data backup immediately before the test.
• Isolate the system being tested from communications so it can’t confuse other systems in the organization.
• If changing the date uses NTP or GPS, ensure the 2038 test signals cannot reach other systems.
• After testing, set the systems back to the correct time, and thoroughly document all observed system behaviors.

If a system is found to be vulnerable to Y2K38, a fixing timeline should be requested from the vendor. If a fix is impossible, plan a migration; fortunately, the time we have left still allows for updating even fairly complex and expensive systems.

The most important thing in tackling Y2K38 is not to think of it as a distant future problem whose solution can easily wait another five to eight years. It’s highly likely that we already have insufficient time to completely eradicate the defect. However, within an organization and its technology fleet, careful planning and a systematic approach to solving the problem will allow to actually make it in time.

Kaspersky official blog – ​Read More

Brand, website, and corporate mailout impersonation is becoming an increasingly common technique used by cybercriminals. The World Intellectual Property Organization (WIPO) reported a spike in such incidents in 2025. While tech companies and consumer brands are the most frequent targets, every industry in every country is generally at risk. The only thing that changes is how the imposters exploit the fakes In practice, we typically see the following attack scenarios:

• Luring clients and customers to a fake website to harvest login credentials for the real online store, or to steal payment details for direct theft.
• Luring employees and business partners to a fake corporate login portal to acquire legitimate credentials for infiltrating the corporate network.
• Prompting clients and customers to contact the scammers under various pretexts: getting tech support, processing a refund, entering a prize giveaway, or claiming compensation for public events involving the brand. The goal is to then swindle the victims out of as much money as possible.
• Luring business partners and employees to specially crafted pages that mimic internal company systems, to get them to approve a payment or redirect a legitimate payment to the scammers.
• Prompting clients, business partners, and employees to download malware — most often an infostealer — disguised as corporate software from a fake company website.

The words “luring” and “prompting” here imply a whole toolbox of tactics: email, messages in chat apps, social media posts that look like official ads, lookalike websites promoted through SEO tools, and even paid ads.

These schemes all share two common features. First, the attackers exploit the organization’s brand, and strive to mimic its official website, domain name, and corporate style of emails, ads, and social media posts. And the forgery doesn’t have to be flawless — just convincing enough for at least some of business partners and customers. Second, while the organization and its online resources aren’t targeted directly, the impact on them is still significant.

Business damage from brand impersonation

When fakes are crafted to target employees, an attack can lead to direct financial loss. An employee might be persuaded to transfer company funds, or their credentials could be used to steal confidential information or launch a ransomware attack.

Attacks on customers don’t typically imply direct damage to the company’s coffers, but they cause substantial indirect harm in the following areas:

• Strain on customer support. Customers who “bought” a product on a fake site will likely bring their issues to the real customer support team. Convincing them that they never actually placed an order is tough, making each case a major time waster for multiple support agents.
• Reputational damage. Defrauded customers often blame the brand for failing to protect them from the scam, and also expect compensation. According to a European survey, around half of affected buyers expect payouts and may stop using the company’s services — often sharing their negative experience on social media. This is especially damaging if the victims include public figures or anyone with a large following.
• Unplanned response costs. Depending on the specifics and scale of an attack, an affected company might need digital forensics and incident response (DFIR) services, as well as consultants specializing in consumer law, intellectual property, cybersecurity, and crisis PR.
• Increased insurance premiums. Companies that insure businesses against cyber-incidents factor in fallout from brand impersonation. An increased risk profile may be reflected in a higher premium for a business.
• Degraded website performance and rising ad costs. If criminals run paid ads using a brand’s name, they siphon traffic away from its official site. Furthermore, if a company pays to advertise its site, the cost per click rises due to the increased competition. This is a particularly acute problem for IT companies selling online services, but it’s also relevant for retail brands.
• Long-term metric decline. This includes drops in sales volume, market share, and market capitalization. These are all consequences of lost trust from customers and business partners following major incidents.

Does insurance cover the damage?

Popular cyber-risk insurance policies typically only cover costs directly tied to incidents explicitly defined in the policy — think data loss, business interruption, IT system compromise, and the like. Fake domains and web pages don’t directly damage a company’s IT systems, so they’re usually not covered by standard insurance. Reputational losses and the act of impersonation itself are separate insurance risks, requiring expanded coverage for this scenario specifically.

Of the indirect losses we’ve listed above, standard insurance might cover DFIR expenses and, in some cases, extra customer support costs (if the situation is recognized as an insured event). Voluntary customer reimbursements, lost sales, and reputational damage are almost certainly not covered.

What to do if your company is attacked by clones

If you find out someone is using your brand’s name for fraud, it makes sense to do the following:

• Send clear, straightforward notifications to your customers explaining what happened, what measures are being taken, and how to verify the authenticity of official websites, emails, and other communications.
• Create a simple “trust center” page listing your official domains, social media accounts, app store links, and support contacts. Make it easy to find and keep it updated.
• Monitor new registrations of social media pages and domain names that contain your brand names to spot the clones before an attack kicks off.
• Follow a takedown procedure. This involves gathering evidence, filing complaints with domain registrars, hosting providers, and social media administrators, then tracking the status until the fakes are fully removed. For a complete and accurate record of violations, preserve URLs, screenshots, metadata, and the date and time of discovery. Ideally, also examine the source code of fake pages, as it might contain clues pointing to other components of the criminal operation.
• Add a simple customer reporting form for suspicious sites or messages to your official website and/or branded app. This helps you learn about problems early.
• Coordinate activities between your legal, cybersecurity, and marketing teams. This ensures a consistent, unified, and effective response.

How to defend against brand impersonation attacks

While the open nature of the internet and the specifics of these attacks make preventing them outright impossible, a business can stay on top of new fakes and have the tools ready to fight back.

• Continuously monitor for suspicious public activity using specialized monitoring services. The most obvious indicator is the registration of domains similar to your brand name, but there are others — like someone buying databases related to your organization on the dark web. Comprehensive monitoring of all platforms is best outsourced to a specialized service provider, such as Kaspersky Digital Footprint Intelligence (DFI).
• The quickest and simplest way to take down a fake website or social media profile is to file a trademark infringement complaint. Make sure your portfolio of registered trademarks is robust enough to file complaints under UDRP procedures before you need it.
• When you discover fakes, deploy UDRP procedures promptly to have the fake domains transferred or removed. For social media, follow the platform’s specific infringement procedure — easily found by searching for “[social media name] trademark infringement” (for example, “LinkedIn trademark infringement”). Transferring the domain to the legitimate owner is preferred over deletion, as it prevents scammers from simply re-registering it. Many continuous monitoring services, such as Kaspersky Digital Footprint Intelligence, also offer a rapid takedown service, filing complaints on the protected brand’s behalf.
• Act quickly to block fake domains on your corporate systems. This won’t protect partners or customers, but it’ll throw a wrench into attacks targeting your own employees.
• Consider proactively registering your company’s website name and common variations (for example, with and without hyphens) in all major top-level domains, such as .com, and local extensions. This helps protect partners and customers from common typos and simple copycat sites.

Kaspersky official blog – ​Read More