MAR-10454006.r5.v1 SUBMARINE, SKIPJACK, SEASPRAY, WHIRLPOOL, and SALTWATER Backdoors
Post published:September 8, 2023
Notification
This report is provided “as is” for informational purposes only. The Department of Homeland Security (DHS) does not provide any warranties of any kind regarding any information contained herein. The DHS does not endorse any commercial product or service referenced in this bulletin or otherwise.
This document is marked TLP:CLEAR–Recipients may share this information without restriction. Sources may use TLP:CLEAR when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:CLEAR information may be shared without restriction. For more information on the Traffic Light Protocol (TLP), see http://www.cisa.gov/tlp.
Summary
Description
CISA obtained five malware samples – including artifacts related to SUBMARINE, SKIPJACK, SEASPRAY, WHIRLPOOL, and SALTWATER backdoors. The device was compromised by threat actors exploiting CVE-2023-2868, a former zero-day vulnerability affecting versions 5.1.3.001-9.2.0.006 of Barracuda Email Security Gateway (ESG).
For information about related malware, specifically information on the initial exploit payload, SEASPY backdoor, WHIRLPOOL backdoor, and the SUBMARINE backdoor, see CISA Alert: CISA Releases Malware Analysis Reports on Barracuda Backdoors.
This file is a SUBMARINE artifact, an empty text/data file. The name of the file is designed to exploit a vulnerability on the target environment where the base64 string within the file name will be executed on the Linux shell. The code in Figure 1 will change the permissions of any directory/file/path with that begins with ‘/root/mac’ to executable. Then, anything containing the string ‘mach*’ in the directory/file/path ‘/root/mach’ are executed.
Screenshots
Figure 1 – Figure 1 depicts the Base64 encoded, and decoded, name of the artifact.
This artifact, belonging to the SKIPJACK malware family, is a Perl script that enumerates file system information. This script first checks the file system by opening ‘/etc/fstab.main/,’ then checks the value against the array ‘ARGV[0]’, which perl automatically provides to hold all values from the command line in. The script will print either ‘xfs’ or hda depending on the type of file system it finds. The script contains a second if statement that gathers more information about the type of file system. This second if statement contains the regular expression ‘/^/dev/(S+)d+s+/s+(S+)/,’ which translates to ‘/etc/fstab.’ The script uses this second half of the code to check for file system type or information about the partition, which it then prints based on the value of ‘$requested_data.’
Screenshots
Figure 2 – Figure 2 depicts code contained in “get_fs_info.pl.”
This artifact is a trojanized Lua module that has been identified as a “SEASPRAY” variant. SEASPRAY registers an event handler for all incoming email attachments. This variant checks for the sender and the string “obt”, which is hard coded in the lua file. If that string is found the malware uses os.execute to execute the file “saslautchd”, see Figure 3.
Screenshots
Figure 3 – This screenshot illustrates how the SEASPRAY filters traffic looking for the string “obt”. Once that string is received SEASPRAY uses os.execute to execute the file “saslautchd”.
This artifact, belonging to the WHIRLPOOL malware family, is a 64-bit Linux Executable and Linkable Format (ELF) file. The malware checks processor hardware and architecture, to include if the target system uses AMD or Intel, see Figure 4. Figure 5 shows the malware determining the kernel version by invoking the ‘uname’ command line function and exploring the contents of the ‘/proc/sys/kernel/osrelease’ file. Figures 6, 7, and 8 show the malware’s capacity to connect to a remote address, and then create a new process with the command line argument ‘/bin/sh.’ The connection to a remote host and the invocation of a bash shell are the two components/phases used by reverse shells. Figure 9 shows the malware’s capacity to interact with the Name Service Cache Daemon by creating and connecting to a Unix socket at ./var/run/nscd/socket.’ This socket can cache Domain Name System (DNS) requests. Rather than listening on port 53, it listens on the socket file itself, for data from other programs/processes. Figure 10 shows the malware’s capacity to perform DNS resolution, using the system call ‘sys_getpeername.’ The malware accesses the target’s environment variables. See below list below:
Figure 4 – Figure 4 depicts the use of the ‘cpuid’ assembly instruction and strings amalgamating to ‘intel’ and ‘AMD.’
Figure 5 – Figure 5 depicts the ‘uname’ Linux OS command line function. This figure further depicts a call to functions that open and read the contents of the path ‘/proc/sys/kernel/osrelease/.’
Figure 6 – Figure 6 depicts the creation of a socket that facilitates Internet Protocol Version 4 connections. It further depicts a connection to a remote address using the ‘sys_connect’ function.
Figure 7 – Figure 7 depicts the string ‘sh -c /bin/sh’ fed into the ‘sys_execve’ function as an argument.
Figure 8 – Figure 8 depicts the string ‘sh -c /bin/sh’ fed into the ‘sys_execve’ function as an argument.
Figure 9 – Figure 9 shows the malware’s ability to interact with the Name Service Cache Daemon.
Figure 10 – Figure 10 depicts the Linux OS system call, ‘sys_getpeername.’
This artifact, belonging to the SALTWATER malware family, is a 32-bit Linux Shared Object (.so) file. The malware can intake data over the network, using a previously established socket, with the ‘recv’ function as shown in Figure 11. Figure 12 shows the malware creating a new thread, within the calling process. This is thread injection and it can inject two different functions. Figure 13 shows the first function that can perform DNS resolution. Figures 14 and 15 show the second function. The second function can establish communications, over the network, using a TLS version 1 connection. Lastly, using ‘popen’, the malware can execute any shell command with the same privileges as its calling process.
Screenshots
Figure 11 – Figure 11 depicts the ‘recv’ Berkeley Sockets function dynamically loaded and executed at runtime.
Figure 12 – Figure 12 depicts the ‘pthread_create’ function.
Figure 13 – Figure 13 depicts multiple functions from the Berkley Sockets API.
Figure 14 – Figure 14 depicts functions that facilitate Secure Sockets Layer (SSL) and TLS communications.
Figure 15 – Figure 15 depicts the ‘popen’ function.
CISA recommends that users and administrators consider using the following best practices to strengthen the security posture of their organization’s systems. Any configuration changes should be reviewed by system owners and administrators prior to implementation to avoid unwanted impacts.
Maintain up-to-date antivirus signatures and engines.
Keep operating system patches up-to-date.
Disable File and Printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
Restrict users’ ability (permissions) to install and run unwanted software applications. Do not add users to the local administrators group unless required.
Enforce a strong password policy and implement regular password changes.
Exercise caution when opening e-mail attachments even if the attachment is expected and the sender appears to be known.
Enable a personal firewall on agency workstations, configured to deny unsolicited connection requests.
Disable unnecessary services on agency workstations and servers.
Scan for and remove suspicious e-mail attachments; ensure the scanned attachment is its “true file type” (i.e., the extension matches the file header).
Monitor users’ web browsing habits; restrict access to sites with unfavorable content.
Exercise caution when using removable media (e.g., USB thumb drives, external drives, CDs, etc.).
Scan all software downloaded from the Internet prior to executing.
Maintain situational awareness of the latest threats and implement appropriate Access Control Lists (ACLs).
Additional information on malware incident prevention and handling can be found in National Institute of Standards and Technology (NIST) Special Publication 800-83, “Guide to Malware Incident Prevention & Handling for Desktops and Laptops”.
CISA continuously strives to improve its products and services. You can help by answering a very short series of questions about this product at the following URL: https://us-cert.cisa.gov/forms/feedback/
Document FAQ
What is a MIFR? A Malware Initial Findings Report (MIFR) is intended to provide organizations with malware analysis in a timely manner. In most instances this report will provide initial indicators for computer and network defense. To request additional analysis, please contact CISA and provide information regarding the level of desired analysis.
What is a MAR? A Malware Analysis Report (MAR) is intended to provide organizations with more detailed malware analysis acquired via manual reverse engineering. To request additional analysis, please contact CISA and provide information regarding the level of desired analysis.
Can I edit this document? This document is not to be edited in any way by recipients. All comments or questions related to this document should be directed to the CISA at 1-888-282-0870 or CISA Service Desk.
Can I submit malware to CISA? Malware samples can be submitted via three methods:
CISA encourages you to report any suspicious activity, including cybersecurity incidents, possible malicious code, software vulnerabilities, and phishing-related scams. Reporting forms can be found on CISA’s homepage at www.cisa.gov.
XWe use cookies in our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of the cookies explicitly. Visit Cookie Settings to know more about the cookies used on our website. Read More RejectACCEPTCookie settings
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are as essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
This category contains the advertising cookie that is set by Google, when embeding one of its services. CYNET embeds a Google Map, showing its location in the Homepage and in Contact sections. The cookies that are set are the following:
NID
This website uses Google Analytics (with IP Anonymization) in order to track the visitor's performance. The cookies that are set by the service are the following:
_ga
_gat
_gid
This category contains all the cookies that are closely related to the functionality of the Website, such as the prefered language, whether the user has read and/or accepted the Cookie Consent in the various categories.
The following cookies are set:
pll_language
viewed_cookie_policy
cookielawinfo-checkbox-preferences
cookielawinfo-checkbox-advertisement
