Eight Arms to Hold You: The Cuttlefish Malware
Executive Summary:
The Black Lotus Labs team at Lumen Technologies is tracking a malware platform we’ve named Cuttlefish, that targets networking equipment, specifically enterprise-grade small office/home office (SOHO) routers. This malware is modular, designed primarily to steal authentication material found in web requests that transit the router from the adjacent local area network (LAN). A secondary function gives it the capacity to perform both DNS and HTTP hijacking for connections to private IP space, associated with communications on an internal network. Cuttlefish also has the ability to interact with other devices on the LAN and move material or introduce new agents. Based upon code similarities in conjunction with embedded build paths, we have found overlap with a previously reported activity cluster called HiatusRat, whose targeting aligns with the interest of the People’s Republic of China. While there is code overlap between these two malware families, we have not observed shared victimology. We assess that these activity clusters are operating concurrently.
The Cuttlefish malware offers a zero-click approach to capturing data from users and devices behind the targeted network’s edge. Any data sent across network equipment infiltrated by this malware, is potentially exposed. What makes this malware family so insidious is the ability to perform HTTP and DNS hijacking for connections to private IP addresses. Cuttlefish lies in wait, passively sniffing packets, acting only when triggered by a predefined ruleset. The packet sniffer used by Cuttlefish was designed to acquire authentication material, with an emphasis on public cloud-based services. To exfiltrate data, the threat actor first creates either a proxy or VPN tunnel back through a compromised router, then uses stolen credentials to access targeted resources. By sending the request through the router, we suspect the actor can evade anomalous sign-in based analytics by using the stolen authentication credentials.
Our analysis suggests this malware has been active since at least July 27, 2023, however we found code references indicating there were previous iterations. This latest campaign ran from October 2023, through April 2024. The infection pattern was unique as 99% of infections occurred within Turkey, mainly stemming from two telecommunications providers. These two telecom firms accounted for roughly 93% percent of infections – 600 unique IP addresses. The handful of non-Turkish victims included IP addresses of likely clients associated with global satellite phone providers, and a potential US-based datacenter.
Introduction
Black Lotus Labs recently discovered a series of malicious files that triggered an investigation into an undocumented activity cluster targeting networking equipment. We are currently unable to determine the initial access vector; however, once exploited, the threat actor deploys a bash script that gathers certain host-based data to send to the C2. The bash script also downloads and executes Cuttlefish, a malicious binary compiled for all major architectures used by SOHO operating systems. This agent implements a multi-step process that begins with installing a packet filter for the inspection of all outbound connections and use of specific ports, protocols, and destination IP addresses. Cuttlefish constantly monitors all traffic through the device and only engages when it sees a particular set of activities. The rules of engagement are updated and specified in a configuration file sent by the C2 after it receives the host-based enumeration from the initial entry. The ruleset directs the malware to hijack traffic destined to a private IP address, and if heading to a public IP it will initiate a sniffer function to steal credentials if certain parameters are met.
- The initial hijack parameters are based on connections to a private IP address when the connection is on either UDP/Port 53 or TCP/Port 80. If the agent observes a DNS request to a private IP, it redirects the request to a DNS server in the configuration file. HTTP requests are purloined by inserting a 302-error code (or “resource temporarily redirected / unavailable”) into the data stream, allowing the connection to be redirected toward actor-controlled infrastructure. We suspect that could allow them to gain access to resources that were internal to a network, or not publicly accessible.
- Traffic to a public IP on a given set of ports and protocols will initiate a sniffer function. Cuttlefish will passively search for “credential markers” typically associated with authentication material in both GET and POST requests.
- If a web request hits on the specified port/protocol, is sent to a public IP, and carries credential markers; the malware logs that information on the infected device until the log file hits a certain file size limit. On reaching the defined limit, it sends the log file to the upload server.
Regardless of which path, following a successful intercept the threat actor creates either a VPN or proxy tunnel back into the compromised router, to presumably weaponize the stolen tokens and retrieve data hosted on cloud resources.
Figure 1: Flow diagram for packet filter and hijacking parameters
We assess that Cuttlefish represents the latest adaptation in networking equipment-based malware, as it combines multiple attributes. It has the ability to perform route manipulation, hijack connections, and employs passive sniffing capability. With the stolen key material, the actor not only retrieves cloud resources associated with the targeted entity but gains a foothold into that cloud ecosystem. We assess that while this most recent malware iteration went undetected for nine months and replaced a prior version called “.putin,” it had the potential for long-term persistent access.
Technical Details
Malicious Files – Bash Script
The deployed bash script begins to enumerate the device, looking for details such as the directory listing, the contents of /etc, running processes, active connections (via netstat), and the mounts. Once it has acquired this information along with the contents of “/etc/config,” it compresses all data and names the file “co.tmp.tar.gz.” This material is uploaded to the actor-controlled domain hxxps://kkthreas[.]com/upload. The domain in question was first registered on December 22, 2023, and resolved to IP address 198.98.56[.]93. One of the details that drew our suspicion was that this IP address hosted a self-signed X.509 certificate. This certificate’s common name was in a private IP address “192.168.10[.]39”, the certificate was first observed on July 23, 2023.
Following the upload of contents, the file is deleted from the infected device. The final command in the bash script, retrieves the trojan from the payload server located at hxxp://209.141.49[.]178/dajfdsfadsfa/{architecture}. This file is then hidden in the tmp directory and named “.timezone.” Appending the file with a “.” prefix enables the attacker to elude a simple “ls” search for files within that directory. Permissions are changed to allow the file to be executable by any user, and the file is then executed.
Once “timezone” is up and running in memory, it is deleted from the file system to hamper recovery efforts. While the primary file path was designed to grab an ARM-based payload, there are secondary file paths embedded that are designed to work on all the major router architectures; i386, i386_i686, i386_x64, mips32, mips64.
Figure 2: Depicting the network connections associated with Cuttlefish activity
Malicious Files – Primary Payload, Cuttlefish
When the file first executes it opens and binds to port 61235 on localhost to ensure only one instance is run. If the file detects that this port is being used by another process, it displays an error message “mutex fial!”[sic]. Once it establishes that there is only one instance running on the device, it then checks for command line arguments that were passed when the file was executed. When we analyzed one of the received bash scripts we observed the following syntax:
/tmp/.timezone -a -b 5000 -z -d
Our analysis of the malicious file identified the following prebuilt parameters, and their purposes were as follows:
- -a: auto selects the interface on the targeted router
- -b: defines the log file size
- -d: denoted whether or not to run as daemon
- -h: help
- -k: kill old agent
- -f: compress and send the specified file to the supplied upload file name
- -u: compress and send the specified file to the supplied upload URL
- -s: appoints the external interface for the sniffer function, this would be used in lieu of -a
- -t: timeout
- -i: identifies the internal IP addresses to hijack, this would be used in lieu of -a
- -v: verbose
- -z: defines whether to hide the process on the local file system.
We noticed that parameters, -k, -h, -v, -u, -f, appeared in the more recent version from late January, but not in the version from December 2023. The options -a and -z, warrant further discussion. If the -a option is supplied on the command line, the binary will collect the network interfaces and store them in two comma separated strings. IPs in the 127.0.0.0/8 range are ignored, internal IP ranges are stored in one variable (hijack), and external IPs are stored in another (filter and steal creds).
If the -z option is supplied, the sample hides itself by creating the hardcoded directory “/tmp/.Pg88s51gQG4tFyImFsT9qy6ZM5TeTF8.so” mounting to the current /proc/{PID}, and then deleting “/tmp/.Pg88s51gQG4tFyImFsT9qy6ZM5TeTF8.so” from the file system hampering recovery efforts of the file while keeping the malware in memory.
Next it sets up a logger to log output to the hardcoded location “/tmp/log.txt” and creates a uuid from the mac address of eth0, unless it uses the value “000000000000.” If it cannot locate “eth0” it will use the mac address of the first interface that is not ‘‘000000000000.” After converting the uuid from the mac address, it will check for the presence of the file “/tmp/.putin.” If this file exists, it will overwrite the uuid with the contents from the file. We suspect that this denotes that the file “.putin” was an earlier iteration of this malware.
Retrieval of RuleSets
The payload sets up a secure connection to the C2 using an embedded RSA certificate, to download and update the ruleset. It retrieves the policy using the following URL structure https://205.185.122[.]121:443/rules?uuid=UUID_CREATED_EARLIER
The payload then saves the output as /tmp/config.js. It will then parse the config JS file, updating “http_rule_hearttime”, “dns log status”, “script” and “http_rule_version.” If the http_rule_version is greater than the current rule version, it will update the HTTP rules. On one run, the “script” option contained a Base64-encoded script to download what appeared to be an updated version of the malware. The http_rule_hearttime defines an interval the malware should wait before reconnecting back to the C2, to see if there are new rules available.
Once it has the configuration file in place, the malware creates two threads. One thread keeps track of the heartbeat time to check for periodic module updates. The second thread monitors traffic moving across the selected interfaces specified via the command line, upon execution.
Figure 3: Functionality to use the embedded RSA certificate when making the request
Credential Harvesting Functionality
The sample uses libpcap to create an extended Berkeley Packet Filter (eBPF) for eavesdropping and hijacking IP ranges. The filter parameters can be broken down into two logical components, with the first part comparing outbound network traffic to a dictionary list of ports and protocols. If the connection hits one of the outbound network parameter combinations in the dictionary, the malware searches for certain credential “markers.” These credential markers contain a list of predefined strings, some of which appeared to be generic like “username,” “password” or “access_token,” while others were much more targeted like “aws_secret_key” and “cloudflare_auth_key.” Any traffic that matches both the network filters and markers is logged and sent to the C2; HTTP messages are Base64 encoded. A list of extracted credential markers, as well as the predefined ports/protocol list, can be found on our Github linked here. Many of the specific markers were associated with cloud-based services such as Alicloud, AWS, Digital Ocean, CloudFlare, and BitBucket. This caught our attention as many of these services would be used to store data otherwise found within the network. Capturing credentials in transit could allow the threat actors to copy data from cloud resources that do not have the same type of logging or controls in place as traditional network perimeters.
The one oddity in this process, is that while there were network rules for outbound TCP data transmitted via port 443 traffic, we did not see any embedded functionality to bypass or degrade network encryption such as TLS. So while much of the data may hit on one of the conditions, it is unclear how successful the packet filter’s functionality would be given the rapid adoption of TLS. We suspect that the actors likely had more success implementing the hijack functionality.
Logger and Data transmission Function
Once a log file of filtered traffic reaches the size supplied on the command line, or the maximum size set by the malware 0x100000 (1048576) bytes, Cuttlefish will gzip and then upload the file to the C2 using the previously computed uuid and a hardcoded value of “tid”:
hxxps://205.185.122[.]121:443/upload?uuid=%s&filename=%s&tid={hex value}
Hijack Functionality
The hijack functionality begins by downloading rules from the C2, then saving the file as “/tmp/thconfigjs” and parsing out the following fields:
- http_hijack_hearttime: beacon interval to check for update rules
- http_hijack_version: configuration version number
- http: hijack parameters for HTTP requests
- dns: hijack parameters to insert when the connection is hijacked
Once the malware executes it initiates two threads. The first thread monitors the http_hijack_hearttime interval to continuously check for updates, while the second thread monitors all network traffic traversing the router, waiting for the two conditions to be present that initiate the hijack. The first of these are connections to private IP addresses. A sample is shown below:
Figure 4: Comparing internal interfaces to a list of known private IP addresses
The second condition is met if it finds TCP connections to port 80 (both GET and POST messages) or outbound UDP-based connections to port 53, typically used for DNS. As for HTTP, it creates the hijack by taking advantage of HTTP response error code “302,” which indicates “resource temporarily relocated.”
Leveraging the 302 error, the malware can replace any request to internal IPs with values from the file /tmp/thconfig. In one of the recovered configuration files, the HTTP connections were sent to 114.114.114[.]114, associated with a public DNS server “public 114dns” in China, while the DNS requests were sent to fadsdsdasaf2233[.]com and had an IP value of “2.2.2[.]2.” When we queried our telemetry holdings for routers compromised by this activity cluster, we did observe some DNS interactions with the 114.114.114[.]114 node, but no interactions with the 2.2.2[.]2 IP address.
Figure 5: Snippet from /tmp/thconfigjs showing hijacking destinations
We suspect this capability enables Cuttlefish to hijack internal (a.k.a. “east-west”) traffic through the router, or site-to-site traffic where there is a VPN connection established between routers. The additional function opens the door to secured resources that are not accessible via the public internet. The capability was further supported by the actor using a self-signed X.509 certificate with a subject common name of “192.168.10.39,” a private IP address. This class of private-to-private IP address traffic would bypass the parameters of the malware’s sniffer function, thus the addition of hijack functionality.
Once they possess authentication material from the HTTP hijack, the actor may connect back into the targeted LAN using a VPN embedded in the malware, which will be described in the next section. We suspect this type of attack could be particularly hard to detect as it occurs over a trusted internal network, whereas many security tools are focused on connections occurring to and from the internal network and the internet.
VPN Functionality
We discovered one module to provide VPN functionality based off of the open-source project called n2n.
The VPN function starts by running the following commands on the compromised host:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE
Next the sample will get the IP of the hardcoded domain pp.kkthreas[.]com using CloudFlare’s DNS API using the URL hxxps://cloudflare-dns[.]com/dns-query?name=%s&type=A.
It then downloads the rules from the C2 on port 443 and saves the output as /tmp/n2nconfigjs. Then it will read and parse the following rules for the n2n module:
- “proxy_rule_hearttime”: 1000,
- “proxy_rule_version”: 13,
- “n2n_rule_hearttime”: 10800,
- “n2n_rule_version”: 11,
- “n2n_community”: “mynetworks”,
- “n2n_secret_pass”: “{redacted}”,
- “n2n_supernode”: “107.189.28[.]251:7777”,
- “n2n_nic_ip”: “100.126.229.9”,
- “n2n_status”: 1
If n2n_status is set to 1, it creates a thread to join an n2n community and process connections as shown below. We suspect that this could allow the actors the ability to impersonate the legitimate victims true IP address when access public cloud services, or even give them the ability to interact with the local LAN from a private IP address, thus bypassing some perimeter-based security measures.
Figure 6: Screenshot showing the resolution, retrieval and writing of the n2n parameters to disk
Private Proxy Functionality
The proxy functionality is used as an alternative to a VPN tunnel in routing traffic back through the infected device, allowing them to weaponize the stolen credential material from an IP address associated with a known user. This function appears to be based on an open-source project called “socks_proxy.” The sample will bind to all external interfaces on what appears to be a random port and uses the hard coded username and password for socks5 proxy authentication. Unlike other proxy malware such as TheMoon, where the proxy services are sold to other actors, we assess that this proxy pool is only used by the cuttlefish actors.
Figure 7: Proxy functionality
Historical Context for the Campaigns
Thus far we have identified two campaigns. One campaign took place around December 22, 2023, where the i386 and x86-64 version appeared to communicate with the hard-coded IP address 205.185.122[.]121. The ARM, and all other versions, appeared to communicate with the embedded domain kkthreas[.]com that resolved to the IP address hxxps://198.98.56[.]93. In a more recent campaign, we observed the same payload server, but a different file path is utilized. This version of the binary appeared to be more robust and once again communicated with the hardcoded IP address 198.98.56[.]93. This sample was first submitted to VirusTotal on August 11, 2023.
Based on x.509 certificates, we assess Cuttlefish has been active since at least July 27, 2023. The first documented campaign to deploy the malware dates back to August 11, 2023, and at least one additional campaign took place on December 31, 2023.
Overlap with HiatusRat
The binary displayed associations to a previously documented activity cluster we named “HiatusRat.” One of the strongest correlations came from the embedded build paths, which were the same across both the Cuttlefish and HiatusRat samples. A search across VirusTotal for the first part of the build path, “/home/test/qwert/buildroot-2020.02.4,” returned only five results; four of which were associated with Cuttlefish, and the other with a previously documented HiatusRat sample.
Embedded build paths from Cuttlefish:
/home/test/qwert/buildroot-2020.02.4.arm/output/build/mbedtls-2.16.7/library/ssl_tls.c
/home/test/qwert/buildroot-2020.02.4.arm/output/build/mbedtls-2.16.7/library/ssl_cli.c
/home/test/qwert/buildroot-2020.02.4.arm/output/build/mbedtls-2.16.7/library/ssl_srv.c
Embedded build paths from HiatusRat:
/home/test/qwert/buildroot-2020.02.4.arm/output/build/mbedtls-2.16.7/library/ssl_tls.c
/home/test/qwert/buildroot-2020.02.4.arm/output/build/mbedtls-2.16.7/library/ssl_cli.c
/home/test/qwert/buildroot-2020.02.4.arm/output/build/mbedtls-2.16.7/library/ssl_srv.c
We compared Cuttlefish and HiatusRat binaries using BinDiff, which showed 2271 out of 2938 functions match, this correlated to 77% overlap. We believe that the overlap of the build path and the function match indicate the same developers were behind both malware families.
Black Lotus Labs Global Telemetry and Analysis
Victimology
Lumen’s global network telemetry surrounding the Cuttlefish campaigns was peculiar, in that approximately 99% of the connections to the confirmed C2 stemmed from Turkish-based IP addresses going back to early October 2023. While we have observed several hundred IP addresses interacting with the identified C2 servers, gauging the number of true infections is difficult given that 93% are stemming from two cellular network providers, and as such these typically have a higher DHCP churn. So, while the targeting was almost exclusively limited to Turkey, there was a wide scale compromise of entities who rely on Turkish infrastructure.
Some of the more prominent entities include the infection stemming from an IP address associated with a Turkish-based airline, and a handful of IP addresses associated with satellite service providers from two different firms.
The first and most recent US victim communicated with one of the C2s for over 23 days, a likely indication of infection. This was a US-based IP address associated with a datacenter. At this time, we are unable to confirm if it is the datacenter itself that was compromised, or someone who is leasing servers and IP addresses from the data center, as there were two IP addresses used concurrently within the same subnet.
Creating VPN/Proxy Tunnels to Weaponize Stolen Key Material
Another compromised router had communications with one of the C2s for a single day in December. During this interaction the compromised router received a connection on port 1194 from the C2, this port is associated with OpenVPN. We assess that they used this function prior to implementing the n2n module. When we analyzed the primary C2 node,107.189.28[.]251, we observed a large number of UDP-based connections to compromised routers using dynamic Turkish-based IP addresses. While these connections were all brief (typically less than 24hrs), they indicated large UDP based data transfers.
We assess the threat actor was connecting through the compromised router with a Virtual Private Network (VPN) protocol such as n2n, or a proxy service like socks_proxy. This would allow them to weaponize the stolen authentication material, and retrieve data associated with the targeted entities. By implementing the VPN connection through the compromised router, the actor is attempting to avert suspicion from abnormal login-based alerts, as the IP address of said router (now used as a proxy), is associated with the targeted organization.
Conclusion
Cuttlefish represents the latest evolution in passive eavesdropping malware for edge networking equipment, allowing an actor to adapt and overcome the TLS configurations adopted by more modern enterprises. We also believe these innovations are the next generation in malware capabilities; the ability to eavesdrop and perform DNS and HTTP hijacking has seldom been observed – the few publicly identified campaigns include ZuoRat, VPNFilter, Attor, and Plead. However, this is the first instance where we have seen rules specifically designed to seek out private IP connections to hijack. We assess that the underlying actor would likely deploy HiatusRat (which relies on tcpdump) on legacy networks where resources such as email servers were hosted on-premise, which may explain some of the peculiar targeting associated with the first HiatusRat report.
An interesting feature of this campaign was the choice to seek cloud-based authentication material. As Gartner predicts, the influence of public cloud will only increase and “become a necessity by 2028,” thus far security controls have not kept pace. So while there have been a few reports of cloud-centric intrusions from apex actors like Storm-558 and Midnight Blizzard, we suspect that trend is likely going to increase until proper controls and logging are widely configured. Additional recommendations on how to hunt through Cloud Logs and managing Identity access guidance have been released by the US National Security Agency (NSA) and Cybersecurity infrastructure agency (CISA) within the US Department of Homeland Security (DHS) on this topic.
We suspect that targeting these cloud services allows the attackers to gain access to many of the same materials hosted internally, without having to contend with security controls like EDR or network segmentation. We assess the combination of targeting networking equipment (which is frequently unmonitored), to gaining access to cloud environments (which frequently do not have logging in place), is intended to grant long term persistent access to those targeted ecosystems.
Black Lotus Labs continues to monitor and track SOHO/IoT-based malware to help protect and help better secure the internet as a whole. To that end, we have blocked traffic across the Lumen global backbone to all of the infrastructure related to Cuttlefish. We have added the indicators of compromise (IoCs) from this campaign into the threat intelligence feed that fuels the Lumen Connected Security portfolio. We will continue to monitor new infrastructure, targeting activity, and expanding TTPs, and we will continue to collaborate with the security research community to share findings related to this activity.
We encourage the community to monitor for and alert on these and any similar IoCs. We also advise the following:
Corporate Network Defenders:
- Continue to look for attacks on weak credentials and suspicious login attempts, even when they originate from residential IP addresses which bypass geofencing and ASN-based blocking.
- To encrypt network traffic with TLS/SSL, to prevent sniffing when retrieving or sending data located remotely, such as when you are using cloud-based services or performing any type of authentication.
- We recommend the inspection of SOHO devices for abnormal files such as binaries located in the /tmp directory or rogue iptables entries. We also recommend routinely power cycling these devices to help remove malware samples in-memory.
- To implement certificate pinning when remotely connecting to high-value assets, such as cloud assets, to prevent threat actors from being able to hijack connections.
Consumers with SOHO routers:
- Users should follow best practices of regularly rebooting routers and installing security updates and patches. For guidance on how to perform these actions, please see the “best practices” document prepared by Canadian Centre for Cybersecurity.
- For Organizations that manage SOHO routers: make sure devices do not rely upon common default passwords. They should also ensure that the management interfaces are properly secured and not accessible via the internet. For more information on securing management interfaces, please see DHS’ CISA BoD 23-02 on securing networking equipment.
- We also recommend routinely power cycling these devices to help remove malware samples in-memory.
- We also recommend replacing devices once they reach their manufacturer end-of-life (EOL) and are no longer supported.
Analysis for this report was performed by Steve Rudd and Danny Adamitis. Technical editing by Ryan English.
For additional IoCs associated with this campaign, please visit our GitHub page.
If you would like to collaborate on similar research, please contact us on Twitter @BlackLotusLabs.
This information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk.