{
	"id": "57834c15-01f1-456a-b9c0-180be2dbfc3c",
	"created_at": "2026-04-06T00:17:21.407686Z",
	"updated_at": "2026-04-10T13:12:03.208721Z",
	"deleted_at": null,
	"sha1_hash": "549a8254edd6fd9204baa4a09c98ace755a75389",
	"title": "AvosLocker Ransomware Linux Version Analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 415193,
	"plain_text": "AvosLocker Ransomware Linux Version Analysis\r\nArchived: 2026-04-05 20:21:33 UTC\r\nIntroduction\r\nOver the last few months, several cyber gangs (BlackCat, Hive, Revil, etc.) have built Linux versions of their ransomware,\r\nspecifically targeting the VMware ESXi. The reason is that a single command could encrypt all the data contained on the\r\nvirtual machines. In autumn 2021, the Avoslocker operators announced their new Linux variant of AvosLocker. The sample\r\nhas been publicly available since January 2022.\r\nThis article is a detailed analysis of the Avoslinux piece of ransomware. The main objectives were to show the differences\r\nwith the Windows variant, to understand the encryption mechanisms and to see if any anti-reverse engineering techniques\r\nwere used.\r\nELF Analysis\r\nThe analyzed sample was found on the public platform MalwareBazaar and its sha256sum is\r\n10ab76cd6d6b50d26fde5fe54e8d80fceeb744de8dbafddff470939fac6a98c4 . Based on the ELF header, it was compiled with\r\nGCC 4.4.7.\r\n$ readelf -p .comment 10ab76cd6d6b50d26fde5fe54e8d80fceeb744de8dbafddff470939fac6a98c4.elf\r\nString dump of section '.comment':\r\n [ 0] GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-23)\r\nObviously, the binary is stripped and does not contain any symbols:\r\n$ nm 10ab76cd6d6b50d26fde5fe54e8d80fceeb744de8dbafddff470939fac6a98c4.elf\r\nnm: 10ab76cd6d6b50d26fde5fe54e8d80fceeb744de8dbafddff470939fac6a98c4.elf: no symbols\r\nThe ELF header also contains the sections .ctors and .dtors . The .ctors section contains a list of functions ran\r\nbefore the main function to initialize dynamic non-local variables.\r\n$ readelf -S ./10ab76cd6d6b50d26fde5fe54e8d80fceeb744de8dbafddff470939fac6a98c4.elf\r\nSection Headers:\r\n [Nr] Name Type Address Offset\r\n Size EntSize Flags Link Info Align\r\n [ 0] NULL 0000000000000000 00000000\r\n 0000000000000000 0000000000000000 0 0 0\r\n [ 1] .interp PROGBITS 0000000000400200 00000200\r\n 000000000000001c 0000000000000000 A 0 0 1\r\n....\r\nsnip\r\n....\r\n [19] .ctors PROGBITS 0000000000757000 00157000\r\n 00000000000000a0 0000000000000000 WA 0 0 8\r\n [20] .dtors PROGBITS 00000000007570a0 001570a0\r\n 0000000000000010 0000000000000000 WA 0 0 8\r\nThe last constructor function called initializes three strings, the ransom notes, the sample ID, and base64 strings:\r\nhttps://blog.lexfo.fr/Avoslocker.html\r\nPage 1 of 6\n\nransom_notes\r\nThe decoded base64 strings are 88-byte long and at first sight I couldn't figure out what it was.\r\n$echo -en \"MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAE9U+h7UA0Do9mVDFVJM9Gj5Qi/5zn2b/5dH9qFMApEmVngoc4zlLk49U1iWc2l+in2CtyQb+/s+JKvy\r\n00000000: 3056 3010 0607 2a86 48ce 3d02 0106 052b 0V0...*.H.=....+\r\n00000010: 8104 000a 0342 0004 f54f a1ed 4034 0e8f .....B...O..@4..\r\n00000020: 6654 3155 24cf 468f 9422 ff9c e7d9 bff9 fT1U$.F..\"......\r\n00000030: 747f 6a14 c029 1265 6782 8738 ce52 e4e3 t.j..).eg..8.R..\r\n00000040: d535 8967 3697 e8a7 d82b 7241 bfbf b3e2 .5.g6....+rA....\r\n00000050: 4abf 23ef 69c9 3d83 J.#.i.=.\r\nThen, by digging further in the binary, it appears to be an elliptic curve public key generated using the secp256k1 curve.\r\n$echo -en \"MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAE9U+h7UA0Do9mVDFVJM9Gj5Qi/5zn2b/5dH9qFMApEmVngoc4zlLk49U1iWc2l+in2CtyQb+/s+JKvy\r\n 0:d=0 hl=2 l= 86 cons: SEQUENCE\r\n 2:d=1 hl=2 l= 16 cons: SEQUENCE\r\n 4:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey\r\n 13:d=2 hl=2 l= 5 prim: OBJECT :secp256k1\r\n 20:d=1 hl=2 l= 66 prim: BIT STRING\r\n 0000 - 00 04 f5 4f a1 ed 40 34-0e 8f 66 54 31 55 24 cf ...O..@4..fT1U$.\r\n 0010 - 46 8f 94 22 ff 9c e7 d9-bf f9 74 7f 6a 14 c0 29 F..\"......t.j..)\r\n 0020 - 12 65 67 82 87 38 ce 52-e4 e3 d5 35 89 67 36 97 .eg..8.R...5.g6.\r\n 0030 - e8 a7 d8 2b 72 41 bf bf-b3 e2 4a bf 23 ef 69 c9 ...+rA....J.#.i.\r\n 0040 - 3d 83 =.\r\nFinally, three objects are initialized, two of them will hold a public and private key, and one is for the random generator.\r\nThese objects come from the crypto++ library.\r\nhttps://blog.lexfo.fr/Avoslocker.html\r\nPage 2 of 6\n\nctors_object_init\r\nMain function\r\nNo technique has been set up to obfuscate and protect the ransomware. The ransomware is basic and accepts two\r\nparameters, the number of threads to be used and the directories to encrypt:\r\nprogram_helper\r\nIf one of the given paths contains the strings \"esxi\" or \"vmfs\", a global variable is set to true and the running VMs (virtual\r\nmachines) are killed using the esxcli command line:\r\nkilling_ESXi\r\nFinally, it will browse the given lists of directories recursively, load the attackers' public key and build a list of files that the\r\nencryption thread routine will consume.\r\nmain_encryption_flow\r\nGenerating the list of files to encrypt\r\nThe function that builds the list of files to encrypt is simple. First, it calls \"opendir\" with the directory path name to encrypt,\r\nand then, using \"readdir\", it iterates through the files in the directory. If it is a regular file and the name is not\r\n\"README_FOR_RESTORE\" or it does not end with the \".avoslinux\" or \".avos2\" extension, it is added to the global list. If\r\nthe esxi global variable is set to true, only files that end with \".vmdk\", \".vmem\", \".vswp\", \".vmsn\" or \".log\" are added to the\r\nlist:\r\nhttps://blog.lexfo.fr/Avoslocker.html\r\nPage 3 of 6\n\nbuild_files_list_to_encrypt\r\nUnlike most Windows pieces of ransomware, that only encrypt data files based on their extension name using a whitelist or\r\na blacklist, this Linux variant may encrypt all the files, including system files.\r\nLoad the attackers' public key\r\nBecause the ransomware uses the crypto++ library, we recognize the particular concept of filters and pipes used by the\r\nlibrary in the reversed code. Similarly to Unix, Pipes allows data flows from a source to a sink and filters them to transform\r\nthem. The original function that decodes and loads the base64 attackers' public key would probably look like this:\r\nAutoSeededRandomPool prng;\r\nstring encoded = \"MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAE9U+h7UA0Do9mVDFVJM9Gj5Qi/5zn2b/5dH9qFMApEmVngoc4zlLk49U1iWc2l+in2CtyQb+/\r\nstring decoded;\r\nStringSource ss(encoded, true, new Base64Decoder( new StringSink(decoded)));\r\nECIES\u003cECP\u003e::Encryptor e0;\r\ne0.AccessPublicKey().Load(decoded);\r\ne0.GetPublicKey().ThrowIfInvalid(prng, 3); // Validate the public key\r\nload_attackers_public_elliptic_curvre_key\r\nEncryption\r\nTo encrypt files on the disk, Avoslinux uses the Salsa20 stream ciphers using the 12-round variant. For each file to encrypt,\r\nit generates a 32-byte long Salsa key and an 8-byte long nonce.\r\nhttps://blog.lexfo.fr/Avoslocker.html\r\nPage 4 of 6\n\ngen_salsa_key_nonce\r\nThe generated key and nonce are passed to the function \"ECIES_n_b64\" to be encrypted using the ECIES (Elliptic Curve\r\nIntegrated Encryption Scheme) crypto scheme, and then base64-encoded.\r\nECIES_encrypt_key_and_nonce\r\nThe function would probably look like this:\r\nstring key_nonce;\r\nStringSource ss1 (key_nonce, true, new PK_EncryptorFilter(prng, e0, new Base64Encoder( new StringSink(b64_ecies_key_nonce)\r\nThe ECIES-encrypted output is bigger than the original: 125-byte long. Based on the crypto++ ECIES documentation, \"The\r\noutput of the encryption function is the tuple {K,C,T}, where K is the encrypted common secret, C is the ciphertext, and T is\r\nthe authentication tag.\"\r\nThe number of Salsa rounds is set:\r\nset_salsa_rounds_and_key\r\nThe file is encrypted using the Salsa20/12 algorithm, and the key with the previously encrypted nonce (ECIES and base64)\r\nis appended to the end of the file.\r\nhttps://blog.lexfo.fr/Avoslocker.html\r\nPage 5 of 6\n\nsalsa20/12 encrypting\r\nThen, the file is renamed by appending the \".avoslinux\" extension to the file.\r\nFile renamed\r\nFinally, the Salsa key and the nonce are erased from the memory:\r\nSalsa key and nonce zeroing\r\nConclusion\r\nThe Linux variant is very simple and has no special features like network encryption or any anti-reverse techniques to\r\nobfuscate codes. The encryption process is not common for a piece of ransomware and it is different from the Windows\r\nvariant, which uses the RSA and AES combination. Another thing to note is that unlike most Windows pieces of\r\nransomware, that only encrypt data files based on their extension name using a whitelist or a blacklist, this Linux variant\r\nmay encrypt all the files, including system files.\r\nIOCs\r\nSample hash\r\nSHA256: 10ab76cd6d6b50d26fde5fe54e8d80fceeb744de8dbafddff470939fac6a98c4\r\nSHA1: 9c8f5c136590a08a3103ba3e988073cfd5779519\r\nMD5: f659d1d15d2e0f3bd87379f8e88c6b42\r\nElliptic curve public key\r\nMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAE9U+h7UA0Do9mVDFVJM9Gj5Qi/5zn2b/5dH9qFMApEmVngoc4zlLk49U1iWc2l+in2CtyQb\r\nSource: https://blog.lexfo.fr/Avoslocker.html\r\nhttps://blog.lexfo.fr/Avoslocker.html\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.lexfo.fr/Avoslocker.html"
	],
	"report_names": [
		"Avoslocker.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434641,
	"ts_updated_at": 1775826723,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/549a8254edd6fd9204baa4a09c98ace755a75389.pdf",
		"text": "https://archive.orkl.eu/549a8254edd6fd9204baa4a09c98ace755a75389.txt",
		"img": "https://archive.orkl.eu/549a8254edd6fd9204baa4a09c98ace755a75389.jpg"
	}
}