As more and more companies perform their computing on off-premise machines and delegate infrastructure (Iaas), operating systems (OS) and software development to the cloud, more security challenges and considerations arise in enterprise defense. While Cloud Service Providers (CSP) such as AWS, Azure, and GCP are responsible for keeping their platforms secure, the users still need to secure the workloads, data, processes and machine identities in the cloud in the same way they do in on-prem environments.
In the new production environment in the cloud with DevOps tools and fully automated CI/CD pipelines, some areas remain overlooked or unaddressed and become part of a new realm for attackers to exploit. Attackers are fast to adapt to the shift towards the cloud operating model and cloud-native technologies and to the dominating operating system (OS) upon which they run, and the number of cloud-based attacks significantly grows.
Linux rules the cloud (Linux and SSH)
Given its open-source nature, Linux is generally considered to be more secure and requires less maintenance, making it the ideal OS for backend servers and maintaining off-site machines. With the rapid rise in cloud production, Linux dominates the backend infrastructure of the top CSPs and is used to manage90 percent of the workloads in the cloud (including Azure, with more than half of its virtual machines running on Linux).
As the common standard for remote access to Linux (and Unix-like) and machine and servers (and more and more Windows machines), Secure Shell (SSH) is widely used in the production environment. From developers running scripts to connect to several servers at once for tests, through configuration management software (like Terraform, Chef, Puppet, Ansible) that connect to hosts to make local changes, and CI/CD automation tools that connect to production servers to configure runtimes and push builds.
Attackers, who often take the “Living of the Land” (LotL) approach, take advantage of preinstalled services and tools and abuse their built-in capabilities to execute parts of their attacks. As the common standard for administration and remote access, SSH becomes a natural target for attackers. Although the protocol is inherently secure, the authentication mechanism, the machine identities and client-server configuration are prone to abuse.
Attackers from all range of sophistication use SSH to maintain persistence on a target, evade defense mechanisms and laterally move to other adjacent machines. The matrix below maps the Tactics and Techniques from MITRE’s ATT&CK framework used today by attackers targeting Linux servers in the cloud through SSH:
SSH Attacks on Linux Servers in the Cloud
Initial Access T1133: External Remote ServicesBrute Force
Exposing an application service to the internet is a common misconfiguration that allows access to an internal system from anywhere and acts as a common attack vector. Attackers leverage external-facing remote services as a point of entry to an application hosted in the cloud, aiming to compromise the underlying instance.
CSPs offer easy deployment of application services in cloud environments, opening more space for errors and misconfigurations by their users. According to a recent report by Unit42, 32 percent of exposed hosts in public cloud have open SSH services and 47 percent of the SSH servers on Azure VMs had password authentication enabled—making them potentially vulnerable to brute-force attacks.
Adversaries continuously look for misconfigurations and weak authentication methods in public-facing remote services and the number of attacks in the cloud that abuse SSH password-based authentication continues to grow.
Advanced Persistent Threat (APT) groups
Azure Security Center reported last year on a Linux-based cyberattack against Azure, where the attacker brute-forced an exposed SSH service to infect the host with a cryptominer and used it as a launchpad for further large-scale attacks.
In another example, Sophos reported of a sophisticated multi-platform APT dubbed Cloud Snooper where skilled attackers managed to get initial access on a Linux system through what appears to be a brute-force attack on an exposed SSH service and moved from there to the on prem network.
Other examples include commodity malware campaigns, like Kaiji Linux cryptominer and FritzFrog botnet, which have “wormlike” spreading capabilities and infected cloud servers and IoT through brute-forcing SSH.
Initial Access T1078: Valid AccountsUnsecured credentials: Private keys
Another less reported attack vector on applications with exposed SSH services is for an attacker to use already compromised SSH keys and credentials. Attackers can gather SSH keys and credentials from source control, public repositories or open buckets or steal them from machines compromised in parallel or unrelated campaigns, or even purchase them on remote access markets where they are sold as-a-service.
Persistence T1133: Valid Accounts, Launching SSH daemon
As the common standard for remote access to Linux servers, SSH is used by both developers and attackers to ensure their access to the server. Attackers who were able to compromise a machine, can enable the SSH service to allow SSH communication and by that establish persistence on the target. This ensures them to also blend in in legitimate traffic, avoid detection and pass through any firewalls that are in place, since SSH port 22 is normally allowed.
In February this year, Aqua Security reported of a new attack vector that leverages containers API servers as an entry point to discover and expand to other instances running in the cloud. By instantiating a container, the attackers were able from there to compromise the host and open an SSH backdoor masquerading as a legitimate process.
In another attack discovered by the same company a few months earlier, a malicious container on Docker Hub containing cryptominers, opens an SSH backdoor by running a script that is designed to run OpenSSH Daemon, listen to connections from clients and allow SSH communication.
Persistence T1078: Valid AccountsUnsecured credentials: Private keys
Another common technique to establish persistence on a target where SSH service is enable, is to insert attacker owned SSH public key to the authorized keys file on the server to ensure remote connection to the server without notice.
In April this year, Trend Micro reported about exposed Redis instances being exploited through a Remote Code Execution (RCE) vulnerability for cryptomining campaigns. The malware was backdooring the vulnerable Redis servers with attacker owned SSH key to guarantee persistence.
In August this year, FritzFrog mentioned above, has breached over 500 SSH servers belonging to governmental offices, educational institutions, medical centers, banks and numerous telecom companies in the US and Europe and backdoored the compromised servers with an attacker owned SSH key to maintain persistence.
Legitimate SSH Services
Defense Evasion T1078: Valid AccountsUnsecured credentials: Private keys
Using legitimate and preinstalled remote service with valid accounts (see below) on compromised machines is a common technique to evade defense mechanisms. Attackers collect insecure machine identities from their targets and use them to establish SSH communication, bypass any access restrictions on traffic and raise no suspicious or flag any security controls.
SSH keys and “wormlike” malware
Lateral Movement T1021: Valid Accounts004: SSH
According to a recent report by Orca Security, 5.6%of publicly exposed assets in the cloud contain
SSH keys that could potentially be used to access adjacent systems. Attackers use these keys to move laterally across the network and log into remote machines to search for higher profile assets or infect further victims.
In early May, a major attack campaign targeted vulnerable servers of the management and configuration software SaltStack, downloading a RAT and cryptominers to the victim machines. The attack hit high profile servers in the cloud belonging to companies like DigiCert, Cisco, LineageOS and Ghost and was designed to steal and exfiltrate SSH keys and known hosts information to enable lateral movement to more and more machines, behaving like a warm. In the aforementioned attack reported by Trend Micro, exposed Reddis servers were targeted by a “wormlike” malware which was collecting SSH keys and known hosts information to spread through the SSH remote service to other victims.
The attacks mentioned before to target Docker API Daemons, among them the infamous Kinsing malware, targeted containers as an entry point to other instances in the cloud and collected SSH keys, known hosts, user account details, and IP addresses in order to spread through the SSH remote service across the network to other potentially higher value targets, again in a “wormlike” manner.
Lateral Movement T1021: Valid AccountsSSH Agent forwarding
In another use case, SkyLight found an active attack on the cloud orchestration platform OnApp used by public and private cloud providers, which allowed an attacker to compromise the entire private cloud through SSH. The investigation managed to demonstrate that the APT group was using a feature exposed by the platform that allowed any user to trigger an SSH connection from OnApp to the managed server, with the SSH agent forwarding feature enabled. This allowed the attacker to relay authentication to any other server within the same cloud, achieving RCE with root privileges.
Command and Control Remote Services, SSH
Adversaries may use legitimate and preinstalled remote access services such as SSH to establish an interactive command and control channel to target systems within networks, since these are normally allowed by application control within a target environment.
In Cloud Snooper APT campaign, the attackers created covert control channels by using connections through a port that is allowed by the AWS Security Groups (SG). On infected AWS instances, the attackers directed the content of the inbound traffic with a source port of 1010/TCP to the SSH port, 22/TCP. This allowed an SSH connection to pass around the AWS SG with IP restrictions on traffic to port 22.
Adversaries constantly look for new ways to exploit systems and execute their attacks and are fast to adapt to the new production environment in the cloud. This is evident in the rise of the cloud-based attacks and more significantly in Linux-based malware.
A review of the recent cloud-based attack campaigns reveals that attackers develop more and more Linux-based malware designed to abuse insecure machine identities as part of the routine attack. Whether it is designed to gain initial access to a target machine through SSH, insert attacker-owned key for persistence or collect SSH keys to laterally move like a “worm” across the network—malware is developed with machine identity in mind.
This is especially worrying since the motivation of the attack is somehow unclear. Although most of the campaigns are reported to primarily deliver crypto currency mining malware, the question arises—what if this malware infected and backdoored a high-profile target or a target of interest for another more sophisticated and skilled group? Can it be that the cryptomining attack is actually part of a preliminary stage and can be then used as a launchpad for more targeted attacks? It also possible that these remote accesses will then be sold to other threat actors of interest in black underground markets? Or maybe these attacks are just noisy and were quick to discover and the APTs are acting stealthily under the radar? Or maybe they were designed as a distraction, like in many Distributed Denial of Service (DDoS) campaigns?
The shift towards a cloud operating model brings with it many challenges and new security considerations. The Windows-centric security community is forced to react and address the problem by tweaking traditional security models like MITRE’s ATT&CK framework to the cloud and to the Linux OS (like in the case of Intezer, who created a matrix for Linux cloud servers).
Companies must ensure that all the appropriate security controls are in place and protect their machine identities as much as they protect their human identities. Upon a successful attack, security teams are advised to not only follow the guidelines and recommendations but also make sure that machine identities are being changed as part of the incident response process.