Cybercriminals frequently deploy Linux ransomware in server environments, targeting organizations with critical data for potentially higher payouts. Cado Security Labs’ cybersecurity analysts recently examined the Linux version of Cerber ransomware, exploiting Confluence servers through CVE-2023-22518, following recent reports.
Unlike its well-documented Windows counterpart, the Linux variant remains largely mysterious. Comprising three heavily obfuscated, 64-bit UPX-packed C++ ELF payloads, it employs an older technique, contrasting with modern trends favoring languages like Rust or Go among threat actors.
Cerber Linux Ransomware
Despite being almost 8 years old and receiving updates, the aging C++ payloads indicate that Cerber’s original language and tooling choices persist, even as its activity has declined since its peak in 2016.
Although less common now, the campaign still exploits the widely-used Confluence vulnerability for distribution. Researchers have observed Cerber ransomware instances on compromised Confluence servers following the attacker’s use of CVE-2023-22518.
This new flaw, exploiting an unsecured configuration restore endpoint, allows threat actors to create a new administrator account, facilitating code execution and ransomware deployment.
The ransomware poses a significant risk due to its broad encryption capability when granted higher privilege access. By default, it encrypts crucial data but is limited to files owned by the “confluence” user.
Multiple Payloads
There are three payloads, listed below:
Primary Payload
The main Cerber payload is a heavily obfuscated, UPX-packed C++ stager that communicates with 45.145.6.112 to fetch additional components.
It generates a lock file at /var/lock/0init-ld.lo, retrieves a “log checker” (agttydck) to /tmp/agttydck.bat, executes it with arguments /tmp and ck.log, and then downloads and deploys the encrypted encryptor (agttydcb) to /tmp/agttydcb.bat.
Once agttydck completes its task, the stager deletes itself if /tmp/ck.log exists.
The stager decodes agttydcb and saves it as an ELF executable on disk, while it remains active in memory.
Its primary role is to prepare the environment for the more potent encryptor payload.
Log Check Payload – Agttydck
The agttydck payload, a highly obfuscated, UPX-packed C++ “log checker,” aims to write “success” to a file path constructed from its arguments (e.g., /tmp/ck.log). Its return code indicates the success or failure of the write operation.
This likely assesses file write permissions to gauge if the system allows proper functioning of the encryptor. Running separately from the stager, it may also attempt to detect sandboxes with faulty file handling, preventing the stager from detecting the log file creation.
In essence, agttydck acts as a simple permission and potential sandbox-checking mechanism before deploying the final encrypted payload.
Encryptor – Agttydck
The core agttydcb encryptor, a heavily UPX-packed C++ payload, self-deletes after creating potential debugging log files (/tmp/log.0 and /tmp/log.1).
It spawns an encryption thread that traverses the root directory to drop ransom notes at writable directories before opening, reading, encrypting in memory, and overwriting each file’s contents with the encrypted data plus a .L0CK3D extension.
Cerber, though aging, remains sophisticated, exploiting Confluence vulnerability to access valuable systems, yet typically encrypts only Confluence data.
Leave A Comment