{
	"id": "2ebf37c6-2dc6-4264-9f39-4ec16c6383a8",
	"created_at": "2026-05-07T02:43:21.989795Z",
	"updated_at": "2026-05-07T02:44:11.087278Z",
	"deleted_at": null,
	"sha1_hash": "146088c1813af96a55e134f877dec5bdd95b324e",
	"title": "Pulling the Curtains on Azov Ransomware: Not a Skidsware but Polymorphic Wiper",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 131602,
	"plain_text": "Pulling the Curtains on Azov Ransomware: Not a Skidsware but\r\nPolymorphic Wiper\r\nBy itayc\r\nPublished: 2022-12-12 · Archived: 2026-05-07 02:17:26 UTC\r\nHighlights:\r\nCheck Point Research (CPR) provides under-the-hood details of its analysis of the infamous Azov\r\nRansomware\r\nInvestigation shows that Azov is capable of modifying certain 64-bit executables to execute its own code\r\nAzov is designed to inflict impeccable damage to the infected machine it runs on\r\nCPR sees over 17K of Azov-related samples submitted to VirusTotal\r\nIntroduction\r\nDuring the past few weeks, we have shared the preliminary results of our investigation of the Azov ransomware\r\non social media, as well as with Bleeping Computer. The below report goes into more detail regarding the internal\r\nworkings of Azov ransomware and its technical features.\r\nBackground \u0026 Key Findings\r\nAzov first came to the attention of the information security community as a payload of the SmokeLoader botnet,\r\ncommonly found in fake pirated software and crack sites.\r\nOne thing that sets Azov apart from your garden-variety ransomware is its modification of certain 64-bit\r\nexecutables to execute its own code. Before the advent of the modern-day internet, this behavior used to be the\r\nroyal road for the proliferation of malware; because of this, to this day, it remains the textbook definition of\r\n“computer virus” (a fact dearly beloved by industry pedants, and equally resented by everyone else). The\r\nmodification of executables is done using polymorphic code, so as not to be potentially foiled by static signatures,\r\nand is also applied to 64-bit executables, which the average malware author would not have bothered with.\r\nThis aggressive polymorphic infection of victim executables has led to a deluge of publicly available files infected\r\nwith Azov. Every day, hundreds of new Azov-related samples are submitted to VirusTotal, which as of November\r\n2022, has already exceeded 17,000. Using a hand-crafted query, it is possible to search for only proper Azov\r\nsamples, without the trojanized binaries.\r\nVirusTotal query to search for Azov-related samples:\r\nPlain text\r\nCopy to clipboard\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 1 of 12\n\nOpen code in new window\r\nEnlighterJS 3 Syntax Highlighter\r\n(behaviour:'Local\\\\\\\\Kasimir_*' OR behaviour:'Local\\\\\\\\azov') AND (behaviour_files:'RESTORE_FILES' OR\r\nbehaviour_registry:'rdpclient.exe')\r\n(behaviour:'Local\\\\\\\\Kasimir_*' OR behaviour:'Local\\\\\\\\azov') AND (behaviour_files:'RESTORE_FILES' OR\r\nbehaviour_registry:'rdpclient.exe')\r\n(behaviour:'Local\\\\\\\\Kasimir_*' OR behaviour:'Local\\\\\\\\azov') AND (behaviour_files:'RESTORE_FILES' OR\r\nFigure 1: VirusTotal query - Azov-related samples\r\nFigure 1: VirusTotal query – Azov-related samples\r\nVirusTotal query to search for only proper Azov samples, without the trojanized binaries:\r\nPlain text\r\nCopy to clipboard\r\nOpen code in new window\r\nEnlighterJS 3 Syntax Highlighter\r\n(behaviour:'Local\\\\\\\\Kasimir_*' OR behaviour:'Local\\\\\\\\azov') AND (behaviour_files:'RESTORE_FILES' OR\r\nbehaviour_registry:'rdpclient.exe') AND detectiteasy:\"Compiler: FASM*\"\r\n(behaviour:'Local\\\\\\\\Kasimir_*' OR behaviour:'Local\\\\\\\\azov') AND (behaviour_files:'RESTORE_FILES' OR\r\nbehaviour_registry:'rdpclient.exe') AND detectiteasy:\"Compiler: FASM*\"\r\n(behaviour:'Local\\\\\\\\Kasimir_*' OR behaviour:'Local\\\\\\\\azov') AND (behaviour_files:'RESTORE_FILES' OR\r\nFigure 2: VirusTotal query - only original Azov samples\r\nFigure 2: VirusTotal query – only original Azov samples\r\nThe abundance of samples has allowed us to distinguish two different versions of Azov, one older and one slightly\r\nnewer. These two versions share most of their capabilities, but the newer version uses a different ransom note, as\r\nwell as a different file extension for destroyed files ( .azov ).\r\nFigure 3: Ransom note of the newer version of Azov\r\nFigure 3: Ransom note of the newer version of Azov\r\nFigure 4: Ransom note of the older version of Azov\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 2 of 12\n\nFigure 4: Ransom note of the older version of Azov\r\nThe text on the left is remarkable for its stealth delivery of various Kremlin talking points (in particular, the threat\r\nof nuclear war). For any readers feeling compelled by the text on the right, we recommend Nicky Case’s The\r\nEvolution of Trust.\r\nTechnical Analysis: Highlights\r\nManually crafted in assembly using FASM\r\nUsing anti-analysis and code obfuscation techniques\r\nMulti-threaded intermittent overwriting (looping 666 bytes) of original data content\r\nPolymorphic way of backdooring 64-bit “.exe” files across the compromised system\r\n“logic bomb” set to detonate at a certain time. The sample analyzed below was set to detonate at 10-27-\r\n2022 10:14:30 AM UTC\r\nNo network activity and no data exfiltration\r\nUsing the SmokeLoader botnet and trojanized programs to spread\r\nEffective, fast, and unfortunately unrecoverable data wiper\r\nFull Technical analysis\r\nWe focus on the original sample of the newer Azov version (SHA256:\r\n650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e — as pointed out above, there is no\r\nmajor difference in functionality compared to the older version). This is a 64-bit portable executable file that has\r\nbeen assembled with FASM (flat assembler), with only 1 section .code (r+x), and without any imports.\r\nFigure 5: Detection of FASM compiler\r\nFigure 5: Detection of FASM compiler\r\nFigure 6: Only 1 section “.code” and no Imports\r\nFigure 6: Only 1 section “.code” and no Imports\r\nWhen we think of a person writing code directly in assembly language, we think of a vulnerability researcher\r\ncarefully piecing together a payload, a hard-boiled engineer creating a real-time application, or maybe an\r\nundergraduate student undergoing a rite of passage. We certainly do not immediately think of a ransomware\r\nauthor creating ransomware (indeed, we suspect most ransomware authors would go the opposite direction and\r\nwrite it all in Python, if they feasibly could). We assume this began with the author having to deal with code at the\r\nassembly level anyway to carry out their “infect executables” plan, and then spun out of control.\r\nThe .code section has three parts, which are most easily seen by looking at its entropy. First, there is a high-entropy part containing the encrypted shellcode. It is followed by plain code implementing the unpacking routine,\r\nand then the last part, with very low entropy, appears to consist of plain strings used to construct the ransom note.\r\nFigure 7: Entropy of the “.code” section\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 3 of 12\n\nFigure 7: Entropy of the “.code” section\r\nUnpacking Routine\r\nAs the whole code of Azov is assembly manually crafted for the purpose of being obtuse, it is necessary to do\r\nsome IDA magic and cleanup to shape the code into a state where it can be decompiled and understood. Once this\r\nis done, the procedure start_0() becomes visible. This code unpacks shellcode into newly allocated memory\r\nand then transfers execution to it.\r\nFigure 8: Entry function start_0\r\nFigure 8: Entry function start_0\r\nThe unpacking routine in the function AllocAndDecryptShellcode() is intentionally created to look more\r\nsophisticated than it is. But in reality, it is a simple seeded decryption algorithm using a combination of xor and\r\nrol , where key = 0x15C13 .\r\nFigure 9: Unpacking routine in the function AllocAndDecryptShellcode\r\nFigure 9: Unpacking routine in the function AllocAndDecryptShellcode\r\nWe provide below a Python implementation of the simplified routine logic:\r\nPlain text\r\nCopy to clipboard\r\nOpen code in new window\r\nEnlighterJS 3 Syntax Highlighter\r\nimport pefile, malduck\r\npe = pefile.PE('Azov_Ransomware.exe')\r\nencrypted_shellcode = pe.sections[0].get_data()[5:0x4615+5]\r\ndecrypted_shellcode = bytearray(encrypted_shellcode)\r\nkey = 0x15C13\r\nfor j in range(0x3FDF,-1,-1):\r\ndecrypted_shellcode[j] ^= malduck.BYTE(key)\r\nkey = malduck.rol(key + 0x92819200, 1, 32)\r\nprint(decrypted_shellcode)\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 4 of 12\n\nimport pefile, malduck pe = pefile.PE('Azov_Ransomware.exe') encrypted_shellcode = pe.sections[0].get_data()\r\n[5:0x4615+5] decrypted_shellcode = bytearray(encrypted_shellcode) key = 0x15C13 for j in\r\nrange(0x3FDF,-1,-1): decrypted_shellcode[j] ^= malduck.BYTE(key) key = malduck.rol(key + 0x92819200, 1,\r\n32) print(decrypted_shellcode)\r\nimport pefile, malduck\r\npe = pefile.PE('Azov_Ransomware.exe')\r\nencrypted_shellcode = pe.sections[0].get_data()[5:0x4615+5]\r\ndecrypted_shellcode = bytearray(encrypted_shellcode)\r\nkey = 0x15C13\r\nfor j in range(0x3FDF,-1,-1):\r\n decrypted_shellcode[j] ^= malduck.BYTE(key)\r\n key = malduck.rol(key + 0x92819200, 1, 32)\r\nprint(decrypted_shellcode)\r\nThe next stage is split into two main routines: one in charge of wiping files and the other in charge of backdooring\r\nexecutables.\r\nFigure 10: Transferring of execution to wiping and backdooring logic\r\nFigure 10: Transferring of execution to wiping and backdooring logic\r\nWiping Routine\r\nThe wiping routine begins by creating a mutex ( Local\\\\\\\\azov ) to verify that two instances of the malware are\r\nnot running concurrently.\r\nFigure 11: Wiping routine - mutex creation\r\nFigure 11: Wiping routine – mutex creation\r\nIf the mutex handle is successfully obtained, Azov creates persistence by trojanizing (similar to the backdooring\r\nroutine) the 64-bit Windows system binary msiexec.exe or perfmon.exe and saving it as rdpclient.exe . A\r\nregistry entry at SOFTWARE\\\\\\\\Microsoft\\\\\\\\Windows\\\\\\\\CurrentVersion\\\\\\\\Run is created pointing to the newly\r\ncreated file.\r\nFigure 12: Persistence creation\r\nFigure 12: Persistence creation\r\nThe wiping procedure uses a trigger time – there is a loop where the analyzed sample checks system time, and if it\r\nis not equal to or larger than the trigger time, it sleeps 10s and loops again. Regarding the analyzed sample in the\r\nTwitter post, the trigger time was 10/27/2022 at 10:14:30 AM UTC.\r\nFigure 13: Trigger time set to 10/27/2022 10:14:30 AM UTC\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 5 of 12\n\nFigure 13: Trigger time set to 10/27/2022 10:14:30 AM UTC\r\nOnce this logic bomb triggers, the wiper logic iterates over all machine directories and executes the wiping routine\r\non each one, avoiding certain hard-coded system paths and file extensions.\r\nFigure 14: System paths omitted from wiping and backdooring\r\nFigure 14: System paths omitted from wiping and backdooring\r\nFigure 15: File extensions omitted from wiping\r\nFigure 15: File extensions omitted from wiping\r\nEach file is wiped “intermittently”, by which we mean a block of 666 bytes is overwritten with random noise, then\r\nan identically-sized block is left intact, then a block is overwritten again, and so on — until the hard limit of 4GB\r\nis reached, at which point all further data is left intact. As a random source, the sample uses an uninitialized local\r\nvariable (e.g., char buffer[666]; ) which in practice means random stack memory content.\r\nFigure 16: Intermittent data wiping\r\nFigure 16: Intermittent data wiping\r\nFigure 17: Example trace of data wiping routine\r\nFigure 17: Example trace of data wiping routine\r\nOnce the wiping is finished, the new file extension .azov is added to the original filename. The typical file\r\nstructure of a wiped file can be seen below.\r\nFigure 18: Example structure of a wiped file\r\nFigure 18: Example structure of a wiped file\r\nBackdooring Routine\r\nBefore traversing the filesystem to search for files to be backdoored, a mutex named Local\\\\\\\\Kasimir_%c is\r\ncreated, with the %c replaced with the letter of the drive being processed.\r\nFigure 19: Backdooring routine - mutex creation\r\nFigure 19: Backdooring routine – mutex creation\r\nThe function TryToBackdoorExeFile() is responsible for backdooring 64-bit “.exe” files that meet certain\r\nconditions.\r\nFigure 20: Files passing pre-processing conditions go to the TryToBackdoorExeFile function\r\nFigure 20: Files passing pre-processing conditions go to the TryToBackdoorExeFile function\r\nThese specific conditions could be simplified as follows:\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 6 of 12\n\n1. Pre-processing conditions:\r\nIt is not a part of the exclude list of filesystem locations\r\nThe file extension is “.exe”\r\nThe file size is less than 20MB\r\n2. Processing conditions:\r\nThe file is a 64-bit executable file\r\nThe PE section containing the Entry Point has enough space for the shellcode implant to be injected\r\nin the way of preserving the original Entry Point of PE (the shellcode start address will be placed at\r\nthe address of the original Entry Point)\r\nFile size == PE size (PE size is manually calculated)\r\nThe processing conditions are all checked in the function TryToBackdoorExeFile() .\r\nFigure 21: Function TryToBackdoorExeFile\r\nFigure 21: Function TryToBackdoorExeFile\r\nOnce the file meets all pre-processing and processing conditions, it is considered suitable for backdooring and\r\npushed to function BackdoorExeFile() .\r\nFigure 22: Proximity graph of function TryToBackdoorExeFile\r\nFigure 22: Proximity graph of function TryToBackdoorExeFile\r\nThe function BackdoorExeFile() is responsible for the polymorphic backdooring of executable files. It first\r\nobtains the address of the original code section (usually the .text section) and randomly modifies its content in\r\nseveral locations. Before injecting the main blob of shellcode into the modified code section, certain constant\r\nvalues are changed, and the whole shellcode is re-encrypted with the same encryption algorithm and key as used\r\nduring the unpacking of the malware, described earlier. After the backdoored file is written back to disk, three\r\nencoded data structures are appended to its end, which are effectively resources needed for the ransomware to\r\nfunction (for instance, an obfuscated form of the ransom note).\r\nFigure 23: Proximity graph of function BackdoorExeFile\r\nFigure 23: Proximity graph of function BackdoorExeFile\r\nDespite the polymorphic backdooring, the encryption/decryption algorithm used during the unpacking and\r\nbackdooring is consistent and can be used for Azov detection.\r\nFigure 24: Re-encryption of the main blob of shellcode using the same algorithm and key as\r\nduring unpacking\r\nFigure 24: Re-encryption of the main blob of shellcode using the same algorithm and key as during unpacking\r\nAnti-analysis and code obfuscation techniques\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 7 of 12\n\nPreventing usage of software breakpoints – using routines that copy already decrypted and currently executing\r\nparts of shellcode to newly allocated memory and later transferring execution to it will sooner or later result in an\r\nexception if software breakpoints are set. In such situations, it is necessary to use hardware breakpoints.\r\nFigure 25: Anti-analysis technique preventing usage of software breakpoints\r\nFigure 25: Anti-analysis technique preventing usage of software breakpoints\r\nOpaque constants – replacing constants with a code routine producing the same resulting constant’s value. (This\r\ncan be repeatedly seen in routines responsible for calculating constant offsets rather than using them directly so\r\nthat a direct call can be replaced with an indirect call )\r\nFigure 26: Opaque constants\r\nFigure 26: Opaque constants\r\nSyntactic confusion – replacing an instruction with semantically equivalent instruction(s) that are not idiomatic, or\r\nare outright bloat. One example of this is found in the routine responsible for parsing the export directory; another\r\nis the repeated replacement of a call with a direct or indirect jmp . Both are pictured below.\r\nFigure 27: Syntactic bloat\r\nFigure 27: Syntactic bloat\r\nFigure 28: Usage of indirect and direct jumps in place of calls\r\nFigure 28: Usage of indirect and direct jumps in place of calls\r\nA simplified version of the assembly that parses the export directory can be seen below.\r\nPlain text\r\nCopy to clipboard\r\nOpen code in new window\r\nEnlighterJS 3 Syntax Highlighter\r\nand rdx, 0\r\nmov edx, [rax]\r\nmov rax, [rbp+moduleBase]\r\nadd rdx, rax\r\nmov [rbp+addressOfNames], rdx\r\nmov rcx, [rbp+exportDirectory]\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 8 of 12\n\nadd rcx, _IMAGE_EXPORT_DIRECTORY.AddressOfFunctions\r\nxor rdx, rdx\r\nmov edx, [rcx]\r\nadd rdx, rax\r\nmov [rbp+addressOfFunctions], rdx\r\nand rdx, 0 mov edx, [rax] mov rax, [rbp+moduleBase] add rdx, rax mov [rbp+addressOfNames], rdx mov rcx,\r\n[rbp+exportDirectory] add rcx, _IMAGE_EXPORT_DIRECTORY.AddressOfFunctions xor rdx, rdx mov edx,\r\n[rcx] add rdx, rax mov [rbp+addressOfFunctions], rdx\r\nand rdx, 0\r\nmov edx, [rax]\r\nmov rax, [rbp+moduleBase]\r\nadd rdx, rax\r\nmov [rbp+addressOfNames], rdx\r\nmov rcx, [rbp+exportDirectory]\r\nadd rcx, _IMAGE_EXPORT_DIRECTORY.AddressOfFunctions\r\nxor rdx, rdx\r\nmov edx, [rcx]\r\nadd rdx, rax\r\nmov [rbp+addressOfFunctions], rdx\r\nDead (junk) code – insertion of garbage bytes which results in no meaningful instructions or even no instructions\r\nat all.\r\nOpaque predicates – a jz/jnz that at first sight appears to be a conditional jump in practice has the condition\r\nalways met (or always not met) and effectively functions as an unconditional jump, confusing static analysis.\r\nThese two obfuscations can both be seen in the function FindGetProcAddress() .\r\nFigure 29: Garbage bytes insertion and Opaque predicate obfuscations\r\nFigure 29: Garbage bytes insertion and Opaque predicate obfuscations\r\nCall-Return Abuse – using push ret or call instead of a jmp .\r\nFigure 30: Control indirection\r\nFigure 30: Control indirection\r\nVolatile Homebrew IAT – A dynamically allocated structure containing API function addresses being used as\r\nnested structure, pushed as an argument to functions that need to use certain WIN API routines instead of using\r\nnormal imports.\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 9 of 12\n\nFigure 31: Dynamically created IAT-like structure being used as nested structure\r\nFigure 31: Dynamically created IAT-like structure being used as nested structure\r\nConclusion\r\nAlthough the Azov sample was considered skidsware when first encountered (likely because of the strangely\r\nformed ransom note), when probed further one finds very advanced techniques — manually crafted assembly,\r\ninjecting payloads into executables in order to backdoor them, and several anti-analysis tricks usually reserved for\r\nsecurity textbooks or high-profile brand-name cybercrime tools. Azov ransomware certainly ought to give the\r\ntypical reverse engineer a harder time than the average malware.\r\nIt is not our place to confidently ascribe a motive to the production and dissemination of this malware, though\r\nobviously, we can rule out the idea that anything in the newer ransom note was written in good faith (we shouldn’t\r\nhave to say this, but none of the listed people or organizations had anything to do with creating this ransomware).\r\nOne might simply write it off as the actions of a disturbed individual; though if one wanted to see this as an\r\negregious false flag meant to incite anger at Ukraine and troll victims more generally, they certainly would have a\r\nlot of evidence for that hypothesis, too. The number of already detected Azov-related samples is so large that if\r\nthere was ever an original target, it has long since been lost in the noise of indiscriminate infections.\r\nThe only thing we can say with certainty, and what has been confirmed by all this analysis, is that Azov is an\r\nadvanced malware designed to destroy the compromised system.\r\nCheck Point customers remain protected from the threats described in this blog, including all its variants.  Anti-Ransomware is offered as part of Harmony Endpoint, Check Point’s complete endpoint security solution.  Check\r\nPoint Provides Zero-Day Protection Across its Network, Cloud, Users and Access Security Solutions.\r\nIOCs\r\nOriginal Azov samples\r\nSHA256 Description\r\nb102ed1018de0b7faea37ca86f27ba3025c0c70f28417ac3e9ef09d32617f801\r\nThe old version\r\nof Azov\r\n650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e\r\nThe new\r\nversion of Azov\r\nYara\r\nPlain text\r\nCopy to clipboard\r\nOpen code in new window\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 10 of 12\n\nEnlighterJS 3 Syntax Highlighter\r\nimport \"pe\"\r\nrule ransomware_ZZ_azov_wiper {\r\nmeta:\r\ndescription = \"Detects original and backdoored files with new and old versions of azov ransomware - polymorphic\r\nwiper\"\r\nauthor = \"Jiri Vinopal (jiriv)\"\r\ndate = \"2022-11-14\"\r\nhash_azov_new = \"650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e\"\r\nhash_azov_old = \"b102ed1018de0b7faea37ca86f27ba3025c0c70f28417ac3e9ef09d32617f801\"\r\nstrings:\r\n// Opcodes of allocating and decrypting shellcode routine\r\n$unpacking_azov_new = { 48 83 ec ?? 58 48 01 c8 48 81 ec ?? ?? ?? ?? 48 83 ec ?? 40 80 e4 ?? c6 45 ?? 56 c6 45\r\n?? 69 c6 45 ?? 72 c6 45 ?? 74 c6 45 ?? 75 c6 45 ?? 61 c6 45 ?? 6c c6 45 ?? 41 c6 45 ?? 6c c6 45 ?? 6c c6 45 ?? 6f\r\nc6 45 ?? 63 c6 45 ?? 00 48 89 74 24 ?? 48 83 ec ?? 48 83 c4 ?? 48 8b 4c 24 ?? 48 8d 55 ?? ff d0 48 83 ec ?? 48 c7\r\n04 24 ?? ?? ?? ?? 48 83 c4 ?? 48 8b 4c 24 ?? 48 c7 c2 ?? ?? ?? ?? 49 c7 c0 ?? ?? ?? ?? 49 c7 c1 ?? ?? ?? ?? ff d0 48\r\nc7 c1 ?? ?? ?? ?? 4c 8d 0d ?? ?? ?? ?? 48 ff c9 41 8a 14 09 88 14 08 48 85 c9 75 ?? 48 c7 c1 ?? ?? ?? ?? 41 b9 ??\r\n?? ?? ?? 41 ba ?? ?? ?? ?? 48 ff c9 8a 14 08 44 30 ca 88 14 08 41 81 ea ?? ?? ?? ?? 45 01 d1 41 81 c1 ?? ?? ?? ??\r\n41 81 c2 ?? ?? ?? ?? 41 d1 c1 48 85 c9 }\r\n$unpacking_azov_old = { 48 01 c8 48 05 ?? ?? ?? ?? 48 81 c1 ?? ?? ?? ?? 48 81 ec ?? ?? ?? ?? 48 83 ec ?? 40 80\r\ne4 ?? c6 45 ?? 56 c6 45 ?? 69 c6 45 ?? 72 c6 45 ?? 74 c6 45 ?? 75 c6 45 ?? 61 c6 45 ?? 6c c6 45 ?? 41 c6 45 ?? 6c\r\nc6 45 ?? 6c c6 45 ?? 6f c6 45 ?? 63 c6 45 ?? 00 48 83 e1 ?? 48 01 f1 48 8d 55 ?? ff d0 48 83 ec ?? 48 c7 04 24 ??\r\n?? ?? ?? 48 83 c4 ?? 48 8b 4c 24 ?? 48 c7 c2 ?? ?? ?? ?? 49 c7 c0 ?? ?? ?? ?? 49 c7 c1 ?? ?? ?? ?? ff d0 48 c7 c1 ??\r\n?? ?? ?? 4c 8d 0d ?? ?? ?? ?? 48 ff c9 41 8a 14 09 88 14 08 48 85 c9 }\r\ncondition:\r\nuint16(0) == 0x5a4d and pe.is_64bit() and\r\nany of ($unpacking_azov_*)\r\n}\r\nimport \"pe\" rule ransomware_ZZ_azov_wiper { meta: description = \"Detects original and backdoored files with\r\nnew and old versions of azov ransomware - polymorphic wiper\" author = \"Jiri Vinopal (jiriv)\" date = \"2022-11-\r\n14\" hash_azov_new = \"650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e\"\r\nhash_azov_old = \"b102ed1018de0b7faea37ca86f27ba3025c0c70f28417ac3e9ef09d32617f801\" strings: //\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 11 of 12\n\nOpcodes of allocating and decrypting shellcode routine $unpacking_azov_new = { 48 83 ec ?? 58 48 01 c8 48 81\r\nec ?? ?? ?? ?? 48 83 ec ?? 40 80 e4 ?? c6 45 ?? 56 c6 45 ?? 69 c6 45 ?? 72 c6 45 ?? 74 c6 45 ?? 75 c6 45 ?? 61 c6\r\n45 ?? 6c c6 45 ?? 41 c6 45 ?? 6c c6 45 ?? 6c c6 45 ?? 6f c6 45 ?? 63 c6 45 ?? 00 48 89 74 24 ?? 48 83 ec ?? 48 83\r\nc4 ?? 48 8b 4c 24 ?? 48 8d 55 ?? ff d0 48 83 ec ?? 48 c7 04 24 ?? ?? ?? ?? 48 83 c4 ?? 48 8b 4c 24 ?? 48 c7 c2 ??\r\n?? ?? ?? 49 c7 c0 ?? ?? ?? ?? 49 c7 c1 ?? ?? ?? ?? ff d0 48 c7 c1 ?? ?? ?? ?? 4c 8d 0d ?? ?? ?? ?? 48 ff c9 41 8a 14\r\n09 88 14 08 48 85 c9 75 ?? 48 c7 c1 ?? ?? ?? ?? 41 b9 ?? ?? ?? ?? 41 ba ?? ?? ?? ?? 48 ff c9 8a 14 08 44 30 ca 88\r\n14 08 41 81 ea ?? ?? ?? ?? 45 01 d1 41 81 c1 ?? ?? ?? ?? 41 81 c2 ?? ?? ?? ?? 41 d1 c1 48 85 c9 }\r\n$unpacking_azov_old = { 48 01 c8 48 05 ?? ?? ?? ?? 48 81 c1 ?? ?? ?? ?? 48 81 ec ?? ?? ?? ?? 48 83 ec ?? 40 80\r\ne4 ?? c6 45 ?? 56 c6 45 ?? 69 c6 45 ?? 72 c6 45 ?? 74 c6 45 ?? 75 c6 45 ?? 61 c6 45 ?? 6c c6 45 ?? 41 c6 45 ?? 6c\r\nc6 45 ?? 6c c6 45 ?? 6f c6 45 ?? 63 c6 45 ?? 00 48 83 e1 ?? 48 01 f1 48 8d 55 ?? ff d0 48 83 ec ?? 48 c7 04 24 ??\r\n?? ?? ?? 48 83 c4 ?? 48 8b 4c 24 ?? 48 c7 c2 ?? ?? ?? ?? 49 c7 c0 ?? ?? ?? ?? 49 c7 c1 ?? ?? ?? ?? ff d0 48 c7 c1 ??\r\n?? ?? ?? 4c 8d 0d ?? ?? ?? ?? 48 ff c9 41 8a 14 09 88 14 08 48 85 c9 } condition: uint16(0) == 0x5a4d and\r\npe.is_64bit() and any of ($unpacking_azov_*) }\r\nimport \"pe\"\r\nrule ransomware_ZZ_azov_wiper {\r\nmeta:\r\ndescription = \"Detects original and backdoored files with new and old version\r\n author = \"Jiri Vinopal (jiriv)\"\r\n date = \"2022-11-14\"\r\n hash_azov_new = \"650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e\"\r\nhash_azov_old = \"b102ed1018de0b7faea37ca86f27ba3025c0c70f28417ac3e9ef09d32617\r\nstrings:\r\n// Opcodes of allocating and decrypting shellcode routine\r\n$unpacking_azov_new = { 48 83 ec ?? 58 48 01 c8 48 81 ec ?? ?? ?? ?? 48 83 ec ?? 40 8\r\n$unpacking_azov_old = { 48 01 c8 48 05 ?? ?? ?? ?? 48 81 c1 ?? ?? ?? ?? 48 81 ec ?? ?\r\ncondition:\r\nuint16(0) == 0x5a4d and pe.is_64bit() and\r\nany of ($unpacking_azov_*)\r\n}\r\nReferences\r\n1. Twitter – Check Point Research: https://twitter.com/_CPResearch_/status/1587837524604465153\r\n2. Bleeping Computer: https://www.bleepingcomputer.com/news/security/azov-ransomware-is-a-wiper-destroying-data-666-bytes-at-a-time/\r\n3. Bleeping Computer: https://www.bleepingcomputer.com/news/security/new-azov-data-wiper-tries-to-frame-researchers-and-bleepingcomputer/\r\n4. Twitter – MalwareHunterTeam: https://twitter.com/malwrhunterteam/status/1586713979514224643\r\nSource: https://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nhttps://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://research.checkpoint.com/2022/pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper/"
	],
	"report_names": [
		"pulling-the-curtains-on-azov-ransomware-not-a-skidsware-but-polymorphic-wiper"
	],
	"threat_actors": [],
	"ts_created_at": 1778121801,
	"ts_updated_at": 1778121851,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/146088c1813af96a55e134f877dec5bdd95b324e.pdf",
		"text": "https://archive.orkl.eu/146088c1813af96a55e134f877dec5bdd95b324e.txt",
		"img": "https://archive.orkl.eu/146088c1813af96a55e134f877dec5bdd95b324e.jpg"
	}
}