Uncovering Linux based cyberattack using Azure Security Center

As more and more enterprises move to the cloud, they also bring their own set of security challenges. Today, almost half of Azure virtual machines (VMs) are running on Linux, and as the Linux server population grows, so are the attacks targeting them. As detection capabilities advance, attackers are using new and stealthier techniques to stay undetected and persist with their motives. Azure Security Center, Microsoft’s cloud-based cyber solution, helps customers safeguard their cloud workloads as well as protect them from these threats.

In this blog post, we detail a real-world Linux attack whose purpose initially looked like crypto mining, but it turned out that the attacker’s intent was to use the compromised host as a launchpad for further large-scale attacks.

Incident details

After the initial successful SSH brute force compromise, the attacker proceeds to download a first stage ‘tddwrt7s.sh’ script using utilities like ‘wget’ that delivers further payload to the host. Azure Security Center surfaces this behavior via a “Detected suspicious file download” alert.

Post stage 1 download, the attacker executed the script to find ‘dota.tar.gz’ by enumerating multiple hosting URLs. Once a live hosting IP was found, the second stage file gets delivered in directory ‘/tmp/.mountfs.’ Most of these exploitation and persistence techniques are observed from the /tmp folder. In this case all activities were tracked under /tmp/.mountfs and /tmp/.mountfs/.rsync directories. Creating directories with a dot keeps the activity hidden from the user interface, a common technique used by attackers.

Later, we see traffic to different mining pools including ‘mine.moneropool.com’ but nothing further that would confirm the purpose as mining cryptocurrency. The “Detected suspicious network activity” analytic triggered on this activity along with “Digital currency mining” analytic. This was followed by reconnaissance grep activity used by the attacker to get more information on the target machine to see if it had already been compromised and in use by other actors.

The attackers then used a bash script to search and kill processes on some of the above-mentioned miners that they grepped using command:

“ps auxf|grep -v grep|grep “xmrig” | awk ‘{print $2}’|xargs kill -9”

Let’s talk more about what this command does. The first command helps to show a tree view of parent-child processes in the output of ps (process status).The first grep removes the grep process from this list and the second grep will extract any xmrig (a well-known miner) process in the filtered list. Awk pattern matches the specified pattern and xargs executes the SIGKILL signal.

What follows next is a series of pkill commands to kill processes using couple of techniques that:

1. Match the entire process and argument list pattern.
2. Forcefully terminate a process.

To get the maximum CPU usage and efficiency, attackers generally start deleting the existing coin miner instances and focus on deploying new instances of mining payload.

Generally, after this activity, the traces of cryptocurrency wallet or other activities related to mining becomes evident but what followed next was a little surprise.

It turns out that this machine appeared to have been used to target 20,000 different endpoints based on our timeline of attack analysis detailed below:

Azure Security Center caught most of the suspicious activities observed above that triggered security alerts. To further our investigation, we collaborated with our internal memory forensics team. The analysis of the ELF payload unfolded even more details in this attack campaign:

• The payload had three important components:
  • tsm64: An ELF executable.
  • Libraries that tsm64 relied on for execution.
  • tsm: Code used to launch the tsm64 executable.
• To ensure that the attacker payload was able to run on most distributions, the attackers supplied the libraries tsm64, which was dependent on for successful execution.
• tsm: tsm is ld.so renamed. ld.so is a helper program that loads the shared libraries needed by the program executable, prepares the program to run, and then runs it.
• Dependent libraries: The dependency analysis of the tsm64 executable showed that it needed four libraries at the runtime. Namely, libpthread.so.0, libdl.so.2, libc.so.6, and ld-linux-x86-64.so.2.
• tsm64: This is the executable that the attacker eventually wants to run. Turns out, tsm64 is a multi-threaded SSH brute force tool that can attack a set of IP’s with provided passwords.
• The analysis of the Procedure Linkage Table (PLTs) for tsm64 showed the multi-threaded, network communication, and password file reading capabilities. A subset of the system apis are listed below:
  • Networking: setsockopt, getsockopt, getsockname, connect, gethostname, socket, inet_ntoa, recvfrom, recv, bind, getaddrinfo, inet_pton, getpeername
  • Multi-threaded (pthread): pthread_getspecific, pthread_setspecific, pthread_cond_signal, pthread_mutex_init, pthread_create, pthread_cond_init, pthread_key_delete, pthread_self, pthread_join, pthread_equal, pthread_cond_wait, pthread_detach, pthread_once, pthread_mutex_lock, pthread_key_create, pthread_mutex_destroy, pthread_cond_broadcast, pthread_mutex_unlock, pthread_kill
  • Password file entry: getpwnam, getpwnam_r, getpwuid_r
• The IP address list and user credentials to be used for the brute force attack were downloaded into innocuous sounding file names ‘a’ and ‘b.’ File ‘a’ contained a list of 20,000 different IP addresses while file ‘b’ had a listing of credentials. These files were later renamed to ‘ip’ and ‘p’ respectively and passed into tsm64.
• Using the inbuilt timeout utility, the tool was programmed to run for a maximum time of 90 minutes.

Adversaries are always finding new and novel ways to evade detection. As cyber defenders, we need to constantly innovate and track these latest threats in order to thwart new and deceptive attacks that are making rounds in the cloud cyber world.

Recommended actions

• Azure Security Center can automatically correlate such multiple triggered alerts into a single security incident. This capability provides a single overview of any attack campaign and all the related alerts to understand the action attackers took and what resources were impacted.
• While Azure Security Center alerted on the activity, the intrusion could have been prevented through good password hygiene. It’s recommended to utilize passwords and passphrases that are not easily guessed. Some of our previous blogs cover this topic: Just In Time (JIT) , Password-less sign-in, and Azure Key Vault.
• Azure Security Center alerts can also be integrated in existing SIEM solution for a centralized view of security posture across your organization or with Microsoft’s new SIEM Azure Sentinel.

Learn more

To learn more about the Azure Security Center, see the following:

• Azure Security Center FAQs—Find frequently asked questions about using the service.
• Setting security policies in Azure Security Center—Learn how to configure security policies for your Azure subscriptions and resource groups.
• Managing and responding to security alerts in Azure Security Center—Learn how to manage and respond to security alerts.
• Operations Management Suite (OMS) Agent for Linux—Enables rich and real-time analytics for operational data (Syslog, Performance, Alerts, and Inventory) from Linux servers, Docker Containers, and monitoring tools like Nagios, Zabbix, and System Center.