{
	"id": "928c70df-0289-46d7-8f55-5a50e0be7721",
	"created_at": "2026-04-06T00:19:28.474801Z",
	"updated_at": "2026-04-10T03:21:11.79623Z",
	"deleted_at": null,
	"sha1_hash": "a68552a9f7e194a061557eca6e25a49d76004fe4",
	"title": "AvosLocker enters the ransomware scene, asks for partners",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1523099,
	"plain_text": "AvosLocker enters the ransomware scene, asks for partners\r\nBy Mark Stockley\r\nPublished: 2021-07-22 · Archived: 2026-04-05 18:05:48 UTC\r\nThis blog post was authored by Hasherezade\r\nIn mid-July we responded to an incident that involved an attack on a Microsoft Exchange server. The threat actor\r\nused this entry point to get into a Domain Controller and then leveraged it as a springboard to deploy ransomware.\r\nWhile examining the ransomware payload, we noticed it was a new variant which we had not heard of before. In\r\nthis blog we will take a look at AvosLocker a solid, yet not too fancy new ransomware family that has already\r\nclaimed several victims.\r\nArticle continues below this ad.\r\nThis type of ransomware attack is unfortunately all too common these days and has wreaked havoc across many\r\nindustries. With the disappearance of the infamous REvil, it is possible new threat actors are actively looking to\r\nfill the void.\r\nNew ransomware, looking for partners\r\nAvos is a relatively new ransomware, that was observed in late June and early July. Its authors started searching\r\nfor affiliates through various underground forums. They announced a recruitment for “pentesters with Active\r\nDirectory network experience” and “access brokers” which suggests that they want to cooperate with people who\r\nhave remote access to hacked infrastructure.\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 1 of 21\n\nIn the other advert they describe the product they offer: a multi-threaded ransomware written in C++:\r\nThey offer not only the malware, but also help in managing the communication with the victim, and hosting of the\r\ndata stolen during the operation. Soon, some victims of this ransomware started to emerge.\r\nBehavioral Analysis\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 2 of 21\n\nAvosLocker is ran manually by the attacker who remotely accessed the machine. For this reason, it is not trying to\r\nbe stealthy during its run. In default mode, it works as a console application reporting details about its progress on\r\nscreen.\r\nA sample log from the run (shortened):\r\n drive: C: drive: D: Threads init Map: C: Searching files on: C:* file: C:autoexec.bat Map: D:\r\nLooking at the log, we can see that the ransomware first “maps” the accessible drives by listing all their files.\r\nAfter that it goes to the encryption. The files are selected for encryption depending on their extensions.\r\nThe files that have been encrypted by AvosLocker can be identified with .avos extension appended to the original\r\nfilename. While the content is unreadable, at the end we find a Base64-encoded block added:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 3 of 21\n\nWe can assume that this Base64-encoded data contains RSA-protected AES key that was used for encrypting this\r\nfile. Each attacked directory has a ransom note dropped in it, named GET_YOUR_FILES_BACK.txt:\r\nInterestingly, the ID is not generated during the deployment, but hardcoded in the sample (which we can see easily\r\nby viewing the sample strings). This may mean that the distributors generate a sample per victim.\r\nThe link given in the ransom note guides to the Onion website, requesting the ID, that was also in the note:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 4 of 21\n\nUpon the ID submission, the victim is presented with the individual panel:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 5 of 21\n\nIn addition to the casual threats about increasing the price after the deadline has passed, this ransomware adds\r\nblackmail by doxing. The additional website titled “Press releases” is provided to prove that those aren’t just\r\nempty threats:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 6 of 21\n\nVisual analysis\r\nVisualizing the content of the encrypted files shows their high entropy. No patterns from the original file content\r\nwere preserved. Example:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 7 of 21\n\nThose properties suggest that a strong encryption algorithm was used, probably in a CBC mode (Cipher Block\r\nChaining).\r\nAlso, the same plaintext files have been encrypted into different ciphertext output. This suggests that for each file\r\na new key (or at least a new initialization vector) was generated.\r\nInside\r\nThis ransomware is dedicated to be deployed by the attacker manually on the hacked machines. This purpose is\r\nreflected in the design. In contrast to most malware, AvosLocker comes without any protective (crypter) layer. Yet,\r\nit’s not completely defenseless: all the strings, and some of the APIs, are obfuscated in order to evade static\r\ndetection. Yet, during its execution, it yells out on the console the logs of the performed actions, so that the\r\nattacker could observe in the real time what the program is doing.\r\nExecution flow\r\nThe execution starts in the main function:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 8 of 21\n\nFirst, the malware checks if it was provided with the optional commandline arguments. By supplying them, the\r\nattacker can enable/disable some of the features.\r\nThen, the mutex name is decoded (“ievah8eVki3Ho4oo”), and its presence is checked. It is done in order to\r\nprevent the ransomware from being run more than once at the time. If the mutex already exists, the execution\r\nterminates.\r\nThis malware may come with a hardcoded RSA Public Key of the attacker. This key will be further used for\r\nencrypting individual AES keys, used for encrypting files. Yet, the presence of the Public Key is optional. In case\r\nif it wasn’t provided, the application will generate a new key pair.\r\nAfter this preparation, the malware proceeds to encrypt files. Depending on the argument given, it may encrypt\r\nnetwork resources. Then, unconditionally, it encrypts drives. The encryption operations are run in new threads.\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 9 of 21\n\nAfter the encryption was done, it prints information for the attacker. Then, all the running threads are finalized. At\r\nthe end the malware prints the summary about how long it took to encrypt available resources.\r\nArguments\r\nBy default it runs as a console application, yet the console can be hidden by supplying a specific commandline\r\nargument: ‘h’ (hide). There is also a commandline argument allowing to opt out encryption of network resources:\r\n‘n’ (network).\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 10 of 21\n\nString obfuscation\r\nAs mentioned before, Avos uses string obfuscation. All the strings are obfuscated by XOR with the given key, and\r\ndeobfuscated just before use. Although the algorithm is simple, the way it implements it is especially tedious to\r\ncounteract. Rather than having one, central deobfuscating function, each of such operations is done inline.\r\nExamples:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 11 of 21\n\nAPI obfuscation\r\nAs well as the strings, some of the APIs used by the malware are obfuscated. Functions are retrieved by their\r\nchecksums, which is a common trick used by malware, in order to avoid hardcoding names of the functions which\r\nmay rise suspicions. Which is lesser common though, is that the function resolving the API is also used as an\r\ninline.\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 12 of 21\n\nThis way of obfuscating API calls not only hides the used functions, but also adds volume to the code, making it\r\nmore unreadable and difficult to follow.\r\nYet, it is easy to reveal the used function names with the help of tracing and tagging. Example – the above\r\nobfuscated function resolved to GetLogicalDrives:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 13 of 21\n\nAttacked targets\r\nThe ransomware encrypts all attached drives.\r\nAdditionally, unless the argument (‘n’) was given from the commandline, the ransomware proceeds to encrypt\r\nnetwork shares. Available resources are being enumerated in a loop:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 14 of 21\n\nThe accessible network shares are getting encrypted:\r\nFrom each medium, the files are first added to the list. Then, the created list is processed by the encryption\r\nroutine.\r\nFiles with the following extensions are being attacked:\r\nndoc docx xls xlsx ppt pptx pst ost msg eml vsd vsdx txt csv rtf wks wk1 pdf dwg onetoc2 snt jpeg jpg\r\nHow the encryption works\r\nAvos uses two strong encryption algorithms. Symmetric: AES – to encrypt files, and asymmetric: RSA – to\r\nencrypt the generated AES keys. This is a very common combo which provides strong data protection. It is also\r\noften used by variety of ransomware.\r\nThe RSA Key\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 15 of 21\n\nAs mentioned before, the RSA Public key may be hardcoded in the Avos sample. In the analyzed case, the\r\nfollowing Public Key was hardcoded:\r\nIn case of lack of thereof, a new keypair is generated. The Public Key is stored for the further use, and the private\r\nkey is logged on the screen, as the information for the attacker.\r\nThe same Private Key is also dumped in each ransom note, instead of the ID:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 16 of 21\n\nThis suggests that this mode was created only for testing purposes, and it not intended to be used on victims. Only\r\nthe mode with the Public Key hardcoded is usable in real attack scenarios.\r\nFile encryption\r\nBefore the malware proceeds to encrypt particular file, it first retrieves a list of associated processes, that may be\r\nblocking the access:\r\nThe list is retrieved with the help of RmGetList:\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 17 of 21\n\nIf any processes has been found, they are being terminated. Then the malware proceeds with encryption.\r\nFor each file, an AES key generated by a previously deployed routine is retrieved and used to initialize AES\r\ncontext.\r\nAfter that, the AES encryption is applied on the file content.\r\nThe file is encrypted in-place (without creating additional copy), in 64-byte long chunks. A chunk of a plaintext is\r\nread, encrypted, and written back to the original file.\r\nAs we observed during the behavioral analysis, the block with the RSA encrypted, base64-encoded AES key is\r\nwritten at the end.\r\nAES key generation\r\nThe generation of random keys is deployed in the function enumerating the files of a particular directory, prior to\r\nthe encryption. For each listed file a new key and Initialization Vector are generated, and stored for further use.\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 18 of 21\n\nAs default, the cryptographically strong random generator is used. However, if for some reason this strong\r\ngenerator fails, it falls back to the naive generator (based on the standard rand() function).\r\nThis may render a flaw in the full encryption scheme. However, the chance of the strong random generator failing\r\nis too small to consider worth the attention in real life scenarios.\r\nThe malware fetches a buffer of 512 random bytes per each file, and then generates out of this a 64-character long\r\nstring for the key, and a 32-characters long string for the Initialization Vector.\r\nThis key and the initialization vector are further passed to a function initializing AES context. Although the\r\ncreated key is 64 bytes long, we must note that only 32 first characters are going to be used. Similarly, in the case\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 19 of 21\n\nof the Initialization Vector, only first 16 bytes matter. Both strings are treated as ASCII.\r\nPreview of the file encrypted with the presented key/IV set:\r\nExample – a ChyberChief recipe decrypting the aforementioned file, using the key and initialization vector\r\ndumped from the memory:\r\nValid implementation, unimpressive design\r\nAvosLocker does not distinguish itself much from other ransomware (apart from being unusually noisy). All its\r\nfeatures are average. Its encryption scheme seems implemented correctly, so recovering the data is not possible\r\nwithout obtaining the original Private Key for a particular sample. It also uses a well-established pair of\r\nalgorithms: RSA and AES. Although it contains some inconsistencies in the implementation, they do not impact\r\nthe main goals of this malware.\r\nWe didn’t find in the sample any routines responsible for uploading the stolen files. Yet, since the model of the\r\ndelivery of this ransomware assumes manual access, it is possible that the data exfiltration is done manually by the\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 20 of 21\n\nattackers.\r\nAvosLocker meets its objective by being a simple tool assisting in the manual attacks, and creating the expected\r\ndamage.\r\nProtection and recommendations\r\nKeep software up-to-date and turn on automatic updates whenever possible\r\nEnforce strong password policies and multi-factor authentication (MFA)\r\nPerform backups and periodically test restoring them\r\nReduce attack surface by removing unused or unnecessary services\r\nMitigate brute-force attacks (this is a feature in our Nebula product) \r\nEnable tamper protection to prevent attackers from uninstalling your security software (this is a feature in\r\nour Nebula product)\r\nAvosLocker is detected without specific signatures by Malwarebytes’ anti-ransomware technology:\r\nIndicators of Compromise\r\n43b7a60c0ef8b4af001f45a0c57410b7374b1d75a6811e0dfc86e4d60f503856\r\nSource: https://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nhttps://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.malwarebytes.com/blog/threat-intelligence/2021/07/avoslocker-enters-the-ransomware-scene-asks-for-partners"
	],
	"report_names": [
		"avoslocker-enters-the-ransomware-scene-asks-for-partners"
	],
	"threat_actors": [],
	"ts_created_at": 1775434768,
	"ts_updated_at": 1775791271,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a68552a9f7e194a061557eca6e25a49d76004fe4.pdf",
		"text": "https://archive.orkl.eu/a68552a9f7e194a061557eca6e25a49d76004fe4.txt",
		"img": "https://archive.orkl.eu/a68552a9f7e194a061557eca6e25a49d76004fe4.jpg"
	}
}