Leverage Azure Security Center to detect when compromised Linux machines attack

When an attacker compromises a machine, they typically have a goal in mind. Some attackers are looking for information residing on the victim’s machine or are looking for access to other machines on the victim’s network. Other times, attackers have plans to use the processing power of the machine itself or even use the machine as a launch point for other attacks. While on Linux virtual machines (VM) in Microsoft Azure we most commonly see attackers installing and running cryptocurrency mining software. This blog post will focus on the latter when an attacker wants to use the compromised machine as a launch point for other attacks.

Azure Security Center (ASC) utilizes an agent that runs on multiple distributions of Linux. When auditd is enabled, it collects logs including process creation events. These are run through the detection pipeline to look for malicious and suspicious activity. Alerts are surfaced through the ASC portal.

The Microsoft Threat Intelligence Center uses a range of methods to identify new emerging threats, including a sophisticated hybrid Linux honeypot service. A honeypot is a decoy system, set up to be attacked and lure cyber attackers to reveal themselves.

In this post, we discuss some recent instances where attacks against the honeypot originated from IPs within customer machines. In each case, malicious behavior on those compromised customer VMs had already resulted in alerts being raised through Azure Security Center. Analysis of these attacks yielded greater insight into the attacker’s behavior. This fed further detection development, allowing us to surface more attack behavior to customers earlier, and provide a more complete view of the attack end to end.

Initial intrusion

The diagram below shows the attack setup. The analysis suggests that an Apache Cassandra account with a default password was used to initially compromise an Azure VM. Once access was gained, the attack approached the honeypot (1) and other targets (2). We identified two IP addresses (3, 4) that the attacker used to log into this VM, one of which also attacked the honeypot (5). Another thing that stood out was the two IPs that the attacker was using shared the same first two octets and resolved to Romania. We will come back to this fact later.

Intrusion breakdown

One of the more common attacks that we see against customer virtual machines is a brute force or password spray attack, these quickly lead to the installation of crypto coin mining malware. In this case, the malicious user was doing something a bit different.

Host enumeration

After the initial compromise, the attacker pulled down a perl based host enumeration script from the domain nasapaul.com which hosts a few enumeration and speed test scripts. Azure Security Center surfaces this behavior via a “detected file download from a known malicious source” alert.

That script looks for specific information in the /proc/cpuinfo file to give the attacker an idea of what kind of machine they are on. You can see some of the commands run in the text box below. That same script also runs a speed test which is a service that nasapaul.com offers.

CPU=$(grep –m 1 “model name” /proc/cpuinfo | cut –d: –f2 | sed-e ‘s/^ */ /’ |sed –e ‘s/$/ / ‘)

CPUS=$ (grep –c ^processor /proc/cpuinfo)

STEP=$ (grep –m 1 “stepping” /proc/cpuinfo | cut –d: –f2 | sed –e ‘s/^ */ / ‘ | sed –e ‘s/$/ / ‘) 

BOGO=$ (grep –m 1 “stepping” /proc/cpuinfo | cut –d: –f2 | sed –e ‘s/^ */ / ‘ | sed –e ‘s/$/ / ‘)

OS=$ (lsb_release –si)

ram=$ (free –m | grep –oP ‘\d+’ | head –n 1)

VER=$ (uname –a)

uptime=$ (</proc/uptime)

uptime=$ {uptime%%. *} bold=$ (tput bold)

zile=$ ( ( uptime%60 ( )

secunde=$ ( ( uptime%60 ) )

minute=$ ( ( uptime/60%60 ) )

ore=$ ( ( uptime/60/60%24 ) )

vid=$ (lspci | grep VGA |cut -f5- -d ‘ ‘)

DISK=$ (df –h --total | grep total |awk ‘ {printf “” $2 “B\n\n” } ‘ )

Initial exploitation

That session ended, but the attacker started a new session and created a connection to a secure FTP server and pulled some files down. Then they modified the files for execution:

chmod +x 1 cyberinfo cybernetikrandom go h4e petarda port pscan2 screen speedtestvps.py sshd

This set of files is a toolkit from a known hacking group. The attacker uses the “go” file to run “pscan2” and “sshd” against two different class B IP ranges. That means they ran the scan against just over 65,000 addresses. They also used the tool “h4e” which our investigation showed was a perl script used in denial of service attacks. The text file “port” holds results of the scans, typically what IPs were listening too and maybe what ports were open. It isn’t clear if those commands completed successfully, but two hours later the attacker deleted them all and pulled down a different kit.

Password spray

This time the attacker used Wget to pull down their toolkit from a public website. As they did before, they pulled down the tools then modified them all for execution.

chmod +x a all classes co gasite.txt hu pass range scan.log ssh2 x

/bin/bash ./a ##.49

./ssh2 1500 -b ##.49 pass 22 "uname -a & lscpu"

/bin/bash ./a ###.66

./ssh2 1500 -b ###.66 pass 22 "uname -a & lscpu"

nano gasite.txt

After that, the same simple pattern is repeated against a number of class B ranges. The file “a” takes the first two octets of a class B range as input, then calls “ssh2”. “ssh2” takes input for a number of threads, the range, a password file (“pass” which in this case contains over 35,000 user/password combinations), a port number, and then the initial commands to run. The file “gasite.txt” collects output.

Later on, we see the files “co” and “range” used with the “classes” folder. The “classes” folder has details of 26 cloud and hosting companies with their IP ranges. Microsoft is there along with all the other major providers. The files “co” and “range” just expand the initial two octets into a full IP.

The attacker didn’t appear to ever execute the files “all”, “hu”, or “x” but they all have to do with configuring IP ranges, specifically filling out the full four octets of an IP. It is possible that the “ssh2” executable uses them.

Analysis of the toolkit took some effort. The output filename “gasite.txt” translates to “found.txt” and the “ssh2” file is a custom Romanian version of an ssh scanner packed and/or obfuscated using UPX. Once unpacked, the Romanian strings came through (see image below). Some further research by the red team tracked down the original ssh2 source code and a forum where our attacker or someone using the same executable, was getting some help with their code.

Result: Enhanced behavioral analytics in Azure Security Center

While investigating the intrusion, we were able to pull out a number of unique TTPs for inclusion into new analytics or for improving existing ones. They uncovered things like better password spray detection and improved coverage of attacker host enumeration. We were also able to validate that existing analytics fired as expected. The goal isn’t to show a customer multiple redundant alerts for the same intrusion, but to provide insight into the full scope of an attacker’s actions. We also acknowledge that the actor behind this attack could change some aspects of their technique. The greater the detection coverage across the attack lifecycle the more resilient we are to changes in attacker methodology. Additionally, specific techniques used by this attacker could be used by other attackers and we’d like to make sure we catch them too.

Recommended actions

Review your alerts regularly in Azure Security Center. The customer received multiple Azure Security Center alerts for this intrusion and the malicious activity stopped soon after and has not appeared again. Azure Security Center consolidates all of your alerts in one centralized location in security alerts. This makes it easy for you to see the severity of your alerts and help you prioritize your response to them. Each alert gives you a detailed description of the incident as well as steps on how to remediate the issue. For further investigation, you can review the alerts in the “Investigation Path”, an interactive and visual way to see every entity involved in the attack.

Change your passwords regularly. While Azure Security Center alerted on the activity, the intrusion could have been prevented through good password hygiene. Of the many username and password combinations in the attacker toolkit, a good chunk of them are defaults that are created when you first install a piece of software. By changing these default passwords or going password-less, you prevent your passwords from being used against you.

Final thoughts

Our team works both ends of the cybersecurity problem. We constantly improve and refine our detections through both public and internal security research. We also are proactive in monitoring the external threat as a key input to ensuring that our detection coverage is most relevant to the attacks facing both Microsoft and its customers. If you have Linux machines in Azure, consider using Azure Security Center to help monitor them and prevent them from targeting others.

In addition to the actions you can take, Microsoft has several physical infrastructure and operational controls in place to help protect the Azure platform. We have over 3,500 cybersecurity experts at Microsoft to help protect, detect, and respond to security threats against our infrastructure and services 24/7, 365 days a year. One of those teams is our team, the Microsoft Threat Intelligence Center. To learn more about our team and how we work to protect against malicious activity in Azure, watch our latest Microsoft Mechanics video.