A single hosting provider saw 70,000 servers infected with Ebury malware in 2023, according to a detailed report by cybersecurity provider Eset.
Ebury, active in various forms since 2009, is a backdoor inside the OpenSSH daemon. It acts as a way for attackers to install more malware.
The US-based autonomous system was used by several server leasing companies. And Eset warned in a whitepaper that the malware operators “have established a significant presence in data centers worldwide…"
AiTM attacks to get in DCs
Ebury's operators have implemented "large scale Adversary in the Middle" (AiTM) attacks to establish their position in DCs. ESET said. First:
Perl scripts are utilized to automate the execution of arpspoof and
the creation of iptables rules and redirecting incoming SSH traffic to a honeypot where victims unwittingly enter their SSH credentials. Upon identifying a target, the following steps are taken:
- Identify a compromised machine with Ebury installed within the same subnet as the targeted system.
- Confirm network segmentation by examining the ARP cache after pinging the target.
- Install necessary tools such as arpspoof.
- Execute arpspoof to intercept network traffic and establish iptables rules to redirect network traffic to an operator-controlled system designed to capture SSH credentials.
Ebury is activated remotely by sending a carefully crafted SSH client version string to the compromised SSH server. Its operators have added various sophisticated and Linux-centric capabilities in recent years.
Ebury was updated in late 2023 and its version 1.8 includes “new obfuscation techniques, a new domain generation algorithm (DGA), and improvements in the userland rootkit used by Ebury to hide itself from system administrators,” Eset said in a threat report. “When active, the process, the file, the socket, and even the mapped memory are hidden.”
How it gets on servers originally has always been something that investigators have had limited visibility into. But Eset said in a detailed whitepaper, based on a joint investigation with Dutch law enforcement that it has identified multiple ways, ranging from ransacked lists of previous outbound and inbound SSH sessions using OpenSSH’s known_hosts files and records from wtmp that include known passwords and keys. (If these are hashed, the attackers look to brute-force them.)
Attackers have also been seen using their access to hypervisors or systems running containers to push out Ebury on “all the subsystems.”
“They will do this in an unobtrusive way that won’t require a shutdown or reboot of the contained systems. This is done in an automated way on servers running OpenVZ, where all containers are compromised by running a malicious Perl script using vzctl exec from the host.
“The way servers are monetized range from credit card information theft and cryptocurrency stealing to traffic redirection, spam sending, and credential stealing,” said Eset – which says over 400,000 Linux, FreeBSD, and OpenBSD servers have been backdoored over the years with Ebury; as of late 2023, over 100,000 compromised servers were online.
These include Internet Service Providers and Tor exit nodes among other endpoints/companies. Challengingly for defenders, Ebury can also persist on disk in multiple ways.
Monitoring a server newly infected with Ebury in early 2024, Eset found that malicious operators “connect back regularly and use the Xcat command to exfiltrate any credentials captured since they last connected. On a less regular basis, a script is used to search for and fetch any new SSH private keys, updates to the known_hosts files, a list of running services, etc. This is all via automated processes.”
The company warned hosting providers that “the compromise of virtual and dedicated servers would be more difficult for the perpetrators if hosting providers wouldn’t use passwords (generated, or not) when provisioning servers. In that scenario, the plaintext password must be communicated to the customer, and it is usually sent via email. A better approach is to use an SSH key pair, generated on the trusted endpoint of the administrator renting the server. The public key can safely be shared with the provider, who can deploy it to the new server. This way, the secret is only available to the administrator, and not even the hosting provider has the credentials to connect via SSH.”
Eset’s whitepaper with more details is here
