Unpacking Diicot - Evolving Campaign Targeting Linux Environments

Wiz Threat Research uncovered a new malware campaign targeting Linux environments attributed to the Diicot threat group.

During a recent threat hunting effort Wiz Research uncovered a new malware campaign that we attribute to the Romanian-speakingDiicot threat group.

This campaign targets Linux systems and showcases significant advancements compared to previous iterations. We have seen evidence of this new malware, as well as earlier versions of it, in several cloud environments, indicating a widespread campaign targeting various sectors.

While Diicot has been previously documented in reports byCado Security,Akamai, andBitdefender, the malware we analyzed includes notable improvements that reflect a deeper level of sophistication. These refinements suggest the attackers are actively learning from prior research and adapting their techniques to counter modern security measures.

In this blog, we’ll walk you through our findings, detailing the capabilities of this updated malware, its methods of operation, and its potential impact.

The Diicot threat group (also known asMexals) is known for targeting Linux systems using techniques likeself-propagating tools,custom UPX packers, Internet scanning, and cryptomining malware likeXMRig. Previous reports from Cado Security, Akamai, and Bitdefender have highlighted their use of packed binaries, staged payloads, and frequent updates to avoid detection and maintain persistence.

In the malware samples we analyzed, we observed clear advancements compared to earlier versions. Specifically, we saw modified UPX headers with corrupted checksums that prevent standard unpacking tools from working out of the box. We also noticed more advanced payload staging and behavior tailored to the environment.

For example, if the malware detects that it is running within a cloud environment (as determined by the Linux distro and version), it prioritizes spreading itself to other hosts, whereas in a traditional (non-cloud) setup, it may focus on deploying cryptomining payloads instead. From our observations, the group appears to be closely following threat intelligence reporting about their activity, learning from them, and refining their tactics to adapt to modern defenses.

The key changes we observed in this version of the malware are listed below:

Infrastructure

New servers and domains for hosting payloads

Shift from Discord-based C2 to HTTP

New cryptocurrency wallets and mining pools

Use of Zephyr protocol for mining, in addition to Monero

Techniques

Shift from shc binaries to Go-based tools

UPX packer further modified to evade standard unpacking tools

Cloud-aware payloads

‘Update’ payload retooled as a central component, with expanded capabilities for spreading and persistency

As previously reported, we found clear signs linking the group to a Romanian speaking individual or group. For example, their code and file paths include Romanian words like afișează (“show”), așteaptă (“wait”), and brute-retea (“brute-force”).

The Diicot malware campaign targets Linux-based machines running OpenSSH, exploiting weak credentials to gain access. If your systems rely on SSH and aren’t properly secured, they could easily become targets for malicious activity and repurposed to further malicious actors’ goals.

Our investigation began with a file namedUpdateflagged by a YARA rule for UPX-packed files. The file showed up on cloud machines hosted on Azure, which ran OpenSSH along with a mix of other technologies.

We then found additional components of the malware on the machine, and categorized all the payloads as follows:

Internally calledbrute-spreader.go(based on compilation artifacts). We identified this file as the primary payload in this attack. It contains the main logic which includes spreading to other targets, maintaining persistence, and uploading results to the attacker’s server. During its execution it drops two additional embedded malicious files onto the system.

Also included in this payload is the “Cloud detection” logic, which is based on the remote machine’s Linux distribution and version. The payload contains a large, hardcoded list of distros that will only receive the spreading payload and not the full mining payload, for example:

4.15.0-1013-azure(Azure)

4.14.47-64.38.amzn2.x86_64(Amazon)

x86_64-linode105(Linode)

4.1.12-61.1.28.el7uek.x86_64(Oracle Cloud)

Internally calledclient.go, this file functions as a reverse shell, giving the attacker a direct remote connection to the compromised machine. Once active, it gives them full control over the system to run commands, manipulate files, or escalate privileges further.

This file is a scanner primarily designed for banner grabbing and identifying systems running OpenSSH. It downloads an IP list from hardcoded URLs, scans port 22 on the remote machines for SSH banners and looks specifically for responses indicating the presence of OpenSSH. We believe the machine we investigated had weak SSH credentials which the attackers abused as an initial access vector to the customer’s environment.

We theorize that this scanner was repurposed by the attackers and wasn’t developed by them, judging by the ‘first seen’ date on VirusTotal, which was much earlier than any other payload associated with this campaign, and by differing file properties compared to the other files.

Unlike the other payloads, this one was found during an investigation of the attacker’s servers. Specifically, the attacker’s C2 server had directory listing enabled which exposed several of the payloads including this one.

Internally calledpayload.go, we believe this is the campaign’s cryptomining payload for non-cloud environments.

It employs the same obfuscation methods as we saw in theUpdatepayload, but instead of just focusing on spreading to more machines, this payload also contains a cryptominer (a custom version of XMRig) with a built-in configuration.

abc123also contains a version ofUpdateas an embedded binary payload, using it to spread and infect more machines.

This payload also updates quite frequently. We saw new versions uploaded to the attackers’ servers multiple times throughout our investigation, most recently updating on 2024-12-05.

In this section, we’ll outline the various techniques employed by Diicot we’ve identified during our investigation, as summarized in the diagram below.

As noted in previous publications, such as by Cado Security, the Diicot group’s payloads use a slightly modified UPX packer that changes the magic header fromUPX!toYTS\x99(T1027.002).

In this iteration, this technique goes a step further by corrupting the checksum information in the headers. This prevents common UPX recovery tools, likeupx_decthat worked on previous versions, from successfully restoring the file. It’s a small change, but it’s clearly aimed at bypassing tools used in earlier analyses and avoiding detection by automated systems.

As can be seen below, when we first analyzed theUpdatefile, only 4 out of 66 VirusTotal engines flagged it as malicious, likely because of the modified UPX headers.

The attack also employed a reverse shell capability. This functionality is executed through thecachepayload. Once executed, the reverse shell connects back to the attacker’s command-and-control (C2) server and allows the attacker to execute arbitrary commands remotely on the infected machine.

The payload attempts to connect to the attacker-controlled domainpauza.digitaldatainsights[.]organd if that fails it connects to the hardcoded IP address:87.120.114[.]219.

TheUpdatefile maintains persistence by modifying the crontab to schedule recurring tasks (T1053.003).

Four different tasks are created:

Update- Re-runs the payload itself

History- Contains a simple bash script that checks if Update is running and runs it again if needed

.b- Contains a simple bash script that checks if cache (the reverse SSH client) is running and runs it again if needed.

.c- Downloads and runs a bash script from the urldigital.digitaldatainsights[.]org/.x/black3This task does nothing currently as the payload doesn't exist, but the newer version,black4, is stored on the server and will likely be included in a future update.

The malware communicates with a C2 server (T1071.001) multiple times during its runtime, sending two types of reports: error reports and information about successful brute-force attempts against other remote machines (T1041). In the samples we analyzed the C2 server’s address was87.120.116[.]35, but we believe the group updates this quite frequently (every few months)

These are generated by various parts of the code and contain a base64-encoded string detailing the specific error encountered. For example, note the following request:

This decodes to an error message (in Romanian) indicating failure to set up crontab jobs for persistence:

/root/skema/brute-spreader.go:218: E de la crontab uid0.

All error requests use Go’s default HTTP implementation, with a hardcoded User-Agent ofcurl/7.68.0, and are sent to the C2 server on port 1418 .

Sent after successfully brute-forcing a remote machine, these reports include:

The victim’s IP address, username, password, and SSH port

System information including CPU count, hostname, architecture, and kernel version

GPU availability (this was always set toNoin the sample we observed)

These reports are sent usingcurlwith the following headers, to the C2 server, using ports 47 or 8000 depending on the victim’s Linux distribution (cloud-associated distros report to port 47 and the rest report to 8000):

Another component of the malware is its SSH brute force functionality (T1110.001), which targets other systems with weak credentials. It starts by using thebisisbinary to scan a range of IP addresses to identify systems running SSH, it then tries to log in to the identified systems using the credentials from its large list of username and password combinations.

When a login is successful, it exfiltrates system details and deploys additional payloads to maintain persistence and enable further activity.

In the screenshot below we can see that the victim’s machine was flagged as a malicious SSH brute-forcer by GreyNoise on November 6th, which corresponds with the earliest modified time of malware samples on the infected machine we analyzed.

Although we didn’t observe any mining activity in the customer’s environment, we believe that this campaign does include crypto-jacking capabilities (T1496.001). Based on our analysis, theUpdatebinary checks system details such as uname and CPU information, adapting its behavior depending on whether it detects a cloud environment or a standard CPU. In cloud environments, it seems focused on spreading itself further.

However, in other cases, we suspect it may drop a cryptominer payload. This hypothesis is supported by findings on the attacker-controlled payloads server (http://80.76.51[.]5/.NzJjOTY) which contains an open directory, where we discovered the file namedabc123which contains references to mining pools. This, combined with the presence of XMRig-related configurations in other samples linked to this campaign, indicates that cryptojacking may be a key objective of the malware in non-cloud environments.

Bytracking the wallets linked to these pools, we found that the attackers have so far earned over $16,000 from Monero mining alone. We also suspect they’ve made significantly more using the Zephyr Protocol, but tracing those transactions is difficult because of its built-in privacy features.

Using Validin’s passive DNS data we can see the exact timeline of the group's activity using their new infrastructure. As seen in the screenshot below, the domains and IP addresses were first observed around October 12th, 2024, which closely corresponds with the earliest evidence we have of the latest wave of attacks.

By pivoting on the unique response hash returned by the payloads server (digital.digitaldatainsights[.]org), we managed to find an additional payload server (91.92.250[.]6) that we assess is also owned by the same group. This additional server was active between May 1, 2024, and September 26, 2024.

Switching to VirusTotal, we can see that the additional server served similar payloads to the newer one we described above. However, it also included some paths that we weren’t aware of previously. By accessing these paths on the newer server, we were able to download previously unknown payloads, which appear to be older iterations of the newer payloads we described above (we have included all of these in the IOCs table).

Wiz can help find and suggest remediation forall compute instances in your cloud environment with misconfigured SSH. This includes common pitfalls like weak credentials or allowing root SSH logins, both of which can lead to a compromise like in this case.

Wiz can help detect attacks like the one described in this blog in multiple ways:

The first is ouragentless malware detection, which detects these types of evolving threats using our proprietary YARA rules catalog.

The second is TheWiz Runtime Sensor, which detects events and behaviors associated with this threat and similar ones, alerting you on every step of the attack: from SSH brute-force attempts, reverse shell connections, modifications to crontab and ultimately cryptomining activity.

Wiz Threat Research investigates misconfigurations in Spring Boot Actuator’s endpoints that can leak environment variables, passwords, and API keys, and even lead to remote code execution.

Discover the latest in LLM hijacking activity, including a dive into the JINX-2401 campaign targeting AWS environments with IAM privilege escalation tactics.

AWS re:Invent 2024 brought an avalanche of announcements, with over 500 updates since November. Let's spotlight the most impactful ones for security teams, from Resource Control Policies to centrally managed root access.

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings