██████╗ ██████╗ ██╗ ██╗ █████╗ ╚════██╗██╔═══██╗██║ ██║██╔══██╗ █████╔╝██║ ██║███████║███████║ ╚═══██╗██║ ██║██╔══██║██╔══██║ ██████╔╝╚██████╔╝██║ ██║██║ ██║ ╚═════╝ ╚═════╝ ╚═╝ ╚═╝╚═╝ ╚═╝
Welcome to 3OHA, a place for random notes, thoughts, and factoids that I
want to share or remember.
14 February 2023
While digging in my pile of Bash malware, I came across a tiny and unfinished sample from a family named Anubis after its original file name anubis.sh. The sample I analyzed, with hash fc1bb578c99f165e3eb8ac116b1ed42c60171eb83644104142c0294d915c856e, is barely 62 lines long and contains a moderate amount of comments documenting they key steps it executes on the victim. Both the original sample and the beautified version that I prepared are available in this GitHub repository.
Anubis is a Bash ransomware using a standard encrypt-then-shred approach. It first retrieves a public key from a C2 endpoint, which in this version is hardcoded to 192.168.0.27:9002—a clear sign of this being a test sample or one that is still in development). It then uses openssl to generate a password (44 random bytes in hexadecimal) that is RSA encrypted using the public key retrieved from the C2 server. The resulting encrypted password is base64 encoded and just left there, though a line which is commented out suggests that it is intended to be sent to the C2 endpoint.
The remaining part of the code is responsible for encrypting recursively, using AES-256-CBC, all files starting at certain point in the file system. The starting point is hardcoded in a variable (/home/"$USER"/Ransomware/TestFolder in this version. The function focuses exclusively on files with .txt or .png extension. After encrypting them, the original files are first copied to a directory named Exfil, which is created in the user desktop, and then shredded. When this process concludes, the Exfil directory with the copy of all the original files is zipped and then also shredded. The process concludes by shredding the password file used for encryption (both the plaintext and the encrypted file) and the public key.
This seems to be just a premature PoC exploring ransomware techniques in Bash for learning or demonstration purposes. Some parts of the code are clearly unfinished, while others have not been thought out properly. For example,
it does not peform any dependency checking and, although openssl is installed by default in most distributions, it's a good practice to check that it is available before using it. Furthermore, the command used to encrypt the encryption password (openssl rsautl) has been deprecated. You should use openssl-pkeyutl instead.
Anubis encrypts just .txt and .png files, which does not make much sense for a real sample. This could be changed or extended to cover more file types, but the way this is currently done suggests the code has not been designed to easily support multiple arbitrary file types.
The communication with the C2 endpoint is flawed. The encryption password generated for a victim is sent separately from the victim's fingerprint. This can results in ambiguities if two or more victims send those messages within a short time window. In addition, having the C2 endpoint hardcoded throughout the code in multiple functions is prone to errors.
Something really striking is the use of the -v flag for the shred command, which makes it verbose. This, together with the several echo commands througout the code reinforces the view that this is just a PoC. On top of that, the tar ball with the original files (Exvil.zip) is neither leaked not deleted, which does not make much sense.
Finally, the sample has a bug in the way it handles files before encrypting them. Files are copied to the Exfil folder without keeping their original full paths. This will result in collisions for files with the same name located in different user directories.