A Russia-aligned hacking group that researchers had not previously named or documented has been running a systematic intelligence campaign against Ukrainian institutions since at least February 2025, targeting courts, prosecutors, local government bodies, and a major foreign military aid hub, according to a report published Tuesday by cybersecurity firm ESET.
The group, which ESET has labeled Gorbag, operates with a focused mandate: collect documents and credentials that give Russian intelligence visibility into how Ukraine is tracking war crimes, where foreign weapons are arriving, and how effectively Russian strikes are degrading infrastructure near the front lines. ESET said the group "demonstrates precise targeting and operational intent to contribute to Russia's broader strategic goals in the war with Ukraine."
About a quarter of Gorbag's known targets are law enforcement and judicial institutions. ESET researchers say this pattern points to Russian efforts to monitor ongoing war crimes investigations, including which soldiers and officers have been identified, what evidence has been gathered, and which individuals face prosecution. Courts and prosecutors hold precisely that case material, and the Kremlin would have an obvious interest in knowing what investigators know.
Another quarter of the group's victims are local government bodies, concentrated among city councils operating near active fighting. These are not high-profile targets on their own, but they hold something specific: internal damage assessments from Russian airstrikes, including infrastructure repair estimates that have never been publicly released. For Russian military planners evaluating whether strikes are achieving their intended effect, that internal accounting is far more useful than what appears in news reports.
ESET also identified a major transportation hub for foreign military aid as a Gorbag target, one that had been previously struck in Russian airstrikes. Its inclusion in the campaign fits a third intelligence priority the firm attributes to the group: tracking inbound weapons deliveries and mapping the logistics infrastructure that moves military equipment into Ukraine from abroad.
Getting in through the mailbox
Gorbag's entry method is phishing, specifically emails carrying malicious attachments formatted to look like official correspondence about administrative penalties or outstanding taxes. The choice of lure is deliberate. Administrative staff in Ukrainian municipal offices process exactly these kinds of documents, and a notice framed as an overdue government fine is designed to generate urgency without triggering immediate suspicion.
Once a machine is compromised, Gorbag deploys a custom info-stealer ESET calls BeautyStealer. The tool searches the infected computer, removable drives, and connected network shares for files of value, then attempts to erase itself after sending the data out, limiting what forensic investigators would find. The group also uses a remote access tool called Prime ReverseShell, built on publicly available code, that allows operators to issue commands to a compromised machine directly.
What BeautyStealer collects is a combination of credentials and documents. Saved browser passwords, authentication cookies, VPN configuration files, Microsoft Office documents, email archives, and compressed files all fall within scope. That mixture is significant: credentials open doors to systems the attacker has not yet reached, while the documents provide the raw intelligence. ESET notes Gorbag may pass stolen credentials to separate groups for follow-on intrusions, though this relationship has not been confirmed.
An old flaw put to new use
Starting in early 2026, Gorbag added another technique. The group began exploiting CVE-2025-8088, a path traversal vulnerability in WinRAR that lets an attacker write files outside an intended extraction folder by abusing NTFS Alternate Data Streams. The flaw was patched in July 2025, but systems running older versions remained open. WinRAR is used extensively across Ukrainian organizations, making it a consistent point of interest for Russia-aligned actors. RomCom, another Russian-linked group, had exploited the same vulnerability before Gorbag adopted it.
"As long as the war in Ukraine continues, we expect groups such as Gorbag to remain a persistent threat to Ukrainian government, justice, and defense entities." [ESET researchers]
ESET characterizes Gorbag as less technically sophisticated than elite Russian state hacking units. The group shows little interest in deep persistence or careful lateral movement through networks over time. Its posture is transactional: access a machine, harvest whatever is reachable, and exit. That approach may reflect a division of labor inside Russia's intelligence apparatus, where collection-focused units gather raw material and pass it upstream to actors with more specialized capabilities.
The targeting reinforces that reading. Gorbag is not hitting central government ministries or high-value military command networks in Kyiv. It is operating at the administrative layer of a country at war, the city councils, the courts, the logistics checkpoints, the bureaucratic infrastructure that underpins both civilian governance and military operations near the contact line. That is exactly where granular, operational intelligence lives, and exactly where it is least expected to be a target.
The operation has been linked to APT29, a cyberespionage group associated with Russia's Foreign Intelligence Service (SVR). According to cybersecurity researchers, the attackers abused a third-party web analytics service to reach visitors of legitimate websites without requiring them to download suspicious applications or files.
According to Sekoia researchers Amaury-Jacques Garçon and Félix Aime, the campaign relied on three main methods to infect devices. These included compromising legitimate websites, creating fake websites that impersonated well-known organisations, and conducting a supply-chain attack against Plerdy SEO Tracker.
The supply-chain compromise took place between August 27 and September 3, 2026. During this period, attackers injected malicious code into the JavaScript file hosted on Plerdy's infrastructure. Since the analytics script was used by thousands of websites, the compromise potentially exposed a large number of visitors to the malicious code.
The researchers discovered that the attackers also created lookalike websites impersonating organisations in the United States, Ukraine, the Czech Republic and Bulgaria. Some compromised websites were associated with the chemical industry, political organisations and military-related activities.
Once the malicious JavaScript executes, it collects information about the visitor's browser, operating system and device configuration.
For Apple devices, the attackers used the DarkSword exploit kit to target vulnerable iOS versions. Depending on the device, the malware could steal Safari cookies or extract more extensive information, including text messages, WhatsApp and Telegram databases, contacts, call history, photographs, Wi-Fi passwords and iCloud Keychain data.
Android users were targeted through a separate malware payload called AndroSnitch. The attack exploited vulnerabilities in Google Chrome to gain access to the device and collect browser information, including cookies, saved login details and Wi-Fi passwords.
Researchers identified several security vulnerabilities used in the campaign, including CVE-2025-43529, CVE-2026-20700 and CVE-2026-3910. These vulnerabilities allowed attackers to execute malicious code and bypass security protections on vulnerable devices.
Sekoia said the campaign appeared to focus on websites likely to attract strategically important visitors, particularly those connected to military organisations and defence-related industries.
A cyberattack targeting OPSSHIELD's software distribution infrastructure allowed an unidentified attacker to compromise cPGuard updates and deploy a malicious script across customers' Linux servers, harvesting password hashes, SSH keys, database credentials, and other sensitive information.
The incident began on November 2, 2026, when the attacker exploited compromised credentials to access OPSSHIELD's update distribution infrastructure. According to the company's investigation, approximately 2,950 customer servers executed the malicious update, while nearly 7,900 billing portal account records were also exposed.
cPGuard, OPSSHIELD's Linux server security solution, provides malware scanning, firewall management, and attack protection for web hosting environments, including servers running cPanel, DirectAdmin, and Plesk.
Compromised Update Infrastructure Delivered Malicious Script
OPSSHIELD's investigation traced the intrusion to its billing and licensing application. The attacker initially registered a customer account under a false identity on November 1 and requested a free cPGuard trial to examine communications between the software and its licensing infrastructure.
After probing the billing portal and submitting specially crafted requests, the attacker obtained command execution on the company's billing and licensing server. This access enabled the theft of credentials used to distribute software updates.
Between 02:04 and 02:09 UTC on November 2, the attacker uploaded a malicious update using a stolen access key. The compromised versions, ranging from 5.88.12 through 5.88.19, were distributed for approximately 70 minutes and executed with root privileges on servers checking for updates during that period.
OPSSHIELD detected the compromise within 12 hours and subsequently revoked the stolen update key.
Password Hashes and SSH Credentials Targeted
The malicious script collected sensitive system information and transferred it to OPSSHIELD's licensing infrastructure through a compromised account, allowing the attacker to retrieve the uploaded data.
The targeted files included "/etc/shadow" and "/etc/passwd", root's MariaDB/MySQL configuration ("my.cnf"), shell history, and SSH authorization and known-hosts files. The script also accessed root's SSH private keys and cloud storage credentials on some systems.
The "/etc/shadow" file contains password hashes rather than plaintext credentials. However, attackers can attempt offline password cracking against these hashes, particularly when passwords are weak, commonly used, or previously exposed. Database configurations and shell histories may contain credentials and API tokens that are immediately usable without requiring password cracking.
OPSSHIELD initially confirmed that attackers retrieved 32 collected files, each associated with a different customer server. Its subsequent disclosure estimated approximately 2,950 servers executed the malicious update.
The attackers also copied approximately 7,900 billing portal records containing customer names, company information, postal addresses, email addresses, and bcrypt-hashed passwords.
OPSSHIELD Releases Security Updates
The malicious script left several identifiable artifacts, including "cpguard-v58812-i91511.sh", a hidden root shell at "/var/tmp/.cpg91511_sh", and a collection directory at "/var/tmp/.cpg91511", containing the staged archive "loot.tgz".
OPSSHIELD's corrective updates remove the known backdoor and associated malicious files. However, removing these artifacts does not establish that a server was never compromised.
The company initially recommended updating to version 5.88.25 or later. Its subsequent disclosure identified version 5.88.26 as the clean release, which also addresses additional persistence mechanisms.
Administrators should run "cpgcli update --start" and verify the installed version using "cpgcli --version".
For potentially affected systems, OPSSHIELD recommends resetting local account passwords, rotating database credentials, S3 access keys, DigitalOcean tokens, and other exposed secrets. Administrators must also replace root SSH private keys and remove corresponding public keys from systems that previously trusted them.
Customers should additionally reset their OPSSHIELD billing portal passwords and enable two-factor authentication.
OPSSHIELD has also begun revoking its previously deployed support-access keys and rebuilding compromised internal infrastructure. Although the company initially did not recommend routine operating system reinstalls, its updated disclosure confirms that affected customer servers are being rebuilt where necessary.
According to Russia's Interior Ministry, the group has been active since at least 2016 and primarily targeted Russian companies through phishing campaigns. The attackers used fraudulent emails to steal login credentials, gain access to corporate networks and deploy malicious software on victims' systems.
The group operated an extensive network of phishing websites designed to impersonate financial institutions and accounting services. It also relied on servers hosted in foreign countries and purchased remote administration tools through dark web marketplaces. These tools allowed attackers to secretly access compromised computers and control them remotely.
One incident involved a company employee who received a phishing email in September 2025. The message appeared to come from a business partner and contained a malicious attachment disguised as a routine financial document. After the employee opened the attachment, the attackers allegedly gained remote access to the computer and the company's online banking system.
The cybercriminals transferred more than 660,000 rubles, approximately $8,000, from the company's bank account to accounts under their control, according to the Interior Ministry.
The investigation also revealed that the group's activities had expanded beyond Russia. In research published in November 2026, Kaspersky reported detecting more than 100 attempted attacks attributed to VasyGrek between January and September this year. The attacks targeted organisations in Russia, Belarus and Kazakhstan.
According to Kaspersky, the group primarily focused on metallurgical companies, wholesale suppliers of raw materials and industrial products, and government organisations. Other targeted sectors included healthcare, oil and gas, energy, finance and agriculture.
Kasppersky described VasyGrek as a financially motivated cybercrime operation that relied heavily on targeted phishing emails and malware capable of providing remote access to compromised systems.
After the investigation, Russian police searched the suspects' homes and offices, seizing computers, communication devices and other materials believed to be connected to the group's activities.
The alleged leader of the group has been placed under house arrest, while two other suspects have been released under travel restrictions, according to Interior Ministry spokesperson Irina Volk.
The Russian Interior Ministry said the group's infrastructure had been dismantled. However, it remains unclear whether the arrests will completely stop its operations or prevent other members from continuing similar attacks.
A ransomware strain called C3RB3R is actively hitting Synology network-attached storage devices, locking files and demanding bitcoin payments from victims who, in many cases, were running software patched nearly two years ago.
Synology confirmed the attacks on October 29, pointing to CVE-2024-10441, a critical remote code execution flaw in its DiskStation Manager operating system rated 9.8 out of 10 on the CVSS scale. The vulnerability was found at Pwn2Own 2024 by DEVCORE researchers Pumpkin Chang and Orange Tsai, and Synology patched it by December 2024 under security advisory SA-24:20. The patch has been available ever since. The fact that attackers are still finding success with it tells you something about how many users never applied it.
Once attackers get into a device, C3RB3R goes to work quickly. The ransomware skips 27 system directories and a handful of file types, then recursively encrypts everything else. Each file receives its own 256-bit encryption key generated on the fly, locked with ChaCha8 and then wrapped with RSA-2048, which means there is no way to crack it without the attacker's private key. The malware drops a ransom note called read-me3.txt into every affected folder, containing a six-digit victim ID and a Tor address. Files come out the other side with a .L0CK3D extension. Backups stored on the same NAS are not spared.
The ransom demand starts at 0.036960 bitcoin, which works out to roughly $2,952 at current rates. Victims who miss the five-day deadline see that figure double to 0.073920 BTC, or about $5,904. No free decryptor exists, and Synology has offered none. Affected users who do not have off-site backups are, for practical purposes, out of options.
Reports first surfaced in South Korea around October 28. Victims filed complaints with KISA, the country's internet security agency, but KISA declined to say how many devices were affected, what caused the intrusions, or what it was doing about them. Synology has similarly not disclosed how many users were hit, which device models were targeted, or when it first became aware of the campaign. A Taiwanese NAS research group that compiled damage cases found a common thread: in every instance they reviewed, the device's management interface was reachable directly from the internet, whether through router port forwarding, UPnP, QuickConnect, or a reverse proxy.
The attack timing is not coincidental. On October 25, four days before Synology issued its statement, a public proof-of-concept exploit for CVE-2024-10441 appeared on GitHub. That kind of public PoC typically compresses the window between disclosure and active exploitation to days, sometimes hours. Security researchers at 360 Security Team and Solar Emergency Response Team, who both published analysis on October 29, noted that the campaign appears to have kicked into gear almost immediately after the PoC dropped.
There is, however, a complication in Synology's explanation. The Solar team examined one affected device running DSM 7.4.1-90080 Update 1, a build that does not fit neatly into the SA-24:20 vulnerability timeline. The researchers have not ruled out other entry points, including vulnerable third-party packages, container services, or stolen credentials. No zero-day has been confirmed, but the mismatch has not been fully explained either.
Adding another layer, the 360 Security Team's analysis points to a different set of flaws entirely: CVE-2026-13639 and CVE-2026-13684, both scored 9.8, patched by Synology on September 18, 2026. Under 360's reading, these are "1-day" exploits built on patches that were barely a month old when the attacks began. If 360 is right, devices that only applied the 2024 patch would still be exposed.
Separately, Synology disclosed two more critical vulnerabilities in its PHP infrastructure, CVE-2026-109618 and CVE-2026-109619, affecting packages including Web Station, WordPress, Joomla, and phpMyAdmin. Synology says these flaws are not the C3RB3R entry point, but has advised users to patch them regardless. Security firm Genians found that 96 percent of internal-network devices running PHP were exposed.
Synology's guidance for users is practical if grim for those already affected. The company recommends running a Security Advisor scan, checking Task Scheduler for unfamiliar scripts, and reviewing User and Group settings for administrator accounts that were not created by the device owner. If either check turns up something unexpected, Synology says to contact its support team rather than attempt a manual cleanup. For everyone else, the advice is to update DSM immediately, enable automatic updates, and move backup jobs off-device using Hyper Backup or Snapshot Replication.
The patches for SA-24:20 are in DSM 7.2.1-69057-6, 7.2.2-72806-1, 7.2-64570-4, 7.1.1-42962-7, and 6.2.4-25556-8. Synology PSIRT says it continues to monitor the campaign.
Through Microsoft Teams, cybercriminals are impersonating IT support personnel in order to gain access to corporate systems and exploit vulnerabilities in Active Directory Certificate Services (AD CS).
The attacks targeted a maximum-severity vulnerability tracked as CVE-2026-97229, which carries a CVSS score of 10.0. Although Alpine Linux found no evidence that the attackers successfully executed malicious code or modified its software packages, the project said it could not completely rule out a breach.
Alpine Linux is a lightweight, open-source operating system widely used as the foundation for Docker container images. Its GitLab server hosts development repositories, code reviews and continuous integration (CI) jobs, including the build recipes used to produce Alpine software packages. This makes the server an important target for attackers seeking to compromise the software supply chain.
The vulnerability is caused by an integer overflow in Onigmo, the regular expression engine included in Ruby and used by GitLab's CI/CD system. If successful, this could allow the attacker to execute arbitrary code on the vulnerable server.
GitLab disclosed the vulnerability and released security fixes on October 12. However, Alpine Linux initially installed GitLab version 19.3.4 instead of the patched 19.3.5. The project later upgraded to version 19.3.6 on October 22, but the vulnerability remained because the required Ruby security patch was missing from Alpine's custom container image.
According to Alpine Linux, an attacker created a new account and began submitting specially crafted CI configurations to its GitLab server on October 20-21.
The security team recorded eight worker crashes during the attacks. Four attempts reportedly progressed partway through the exploitation process before failing to complete.
The attackers also downloaded Alpine Linux's GitLab container image, suggesting they may have been studying the server's configuration and preparing an exploit specifically designed for that environment.
The project later discovered that upgrading GitLab alone was insufficient to address the problem. The security fix required an updated version of Ruby, which was included in GitLab's official packages but was not present in Alpine's custom image.
There were doubts about a possible software supply-chain attack. If attackers had successfully compromised the GitLab server, they could potentially have accessed user information, password hashes, two-factor authentication secrets, CI/CD credentials, integration tokens and private project repositories.
The project also advised users to change passwords reused on other websites and to pull the updated alpinelinux/gitlab:19.3.6 container image published on October 27. This image includes Ruby 3.3.13, which contains the necessary security fix.
Drupal has confirmed active exploitation of a highly critical access bypass vulnerability in its Commerce Core module, warning online retailers that attackers could manipulate orders and circumvent payment processes. The company has urged administrators to install the latest security updates and investigate existing transactions for unauthorized modifications.
Tracked as CVE-2026-118539, the vulnerability affects Drupal Commerce Core, a contributed module that enables websites to sell products and services through shopping carts, checkout systems and payment integrations. It also supports headless commerce architectures, where external applications interact with Drupal through APIs.
According to the original security advisory, certain application routes and entity fields do not have sufficient access restrictions, allowing unauthorized users to bypass established permission checks. This could enable attackers to manipulate commerce-related information, potentially causing direct financial losses for merchants.
Published on October 28 under advisory SA-CONTRIB-2026-254, the vulnerability received a Drupal security risk score of 21 out of 25, placing it in the highly critical category. Its assessment identifies the flaw as exploitable without authentication or special access requirements, regardless of the module's configuration.
Drupal has confirmed that the vulnerability is being actively exploited in the wild. However, its initial advisory did not disclose the attack methodology, affected organizations or the number of compromised websites.
Fraudulent Order Attempts Reported on Live Websites
Additional information published on October 29 by Centarro, the maintainer of Drupal Commerce, provides further insight into the exploitation activity.
According to Centarro, it received two reports from merchants who observed suspicious attempts to place fraudulent orders on their live websites. Following an investigation conducted alongside the Drupal Security Team, the maintainers stated that they had not found evidence of scripted or widespread exploitation beyond the initially reported sites.
The vulnerability affects both traditional, full-stack Drupal Commerce installations and headless deployments, although the potential attack paths differ depending on the website's architecture.
Centarro identified several suspicious transaction patterns that administrators should investigate. These include orders placed without corresponding payments, transactions marked as paid despite having no associated payment records, product prices modified without legitimate promotions, and unauthorized discounts, fees or other adjustments applied to orders.
Some reported attempts involved products listed at unusually low prices, including $0.01, while others used apparently normal prices to make fraudulent transactions less conspicuous.
The maintainers also warned that the vulnerability may have existed in earlier Commerce Core releases for several years. Exploitation was theoretically possible from version 8.x-2.18, released in May 2020, on installations using Drupal's JSON:API module. Other configurations became potentially vulnerable from version 8.x-2.25, released in June 2021.
Consequently, organizations should not restrict their investigation to transactions created shortly before the October security disclosure.
Security Updates and Additional Commerce Vulnerabilities
Drupal has released Commerce Core 3.3.13 and 8.x-2.41 to address CVE-2026-118539. Administrators running the 3.x branch should upgrade to version 3.3.13, while installations using the earlier 8.x-2.x branch should move to 8.x-2.41.
Centarro has also recommended updating the associated Commerce API, Commerce License, Commerce Shipping and Commerce Stripe modules, which received separate security releases. Websites that do not require write operations through JSON:API should consider restricting the interface to read-only access.
The October 28 security releases addressed several additional vulnerabilities across Drupal's contributed projects.
Among them, CVE-2026-118558 affects Commerce Stripe through a cross-site request forgery (CSRF) vulnerability. The module does not include a CSRF token in the return URI used during Stripe Connect authorization. An attacker could exploit this weakness by tricking an administrator into following a malicious link, potentially causing an order to be marked as paid without an actual payment.
Another issue, CVE-2026-118582, affects the CAPTCHA module. The vulnerability results from inadequate invalidation of previously solved CAPTCHA sessions, allowing an already-submitted protected form to be submitted again without completing another challenge. This could weaken protections against automated registrations, comment spam and login brute-force attempts. Drupal's advisory indicates that exploit code exists, although it does not confirm active exploitation.
Drupal also disclosed information disclosure vulnerabilities in Commerce Core and Media Alias Display. The former can expose information about unpublished product variations under certain JSON:API configurations, while the latter involves improperly configured caching that could expose files containing information intended to remain inaccessible.
Earlier Critical Drupal Vulnerabilities
The October disclosures follow another security release on October 14, when Drupal addressed two critical remote code execution vulnerabilities.
CVE-2026-108097 affects the Field UI module in Drupal Core, while CVE-2026-108099 impacts the contributed Entity List module. Although neither component independently exposes the vulnerabilities through its default functionality, certain contributed modules and custom implementations can introduce exploitable pathways. Drupal identified at least one potential attack path that does not require authentication.
Another vulnerability, CVE-2026-9082, involved SQL injection in Drupal Core's database abstraction API, affecting websites using PostgreSQL databases. The flaw could allow unauthenticated attackers to execute specially crafted database queries, potentially resulting in information disclosure, privilege escalation or remote code execution. The vulnerability was added to the US Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog in May 2026 following confirmed exploitation.
With CVE-2026-118539 now confirmed under active exploitation, administrators should prioritize security updates, examine historical order records and verify that payment confirmations correspond to actual transactions before fulfilling orders. Centarro has also recommended comparing suspicious transactions against website access logs to establish whether they originated through legitimate checkout processes.