Enterprises continue to be the main target for malicious cryptomining campaigns. Mainly due to their powerful computing resources, but also due to their network structure that allows attackers to infect one vulnerable machine as an entry point and gain a foothold from which they will move laterally to other connected targets on the network.
This fact is only enhanced by the enterprises’ rapid shift to the cloud production environment. With Linux and Unix-like being the preferred operating systems in the cloud and Secure Shell (SSH) being the common standard for remote access to Linux and Unix-like machines, the number of cryptomining campaigns that target these resources increases accordingly.
The latest attacks targeting Linux servers in the cloud and SSH are FritzFrog and Lemon_Duck. Here’s what you need to know about these two attacks:
Lemon_Duck–the most sophisticated cryptominer to date
Security researchers from Sophos report that Lemon_Duck, one of the most advanced cryptominers reported today, infects cloud applications and Linux machines and continuously updates itself with new threat vectors and obfuscation techniques. The miner itself is “fileless,” meaning it resides solely in memory and leaves no trace on disk and therefore is much harder to discover.
Remote Access and Lateral Movement: SSH Machine Identities
For Linux targets, the malware employs an SSH bruteforce module that performs port scanning to find machines listening on port 22 (SSH) and when it finds them, it launches an SSH brute force attack, with the username rootand a hardcoded list of passwords.
Upon a successful attack, the malware downloads and executes a malicious shellcode that in order to spread across the network looks for additional targets in /.ssh/known_hosts and collects SSH machine identities and authentication information.
FritzFrog–Both a botnet and a worm
Security firm Guardicore discovered FritzFrog, an active botnet campaign that has managed to breach and infiltrate over 500 SSH servers belonging to governmental offices, educational institutions, medical centers, banks and numerous telecom companies in the US and Europe.
Written in Golang, FritzFrog is both a “fileless” worm and a botnet targeting Unix-like devices. It assembles and executes its payload entirely in memory without writing to disk, making it volatile and harder to detect and employs a custom P2P implementation, which makes it decentralized and self-sufficient.
Remote access and Persistence: SSH machine identities
Similarly to Lemon_Duck, FritzFrog obtains initial access via bruteforce on SSH remote service. Upon a successful attack, it collects SSH machine identities and backdoors the server by inserting an attacker-owned SSH machine identity to maintain persistence on the target.
Should we worry?
The increase in malware campaigns that target SSH is worrying for several reasons. First, it makes it harder for defenders to detect the attackers. Since SSH offers end-to-end encryption, an SSH connection would most likely not raise suspicions and would not trigger alerts by typical network detection tools, enabling the attackers to evade defense mechanisms and stay under the radar.
The second reason is that it implies that SSH and SSH machine identities on cloud assets are not protected and properly managed and therefore cannot be easily discovered or changed upon a successful intrusion, allowing attackers to potentially open a backdoor to maintain persistence in the network.
How Venafi can help
SSH Machine Identity Management
- Discover all SSH machine identities in the environment, who they belong to and what they are used for:
- Organizations should map all trust relationships and identify and remove any orphaned and duplicate authorized keys.
- They should ensure passphrase protection, key length and algorithms. Furthermore, they should assign ownership of all access granting keys, and monitor and analyze key-based access usage.
- Control SSH identities and authorized keys.
- Control SSH configuration files and known hosts files to prevent any tampering.
- Implement clearly defined SSH key management policies
- Define SSH hardening configurations.
- Create inventory and remediation policy.
- Establish continuous monitoring and audit process.
- Automate the whole process.
Do you have what it takes to protect your SSH keys from abuse?