Poland’s ABW confirmed hackers breached ICS at five water plants, gaining ability to alter equipment settings. Russia-linked APT groups suspected.
Poland’s Internal Security Agency (ABW) has published a detailed account of a sustained campaign targeting the country’s water plants, documenting security breaches at five water treatment facilities in 2025. The incidents mark one of the clearest documented cases in Europe of state-linked hackers gaining direct access to industrial control systems managing public water supplies.
The affected facilities were located in Jabłonna Lacka, Szczytno, Małdyty, Tolkmicko, and Sierakowo. In several cases, attackers didn’t just observe, they obtained the ability to modify operational parameters of equipment in real time, creating a direct and concrete risk to the continuity of public water services. A breach of this kind isn’t a data theft. It is the digital equivalent of sabotage.
“In some cases, the attackers gained access to industrial control systems and obtained the capability to modify device operating parameters.” reads the report published by ABW. “This created a direct threat to the continuity of water supply processes and the proper functioning of municipal infrastructure.”
The attack vectors ABW identified are as unglamorous as they are alarming: weak password policies and systems left directly exposed to the internet. These are not sophisticated zero-day exploits. They are basic security failures that the OT and ICS security community has been warning about for years.
“The incidents were made possible by inadequate security measures, including weak password policies and the exposure of management interfaces directly to the public internet.” continues the report. “In several cases, systems responsible for operational technology were accessible without sufficient protection mechanisms.”
The attribution points firmly eastward. ABW identified Russian APT groups APT28 and APT29, the same actors linked to election interference across Europe and the SolarWinds supply chain attack, as well as UNC1151, a Belarusian-aligned group previously connected to the Ghostwriter operation targeting NATO countries.
“APT28, APT29 and UNC1151 are among the most active state-linked cyber espionage groups operating against European targets.” concludes the report. “Their activities combine intelligence collection, disruptive cyber operations and coordinated information warfare campaigns.”
Nearly 200,000 Zara customers were exposed in a third-party breach linked to ShinyHunters, revealing emails, purchase history, and support data.
Personal data belonging to nearly 197,000 Zara customers has been compromised following a cyberattack on a former technology provider used by Inditex, the Spanish fashion giant behind some of the world’s most recognized retail brands including Bershka, Pull&Bear, and Massimo Dutti.
The breach came to light last month when Inditex confirmed unauthorized access to databases hosted by a third-party vendor. The company was careful to limit the alarm: the compromised databases did not contain names, passwords, payment details, addresses, or phone numbers.
“Inditex has immediately applied its security protocols and has started notifying the relevant authorities of this unauthorized access, that stems from a security incident that affected a former technology provider and has impacted several companies operating internationally,” reads a statement by Inditex.
“Operations and systems haven’t been affected and customers can continue to access and use its services safely,”
What was exposed, however, tells a different story about the scale of the incident.
The data breach notification service Have I Been Pwned analyzed the stolen dataset and confirmed that 197,400 unique email addresses were among the compromised records, alongside order IDs, product SKUs, geographic locations, purchase history, and customer support tickets, enough to paint a detailed picture of individual shopping habits and interactions with the brand.
The extortion group ShinyHunters claimed the attack and the theft of a 140GB archive from BigQuery instances by exploiting compromised Anodot authentication tokens, the same technique they have used against dozens of other companies.
“Your Bigquery instances data was compromised thanks to Anodot.com.” the cybercrime group wrote on its Tor data leak site. “The company failed to reach an agreement with us despite our incredible patience, all the chances”
The Anodot vector is significant. ShinyHunters has told journalists that stolen Anodot tokens gave them access to analytics infrastructure across multiple large organizations simultaneously, a single point of failure that cascaded into dozens of separate breaches. The gang has also run coordinated vishing campaigns targeting employees’ SSO accounts at Microsoft Entra, Okta, and Google to move laterally into connected SaaS environments.
Inditex has not yet named the compromised provider or attributed the attack to a specific threat actor, despite ShinyHunters having publicly claimed it and released data as proof.
Zara is the flagship fashion brand of Inditex, one of the world’s largest apparel groups. Inditex reported revenue of about €38.6 billion in fiscal 2025 and employs roughly 160,000 people worldwide. Zara operates in more than 90 countries through thousands of stores and online platforms, making it one of the most globally recognized fast-fashion retailers.
Rival retailer Mango disclosed its own data breach last October, after a marketing vendor was hacked and customer data used in promotional campaigns was exposed. In that case, no extortion group has come forward, and the attackers remain unidentified.
Through our daily threat hunting, we noticed that, beginning in July 2025, a series of malicious wheel packages were uploaded to PyPI (the Python Package Index). We shared this information with the public security community, and the malware was removed from the repository. We submitted the samples to Kaspersky Threat Attribution Engine (KTAE) for analysis. Based on the results, we believe the packages may be linked to malware discussed in a Threat Intelligence report on OceanLotus.
While these wheel packages do implement the features described on their PyPI web pages, their true purpose is to covertly deliver malicious files. These files can be either .DLL or .SO (Linux shared library), indicating the packages’ ability to target both Windows and Linux platforms. They function as droppers, delivering the final payload – a previously unknown malware family that we have named ZiChatBot. Unlike traditional malware, ZiChatBot does not communicate with a dedicated command and control (C2) server, but instead uses a series of REST APIs from the public team chat app Zulip as its C2 infrastructure.
To conceal the malicious package containing ZiChatBot, the attacker created another benign-looking package that included the malicious package as a dependency. Based on these facts, we confirm that this campaign is a carefully planned and executed PyPI supply chain attack.
Technical details
Spreading
The attacker created three projects on PyPI and uploaded malicious wheel packages designed to imitate popular libraries, tricking users into downloading them. This is a clear example of a supply chain attack via PyPI. See below for detailed information about the fake libraries and their corresponding wheel packages.
Malicious wheel packages
The packages added by the attacker and listed on PyPI’s download pages are:
uuid32-utils library for generating a 32-character random string as a UUID
colorinal library for implementing cross-platform color terminal text
termncolor library for ANSI color format for terminal output
The key metadata for these packages are as follows:
Pip install command
File name
First upload date
Author / Email
pip install uuid32-utils
uuid32_utils-1.x.x-py3-none-[OS platform].whl
2025-07-16
laz**** / laz****@tutamail.com
pip install colorinal
colorinal-0.1.7-py3-none-[OS platform].whl
2025-07-22
sym**** / sym****@proton.me
pip install termncolor
termncolor-3.1.0-py3-none-any.whl
2025-07-22
sym**** / sym****@proton.me
Based on the distribution information on the PyPI web page, we can see that it offers X86 and X64 versions for Windows, as well as an x86_64 version for Linux. The colorinal project, for example, provides the following download options:
Distribution information of the colorinal project
Initial infection
The uuid32-utils and colorinal libraries employ similar infection chains and malicious payloads. As a result, this analysis will focus on the colorinal library as a representative example.
A quick look at the code of the third library, termncolor, reveals no apparent malicious content. However, it imports the malicious colorinal library as a dependency. This method allows attackers to deeply conceal malware, making the termncolor library appear harmless when distributing it or luring targets.
The termncolor library imports the malicious colorinal library
During the initial infection stage, the Python code is nearly identical across both Windows and Linux platforms. Here, we analyze the Windows version as an example.
Windows version
Once a Python user downloads and installs the colorinal-0.1.7-py3-none-win_amd64.whl wheel package file, or installs it using the pip tool, the ZiChatBot’s dropper (a file named terminate.dll) will be extracted from the wheel package and placed on the victim’s hard drive.
After that, if the colorinal library is imported into the victim’s project, the Python script file at [Python library installation path]\colorinal-0.1.7-py3-none-win_amd64\colorinal\__init__.py will be executed first.
The __init__.py script imports the malicious file unicode.py
This Python script imports and executes another script located at [python library install path]\colorinal-0.1.7-py3-none-win_amd64\colorinal\unicode.py. The is_color_supported() function in unicode.py is called immediately.
The code loads the dropper into the host Python process
The comment in the is_color_supported() function states that the highlighted code checks whether the user’s terminal environment supports color. The code actually loads the terminate.dll file into the Python process and then invokes the DLL’s exported function envir, passing the UTF-8-encoded string xterminalunicod as a parameter. The DLL acts as a dropper, delivering the final payload, ZiChatBot, and then self-deleting. At the end of the is_color_supported() function, the unicode.py script file is also removed. These steps eliminate all malicious files in the library and deploy ZiChatBot.
For the Linux platform, the wheel package and the unicode.py Python script are nearly identical to the Windows version. The only difference is that the dropper file is named “terminate.so”.
Dropper for ZiChatBot
From the previous analysis, we learned that the dropper is loaded into the host Python process by a Python script and then activated. The main logic of the dropper is implemented in the envir export function to achieve three objectives:
Deploy ZiChatBot.
Establish an auto-run mechanism.
Execute shellcode to remove the dropper file (terminate.dll) and the malicious script file from the installed library folder.
The dropper first decrypts sensitive strings using AES in CBC mode. The key is the string-type parameter “xterminalunicode” of the exported function. The decrypted strings are “libcef.dll”, “vcpacket”, “pkt-update”, and “vcpktsvr.exe”.
Next, the malware uses the same algorithm to decrypt the embedded data related to ZiChatBot. It then decompresses the decrypted data with LZMA to retrieve the files vcpktsvr.exe and libcef.dll associated with ZiChatBot. The malware creates a folder named vcpacket in the system directory %LOCALAPPDATA%, and places these files into it.
To establish persistence for ZiChatBot, the dropper creates the following auto-run entry in the registry:
Once preparations are complete, the malware uses the XOR algorithm to decrypt the embedded shellcode with the three-byte key 3a7. It then searches the decrypted shellcode’s memory for the string Policy.dllcppage.dll and replaces it with its own file name, terminate.dll, and redirects execution to the shellcode’s memory space.
The shellcode employs a djb2-like hash method to calculate the names of certain APIs and locate their addresses. Using these APIs, it finds the dropper file with the name terminate.dll that was previously passed by the DLL before unloading and deleting it.
Linux version
The Linux version of the dropper places ZiChatBot in the path /tmp/obsHub/obs-check-update and then creates an auto-run job using crontab. Unlike the Windows version, the Linux version of ZiChatBot only consists of one ELF executable file.
The Windows version of ZiChatBot is a DLL file (libcef.dll) that is loaded by the legitimate executable vcpktsvr.exe (hash: 48be833b0b0ca1ad3cf99c66dc89c3f4). The DLL contains several export functions, with the malicious code implemented in the cef_api_mash export. Once the DLL is loaded, this function is invoked by the EXE file. ZiChatBot uses the REST APIs from Zulip, a public team chat application, as its command and control server.
ZiChatBot is capable of executing shellcode received from the server and only supports this one control command. Once it runs, it initiates a series of sequential HTTP requests to the Zulip REST API.
In each HTTP request, an API authentication token is included as an HTTP header for server-side authentication, as shown below.
ZiChatBot utilizes two separate channel-topic pairs for its operations. One pair transmits current system information, and the other retrieves a message containing shellcode. Once the shellcode is received, a new thread is created to execute it. After executing the command, a heart emoji is sent in response to the original message to indicate the execution was successful.
Infrastructure
We did not find any traditional infrastructure, such as compromised servers or commercial VPS services and their associated IPs and domains. Instead, the malicious wheel packages were uploaded to the Python Package Index (PyPI), a public, shared Python library. The malware, ZiChatBot, leverages Zulip’s public team chat REST APIs as its command and control server.
The “helper” organization that the attacker had registered on the Zulip service has now been officially deactivated by Zulip. However, infected devices may still attempt to connect to the service, so to help you locate and cure them, we recommend adding the full URL helper.zulipchat.com to your denylist.
Victims
The malware was uploaded in July 2025. Upon discovering these attacks, we quickly released an update for our product to detect the relevant files and shared the necessary information with the public security community. As a result, the malicious software was swiftly removed from PyPI, and the organization registered on the Zulip service was officially deactivated. To date, we have not observed any infections based on our telemetry or public reports.
Zulip has officially deactivated the “helper” organization
Attribution
Based on the results from our KTAE system, the dropper used by ZiChatBot shows a 64% similarity to another dropper we analyzed in a TI report, which was linked to OceanLotus. Reverse engineering shows that both droppers use nearly identical algorithms and logic for to decrypt and decompress their embedded payloads.
Analysis results of dropper using KTAE system
Conclusions
As an active APT organization, OceanLotus primarily targets victims in the Asia-Pacific region. However, our previous reports have highlighted a growing trend of the group expanding its activities into the Middle East. Moreover, the attacks described in this report – executed through PyPI – target Python users worldwide. This demonstrates OceanLotus’s ongoing effort to broaden its attack scope.
In the first half of 2025, a public report revealed that the group launched a phishing campaign using GitHub. The recent PyPI-based supply chain attack likely continues this strategy. Although phishing emails are still a common initial infection method for OceanLotus, the group is also actively exploring new ways to compromise victims through diverse supply chain attacks.
In this LABScon 25 presentation, Joe FitzPatrick explores how networked devices manufactured overseas have quietly become indispensable to everything from small-business prototyping labs to roadside infrastructure. He argues that the safeguards meant to manage the risks these devices introduce are, in practice, largely ineffective.
Starting with recent reports of undocumented cellular radios found in solar inverters used in U.S. highway infrastructure, Joe notes that adding that kind of connectivity to a device with an exposed serial port takes minutes and can be done by anyone: the manufacturer, the installer, or someone who came along later.
From there he covers the familiar mechanisms by which banned hardware finds its way into supply chains anyway, through relabeling and FCC-certified modular components, before turning to mandatory product activation in consumer devices like drones and 3D printers, and what it actually takes to use them without phoning home.
The deeper problem is that small businesses and infrastructure operators are genuinely dependent on imported hardware because it works and it’s affordable. A significant amount of it runs on devices that connect to foreign entities by default, and there’s no clean domestic alternative.
Joe concludes that import bans don’t fix problems that exist equally in domestic products, and that trade policy is the wrong tool for what is fundamentally a consumer safety problem. His preferred alternatives are right to repair with offline use guarantees, hardware and firmware bills of materials, and comprehensive privacy legislation.
This talk is essential viewing for security practitioners concerned about hardware supply chain risks, the unexpected connectivity of critical infrastructure, or the US’s deep dependence on foreign-manufactured consumer electronics.
About the Author
Joe FitzPatrick (@securelyfitz) is an Instructor and Researcher at SecuringHardware.com. Joe has spent most of his career working on low-level silicon debug, security validation, and penetration testing of CPUs, SoCs, and microcontrollers. He has spent the past decade developing and delivering hardware security related tools and training, instructing hundreds of security researchers, pen testers, and hardware validators worldwide. When not teaching Applied Physical Attacks training, Joe is busy developing new course content or working on contributions to the NSA Playset and other misdirected hardware projects, which he regularly presents at all sorts of fun conferences.
LABScon is a unique venue for original research to be shared among peers. The benefit of an invite-only audience of researchers is that there’s no need for long preambles or introductions – speakers are encouraged to dive right into their technical findings.
Original content only.
Talks are 20 minutes long + 5 minutes for Q&A.
Workshops are 90 minutes long.
LABScon is primarily a threat intelligence and vulnerability research conference but we keep an open-mind.
About LABScon
This presentation was featured live at LABScon 2025, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLABS.
The video platform Vimeo confirmed a security breach via Anodot that exposed metadata, video titles, and some user emails.
Vimeo said some user data was accessed after a breach at Anodot. Anodot is a company that provides AI-driven data analytics and anomaly detection tools.
Most of the exposed information includes technical data, video titles, and metadata, while some customer email addresses were also affected. Vimeo says the incident did not expose user-uploaded videos, login credentials, or payment card data, and its platform continues to operate normally without disruption.
Vimeo noted the incident came from a third-party breach.
“Vimeo is aware of a security incident affecting Anodot, a third-party analytics vendor used by Vimeo and many other companies.” reads the notice published by Vimeo. “We have identified that, as a result of the Anodot breach, an unauthorized actor accessed certain Vimeo user and customer data. Our initial findings suggest that the databases accessed primarily contain technical data, video titles and metadata, and, in some cases, customer email addresses.”
In response to the incident, the company disabled all Anodot credentials and removed its integration with the service to stop further access. Vimeo notified law enforcement and is still investigating the incident with the help of external security experts.
Hackers from the extortion group ShinyHunters claimed the Vimeo breach and threaten to leak stolen data by April 30 if the company refuses to pay a ransom. They also warn Vimeo about possible “digital problems” if demands go unmet.
“Your Snowflake and Bigqueryinstances data was compromised thanks to Anodot.com. Pay or Leak.” reads the announcement published by ShinyHunters on its Tor data leak site. “This is a final warning to reach out by 30 Apr 2026 before we leak along with several annoying (digital) problems that’ll come your way. Make the right decision, don’t be the next headline.”
The attackers say they accessed data from Vimeo’s Snowflake and BigQuery environments. They also list the company on their leak site as part of their pressure campaign against the organization.
Attackers linked to the ShinyHunters group stole authentication tokens from Anodot and used them to access customer cloud environments, mainly Snowflake, to extract data from several organizations. The group now tries to monetize the breach through extortion and leak threats.
They also claim they took more than 78.6 million records from game studio Rockstar Games, though they have not confirmed the exact amount of data taken from Vimeo.
Security experts have found a high-severity flaw named Pack2TheRoot in PackageKit that allows hackers to gain full root access on multiple Linux distributions.
AI agents may soon be buying your stuff for you. The FIDO Alliance has teamed up with Google and Mastercard to try to ensure that shopping in the near future isn't a complete disaster.
‘Pack2TheRoot’ flaw lets local Linux users gain root via PackageKit. CVE-2026-41651 (8.8) has existed for nearly 12 years.
The Pack2TheRoot flaw, tracked as CVE-2026-41651, lets unprivileged users install or remove system packages without authorization, potentially gaining full root access.
The vulnerability is rated high severity, CVSS score of 8.8, and has existed for nearly 12 years.
Discovered by Deutsche Telekom’s Red Team, it stems from PackageKit allowing commands like “pkcon install” to run without a password on some systems. Researchers used AI (Claude Opus) to explore the issue, confirmed it manually, and responsibly disclosed it to maintainers, who validated the flaw.
“Today we publicly disclose a high-severity vulnerability (CVSS 3.1: 8.8) – in coordination with distro maintainers – that affects multiple Linux distributions in their default installations. The Pack2TheRoot vulnerability can be exploited by any local unprivileged user to obtain root access on a vulnerable system.” reads the advisory published by Deutsche Telekom. “The vulnerability lies in the PackageKit daemon, a cross-distro package management abstraction layer.
Details of the Pack2TheRoot flaw were disclosed alongside a fix in PackageKit 1.3.5, though exploit code was withheld to allow patching. Deutsche Telekom researchers found that PackageKit could run commands like “pkcon install” without authentication in some cases on Fedora, enabling package installation. The researchers used the Claude Opus AI tool to explore this behavior further and identified the vulnerability as CVE-2026-41651.
All PackageKit versions from 1.0.2 to 1.3.4 are vulnerable, affecting many Linux distributions for over 12 years. Tested systems include Ubuntu, Debian, Fedora, and Rocky Linux, and others using PackageKit may also be at risk, including servers with Cockpit. The issue is fixed in version 1.3.5, with patches released on April 22, 2026.
Technical details of the vulnerability are not yet disclosed and will be shared later. Researchers have developed a reliable proof-of-concept that allows an unprivileged local user to gain root code execution on default Linux systems. However, the PoC code has not been released publicly to prevent abuse while patches are being deployed.
To check if you’re vulnerable, verify if PackageKit is installed using dpkg or rpm, as it may run on demand via D-Bus. Then check if the service is active with systemctl or monitoring tools like pkmon/pkgcli. If active and unpatched, your system may be at risk. Although fixed in version 1.3.5, many distributions have released patched versions separately, so updating via your distro is essential.
You can use the following commands to check whether a vulnerable version of PackageKit is installed on your system:
To verify if the PackageKit daemon is active, run systemctl status packagekit or pkmon. If the service is loaded or running, your system may be at risk if it has not been patched.
Researchers released Indicators of compromise (IOCs) for this flaw.
As these systems move from "pilot" to "permanent," are you more concerned about the erosion of the physician-patient relationship or the potential for hidden economic "steering" within the algorithms?
Entrar
