An investigation of three compromised servers uncovered an image-based malware loader, a custom Python implant and tools that could expose backup credentials.
Attackers who exploited vulnerabilities in AhsayCBS, a backup management platform used by managed service providers (MSPs) and system integrators, planted five families of webshells, deployed multiple cryptominers and installed a custom malware implant, according to a follow-up investigation by cybersecurity firm Huntress.
The investigation found that the attackers went beyond the cryptomining activity identified in an earlier report, leaving behind several mechanisms to maintain access to compromised systems. Some of the tools could also enable remote command execution and file transfers, while activity on a related Veeam server suggested that the attackers were interested in obtaining credentials used by backup infrastructure.
Huntress examined three AhsayCBS servers belonging to a single environment that were compromised between October 8 and October 11, 2026. The intrusions involved two vulnerabilities, CVE-2026-105133, an authentication bypass, and CVE-2026-105134, an unauthenticated remote code execution flaw that could allow attackers to execute commands with SYSTEM privileges.
The vulnerabilities were disclosed in early October. Huntress first reported their exploitation on October 8, describing how attackers chained the flaws to gain access to exposed AhsayCBS servers, install Java Server Pages (JSP) webshells and deploy XMRig cryptominers.
Ahsay subsequently released hotfixes addressing the vulnerabilities. Huntress said it verified that version 10.3.4.45 blocks the initial entry point used in the observed attack chain. However, the fixes do not remove malicious files or other mechanisms that attackers may have installed before systems were patched.
Image files used to conceal malicious code
One of the more unusual findings involved a JSP webshell named AhsayCBS.jsp, which was designed to resemble an internal image-preview service.
Rather than exposing its functionality through conventional command parameters, the webshell extracted encrypted code concealed within the pixel data of uploaded PNG images. It then decrypted the payload and executed it in memory.
The mechanism reads the least significant bits of the red, green and blue values of individual image pixels, reconstructing encrypted data that is subsequently decrypted using AES. The resulting Java class is loaded into memory and executed without requiring the attacker to leave the payload as a conventional executable file on disk.
The webshell also returned image responses, making its activity resemble ordinary image-preview requests in access logs.
Huntress said it analyzed the loader but could not establish what code the attackers actually executed through it.
Another webshell, nsmind.jsp, functioned as a remote administration interface. It used an API key and HMAC-SHA256 request signatures, along with timestamps and nonces, to authenticate requests.
Behind this authentication mechanism, the webshell supported four actions: command execution, directory navigation, file uploads and downloads.
Its file-transfer functionality could move data in chunks, supporting files as large as 4GB. This could provide attackers with a mechanism to extract large files from compromised servers.
Huntress did not find evidence that the download functionality had been used, however, and could not establish whether any data had been stolen.
Custom implant and multiple persistence mechanisms
The investigation also uncovered a Python-based implant that launched an embedded Windows DLL directly in memory.
The implant used a host-specific mechanism to determine whether it was running on the machine for which it had been deployed. It calculated the SHA-256 hash of the system’s MachineGuid and checked for a marker file bearing that hash. If the file was missing, the script exited.
This could prevent the malware from running in a sandbox or on a researcher’s machine, making analysis more difficult.
If the marker was present, the Python loader allocated executable memory, copied an embedded payload into it and started a new thread to execute the code. The payload contained an x64 DLL that communicated with a command-and-control (C2) server.
Huntress identified a C2 address embedded in the DLL but said it had not identified the malware family or observed the implant executing. Its functionality after connecting to the server therefore remains unknown.
The attackers also deployed a second XMRig cryptominer, separate from the one identified in Huntress’s original investigation. A scheduled task named kvm, running with SYSTEM privileges, checked every minute whether the miner was active and restarted it if necessary.
Other tools found on the servers included the tunnelling utilities Gost and Chisel, remote access software such as AnyDesk, Atera and Splashtop, and a Mimikatz package. The attackers also configured broad exclusions in Microsoft Defender, reducing the security software’s ability to scan several system directories and processes associated with AhsayCBS.
Backup credentials raise further concerns
The findings also point to a possible attempt to access credentials associated with backup infrastructure.
On a related Veeam server in the same environment, Huntress found a command consistent with NetExec’s Veeam credential-theft module. The activity involved querying Veeam’s PostgreSQL database for stored credentials and attempting to decrypt them using Windows Data Protection API (DPAPI).
Backup software can store credentials used to access hypervisors, backup repositories and domain accounts. Compromising these credentials could give attackers additional opportunities to access systems and data beyond the initially compromised server.
Huntress could not establish how many credentials, if any, were successfully retrieved. However, the combination of the AhsayCBS compromise and the Veeam credential-query activity suggested that the attackers may have deliberately targeted backup infrastructure.
For organizations running AhsayCBS, applying the vendor’s hotfixes is only the first step. Huntress recommends investigating servers that were exposed before patching for unexpected JSP files, scheduled tasks, unfamiliar services, suspicious Microsoft Defender exclusions and embedded Python installations.
Where signs of compromise are found, the company recommends rebuilding affected servers from trusted backups and rotating credentials stored on or accessible from those systems, including credentials used by other backup software on the network.
