{ "id": "4fd5dd88-8936-41fb-8799-e01cfc210702", "created_at": "2026-04-06T00:06:39.961075Z", "updated_at": "2026-04-10T03:31:18.995075Z", "deleted_at": null, "sha1_hash": "ea1b020661fd5714bc1902a2501a020e7f4bb4d9", "title": "PaaS, or how hackers evade antivirus software", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 450746, "plain_text": "PaaS, or how hackers evade antivirus software\r\nBy Positive Technologies\r\nPublished: 2024-08-19 · Archived: 2026-04-05 23:13:49 UTC\r\nMalware is one of the main tools of any hacking group. Depending on the level of qualification and the specifics of\r\noperation, hackers can use both publicly available tools (such as the Cobalt Strike framework) and their own developments.\r\nCreating a unique set of tools for each attack requires huge resources; therefore, hackers tend to reuse malware in different\r\noperations and also share it with other groups. The mass use of the same tool inevitably leads to its getting on the radar of\r\nantivirus companies, which, as a result, reduces its efficiency.\r\nTo prevent it from happening, hackers use code packing, encryption, and mutation techniques. Such techniques can often be\r\nhandled by separate tools called crypters or sometimes simply packers. In this article, we will use the example of the RTM\r\nbanking trojan to discuss which packers attackers can use, how they complicate detection of the malware, and what other\r\nmalware they can pack.\r\nPacker-as-a-service\r\nA hacker group responsible for RTM distribution regularly sent mass phishing emails with malicious attachments until the\r\nend of 2020. Apparently, the attacks were automated.\r\nFigure 1. RTM phishing email, December 2020\r\nEach attachment contained files that significantly differed from each other, but the final payload remained almost the same.\r\nFigure 2. Example of RTM archive\r\nSuch feature is a natural consequence of using crypters. Initially, the group behind RTM used its own unique crypter. In\r\n2020, however, the group changed it twice.\r\nWhen analyzing samples packed in a new way, we detected numerous other malware protected by similar method. Taking\r\ninto account the fact that packing process is automated, such overlapping with other malware allows us to assume that\r\nattackers use the packer-as-a-service model. In this model, packing of malicious files is delegated to a special service\r\nmanaged by a third party.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 1 of 11\n\nFigure 3. Website of a crypt service\r\nAccess to such services can often be found on sale on hacker forums.\r\nFigure 4. Advertisement of file packing as a service\r\nLater in this article, we will discuss specific examples of crypters used by the RTM group.\r\nRex3Packer\r\nThe first use of this packer by the RTM group that we detected dates back to November 2019. The group started actively\r\nusing the packer in April–May 2020. Rare uses of the packer for distributing old versions of the RTM trojan were also\r\nobserved in late January 2021.\r\nFigure 5. Phishing email by RTM, January 2021\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 2 of 11\n\nWe couldn't associate this packer with any of the publicly described ones, so we named it according to three specifics of its\r\nworking: recursion, bit reverse, and reflective loading of PE files (reflection), hence the name Rex3Packer.\r\nUnpacking algorithm\r\nThe overall algorithm for extracting the payload is as follows:\r\n1. A predetermined amount of memory is allocated with read, write, and execute rights using VirtualAlloc.\r\n2. The content of the current process image in the memory is copied to the allocated buffer (in particular, section .text).\r\n3. Control passes to the function inside the buffer.\r\n4. The difference is calculated between the location of data in the buffer and in the PE file image (difference between\r\nthe addresses in the buffer and virtual addresses in the image). This difference is written to the ebx register. All\r\nreferences to virtual addresses in code are indexed by the content of this register. As a result, wherever necessary, a\r\ncorrection is added to the PE image addresses that allows obtaining the corresponding address in the buffer.\r\nFigure 6. Calls to functions and variables taking into account the correction in the ebx register\r\n5. Another buffer is allocated for packed data.\r\n6. By calling VirtualProtect, RWX rights are assigned to the entire memory region with the PE file image.\r\n7. The packed data is copied to the buffer.\r\n8. The packed data is decoded.\r\n9. The memory region with the PE image is filled with null bytes.\r\n10. The decoded data represents an executable file—the PE payload. This payload is reflectively loaded to where the\r\ninitial PE image was, and control passes to its entry point.\r\nA specific algorithm for decoding packed data is of special interest to us. In this case, it would be incorrect to compare\r\npacking with compression, as the algorithm is such that the size of packed data is always bigger than that of the initial data.\r\nThe packed data is preceded by a 16-byte header that contains four 4-byte fields:\r\nSize of the header\r\nSize of initial data (PE payload)\r\nPosition in initial data (*) at which they are divided (more details below)\r\nEncoding mode (1, 2, or 4)\r\nThe decoding looks as follows:\r\n1. Inside each byte, bit order is reversed (for example, 10011000 becomes 00011001).\r\n2. Depending on encoding mode (1, 2, 4), data is divided into blocks with N size of 9, 5, or 3 bytes, respectively. The\r\nresult of the block decoding is N-1 byte (8, 4, or 2).\r\n3. In the first N-1 bytes of the block, some bits are missing: their values always equal zero. To restore the original bytes,\r\nthe missing bits are extracted from the last byte of the block by using 00000001, 00010001, or 01010101 masks. The\r\nmask is shifted for each subsequent byte. As a result, the last byte of the block is composed of the bits extracted from\r\nprevious bytes and united by the logical operation OR.\r\nFor example, in mode 4, the last byte is composed of even bits of the block's first byte and odd bits of the block's\r\nsecond byte. As a result of \"returning\" these bits to the first and second bytes, an original sequence of two bytes is\r\ncomposed.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 3 of 11\n\nFigure 7. Scheme of obtaining initial bytes in mode 4\r\n4. When bits are restored in all blocks, the obtained data represents the initial PE file divided by two parts at position\r\n(*). These parts, in turn, were swapped. The second rearrangement (taking into account the (*) value) allows\r\nobtaining the original file.\r\nObfuscation\r\nTo complicate code analysis, various obfuscation techniques are used in the packer:\r\nIn between the execution of significant code, various WinAPI functions are called. Their results are saved but not\r\nused, and the functions are selected so that not to affect the program operation.\r\nFigure 8. Calling WinAPI functions\r\nA typical feature of this packer is the presence of cycles (not performing useful operations) implemented via a\r\nrecursive function.\r\nFigure 9. Recursive function (sample without junk code)\r\nFor further obfuscation, several dozens of randomly generated functions are added to executable file. They may call\r\neach other, but none of them obtains control ever.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 4 of 11\n\nFigure 10. Example of generated function\r\nUsage\r\nIn addition to RTM samples, we detected the use of Rex3Packer for packing various malware, mainly originating from the\r\nCIS countries. Below is the list with examples of such malware:\r\nMalware family SHA256\r\nPhobos Ransomware 6e9c9b72d1bdb993184c7aa05d961e706a57b3becf151ca4f883a80a07fdd955\r\nZeppelin Ransomware 8d44fdbedd0ec9ae59fad78bdb12d15d6903470eb1046b45c227193b233adda6\r\nRaccoon Stealer 3be91458baa365febafb6b33283b9e1d7e53291de9fec9d3050cd32d98b7a039\r\nKPOT Stealer 9b6af2502547bbf9a64ccfb8889ee25566322da38e9e0ccb86b0e6131a67df1e\r\nPredator The Thief d1060835793f01d1e137ad92e4e38ef2596f20b26da3d12abcc8372158764a8f\r\nQakBot 18cc92453936d1267e790c489c419802403bb9544275b4a18f3472d2fe6f5dea\r\nWe also detected the use of this packer for packing malware samples of the Nemty, Pony, and Amadey families. This is, of\r\ncourse, not an exhaustive list of all cases of using Rex3Packer.\r\nHellowinPacker\r\nIn May 2020, RTM started using a new packer and went on using it until the beginning of 2021. We called it\r\nHellowinPacker because of the file name \"hellowin.wav\" we spotted in strings of some samples.\r\nThe packer's key feature is two levels of code mutation. The first one significantly changes the unpacking code structure,\r\nmaking samples look different from each other.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 5 of 11\n\nFigure 11. Comparison of code in two samples of different structure\r\nThe example above shows the comparison of samples\r\n5b5f30f7cbd6343efd409f727e656a7039bff007be73a04827cce2277d873aa0 (on the left) and\r\n1f9a8b3c060c2940a81442c9d9c9e36c31ad37aaa7cd61e1d7aec2d86fe1c585 (on the right).\r\nThe second level only changes some details, and the code structure remains in general the same. The changes mainly affect\r\nassembler instructions and constants that do not impact the program operation. As a result, the code looks almost identical\r\nwhen decompiled.\r\nFigure 12. Comparison of code in two samples of the same structure\r\nJust like Rex3Packer, HellowinPacker is actively used by attackers to pack various malware. Note that malware from the\r\nsame family has the same structure when packed. This lasts for at least some time, after which the structure can change.\r\nAll these features coincide with the description of a packing service the access to which is sold on hacker forums:\r\n[Uniqueness] A customer is given a unique crypter that does not depend on other customers. If your files were spotted, your\r\nuploads are to blame. We're not looking for 10,000+ customers, we provide correct Premium support and have a very limited\r\nnumber of clients. We make only unique stubs for a customer.\r\nApparently, each unique crypter has its own structure of generated code. The crypter itself can also mutate code but at a\r\nlower level, without changing the program structure. In any case, the significant executable code remains the same.\r\nUnpacking algorithm\r\nOne of the first actions in all packed files is an attempt to open the registry key HKEY_CLASSES_ROOT\\Interface\\\r\n{b196b287-bab4-101a-b69c-00aa00341d07} (character case may differ in each particular case) and request a default value.\r\nCorrect program operation in some modifications of generated code depends on whether these operations are successful.\r\nInterface GUIDs may also differ. Here are some of the possible options:\r\n{3050f1dd-98b5-11cf-bb82-00aa00bdce0b}\r\n{aa5b6a80-b834-11d0-932f-00a0c90dcaa9}\r\n{683130a6-2e50-11d2-98a5-00c04f8ee1c4}\r\n{c7c3f5a1-88a3-11d0-abcb-00a0c90fffc0}\r\n{b8da6310-e19b-11d0-933c-00a0c90dcaa9}\r\nThe subsequent code obtains the address at which a block of encrypted data is located.\r\nThis block starts with a 4-byte number, which stores the size of initial data (those that will be obtained after decoding). By\r\ncalling VirtualAlloc, a memory block of required size with RWX rights is allocated for decrypted data. Encrypted data is\r\ncopied to the allocated memory by blocks of X bytes each. In the original file, \"spaces\" of Y byte length are located between\r\nthese blocks.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 6 of 11\n\nFigure 13. Scheme of data copying in HellowinPacker\r\nData is then decrypted by 4-byte blocks:\r\nEach next block is interpreted as an integer (DWORD).\r\nIndex of the first byte in the block is added to the integer.\r\nAn xor operation is executed between the obtained value and the sum of the index and a fixed key (Z number).\r\nExample of algorithm implementation in Python:\r\ndef decrypt(data, Z):\r\n index = 0\r\n while index \u003c len(data):\r\n dword = struct.unpack(\"\u003cI\", data[index:index + 4])[0]\r\n dword = (dword + index) \u0026 (2 ** 32 - 1)\r\n dword = dword ^ (index + Z)\r\n data[index:index + 4] = struct.pack(\"\u003cI\", dword)\r\n index += 4\r\nValues X, Y, and Z vary depending on a particular packed sample.\r\nThe next stage of extracting payload—the shellcode—is located inside the decrypted data. The shellcode takes control when\r\nthe decryption ends.\r\nThe shellcode dynamically loads functions required for its operation. These functions are listed in the \"import table\" located\r\nat the beginning of decrypted data.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 7 of 11\n\nFigure 14. \"Import table\" in decrypted data\r\nFor greater variability, the strings in the \"import table\" may be partially filled with random symbols. In the example above,\r\nthe first function name \"GetProcAddress\" is fully replaced by the string \"aaa45678901234\", and the names \"VirtualAlloc\"\r\nand \"VirtualProtect\" are damaged. Right before processing the table, the shellcode restores correct values of all the symbols.\r\nFigure 15. Code for restoring damaged names of functions\r\nPayload (this time, it is the PE file) is extracted by the shellcode from the rest of the decrypted data. It is encrypted again by\r\nthe same algorithm as described above. For Z key, figure 1001 is always used.\r\nWhen the decryption is finished, the shellcode performs reflective loading of the PE file using the functions imported at the\r\nfirst stage.\r\nObfuscation\r\nJust like Rex3Packer, HellowinPacker samples call WinAPI functions not related to the main program logic. However, in\r\nthis case, they are mostly used to complicate behavior analysis and detection in sandboxes. This is also confirmed by the fact\r\nthat in most cases various functions are called in a row at the very beginning of the program.\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 8 of 11\n\nFigure 16. Entry point in one of the packed libraries\r\nAn additional effect of the WinAPI use is the impossibility of detection by a list of imported functions and by imphash.\r\nWhen working with various numeric values, a certain \"arithmetic\" obfuscation is often observed: necessary constants are\r\nrepresented as sums or differences of other constants (which in some cases equal zero). To obtain constants, WinAPI\r\nfunctions can also be called, yielding predictable results (for example, 0 in case of failure).\r\nAn example of such obfuscation is given on the Figure below: the only goal of this function is to assign the value of the\r\nargument source to a variable pointed by target. In this case, the output of calling GetStockObject(789644) will always\r\nequal zero, as the function was given an intentionally incorrect argument.\r\nFigure 17. \"Arithmetic\" obfuscation in the HellowinPacker code\r\nVarious mutations are encountered at the assembler level as well: inserting junk code, using opaque predicates, calling\r\nfunctions with unused arguments and repeated calls of the functions, and replacing instructions with their equivalents.\r\nFigure 18. Example of obfuscation at the assembler code level\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 9 of 11\n\nUsage\r\nHellowinPacker exists at least since 2014 and has been so far used in various mass malware. Here are only a few examples:\r\nMalware family SHA256\r\nCerber Ransomware 1e8b814a4bd850fc21690a66159a742bfcec212ccab3c3153a2c54c88c83ed9d\r\nZLoader 44ede6e1b9be1c013f13d82645f7a9cff7d92b267778f19b46aa5c1f7fa3c10b\r\nDridex f5dfbb67b582a58e86db314cc99924502d52ccc306a646da25f5f2529b7bff16\r\nBunitu 54ff90a4b9d4f6bb2808476983c1a902d7d20fc0348a61c79ee2a9e123054cce\r\nQakBot c2482679c665dbec35164aba7554000817139035dc12efc9e936790ca49e7854\r\nThe packer has been frequently mentioned in reports by other researchers. The earliest mention we found dates back to\r\n2015. In an article about crypters, Malwarebytes experts analyze malware samples that use HellowinPacker. Later, other\r\nresearchers referred to it as the Emotet packer (1, 2). In 2020, our colleagues from NCC Group called it CryptOne and\r\ndescribed how it can be used to pack the WastedLocker ransomware. According to NCC Group, the crypter was also used by\r\nthe Netwalker, Gozi ISFB v3, ZLoader, and Smokeloader malware families.\r\nConclusion\r\nOur example of using the crypters shows us how hackers can delegate responsibilities among each other, especially when it\r\ncomes to mass malware. Developing malicious payload, protecting it from antivirus tools («crypt»), and delivering it to end\r\nusers—all this can be performed by completely unrelated hackers, and each element of this chain can be offered as a service.\r\nThis approach lowers the cybercrime entry threshold for technically unskilled criminals: to conduct a mass attack, all they\r\nhave to do is to provide a necessary amount of money to pay for all the services.\r\nThe packers we described are certainly not the only ones that exist on the market. However, they demonstrate the common\r\nfeatures of such tools: as a result of their work, an executable file is obtained with obfuscated polymorphic code of the\r\nunpacker and a payload encrypted in some way or another. Mutations in code and reuse of the same crypters make static\r\ndetection of payload almost impossible. However, since the payload is somehow decrypted to the memory and then starts its\r\nmalicious activity, behavioral analysis using sandboxes (such as PT Sandbox) allows detecting malware and providing\r\naccurate verdicts even for packed files. In addition, it should be noted that packers do not affect the interaction of malware\r\nwith C\u0026C servers in any way. This makes it possible to determine the presence of malware in the network using traffic\r\nanalysis tools such as PT Network Attack Discovery.\r\nVerdicts of our products\r\nPT Sandbox\r\nTrojan.Win32.RTM.a\r\nTrojan.Win32.RTM.b\r\nTrojan-Banker.Win32.RTM.a\r\nTrojan-Banker.Win32.RTM.b\r\nTrojan-Banker.Win32.RTM.c\r\nTrojan-Banker.Win32.RTM.d\r\nTrojan-Banker.Win32.RTM.e\r\nTrojan-Banker.Win32.RTM.f\r\nPT Network Attack Discovery\r\nREMOTE [PTsecurity] TeamBot/RTM\r\nsid: 10004412;\r\nBACKDOOR [PTsecurity] TeamBot/RTM\r\nsid: 10004415;\r\nMALWARE [PTsecurity] RTM Banker CnC POST\r\nsid: 10000765;\r\nMALWARE [PTsecurity] RTM.N (Redaman)\r\nsid: 10005556; 10005557;\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 10 of 11\n\nMALWARE [PTsecurity] Spy.RTM.AF\r\nsid: 10005468;\r\nMALWARE [PTsecurity] Trojan[Banker]/RTM\r\nsid: 10004855; 10004875;\r\nMALWARE [PTsecurity] Win32/Spy.RTM.N (Redaman)\r\nsid: 10003414; 10004754; 10005555;\r\nPAYLOAD [PTsecurity] RTM.Payload.xor\r\nsid: 10005585;\r\nIOCs (RTM)\r\nDetection\r\ndate\r\nCrypter SHA256 SHA1\r\n19.04.2020 RTM a4229a54f76815ac30a2a878eadf275e199c82da657dbc5f3fc05fe95603c320 ad22ceb309dd30dc769f6317429265\r\n22.04.2020 Rex3Packer 9b88e8143e4452229dac7fdcc3d9281d21390f286c086f09aec410f120dc4325 f881729f6a5ca6fe80f385a2b0f8583b\r\n13.05.2020 HellowinPacker 43e8ebacfa319ff7d871eef3cc35266cfa7c6f44dd787f27a48311e39727e10f 8a28b75285409c55d5bbeca62e3819\r\n28.01.2021\r\nRex3Packer (2\r\nlayers)\r\nfbf5974daee93bf5a2ed1816a4edbb108ceccb264d3e3f72d0aed268dd45e315 2e3352c6341ce57a03aaf2c4fbf484f3\r\nSource: https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nhttps://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/\r\nPage 11 of 11", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/paas-or-how-hackers-evade-antivirus-software/" ], "report_names": [ "paas-or-how-hackers-evade-antivirus-software" ], "threat_actors": [ { "id": "67bf0462-41a3-4da5-b876-187e9ef7c375", "created_at": "2022-10-25T16:07:23.44832Z", "updated_at": "2026-04-10T02:00:04.607111Z", "deleted_at": null, "main_name": "Careto", "aliases": [ "Careto", "The Mask", "Ugly Face" ], "source_name": "ETDA:Careto", "tools": [ "Careto" ], "source_id": "ETDA", "reports": null }, { "id": "610a7295-3139-4f34-8cec-b3da40add480", "created_at": "2023-01-06T13:46:38.608142Z", "updated_at": "2026-04-10T02:00:03.03764Z", "deleted_at": null, "main_name": "Cobalt", "aliases": [ "Cobalt Group", "Cobalt Gang", "GOLD KINGSWOOD", "COBALT SPIDER", "G0080", "Mule Libra" ], "source_name": "MISPGALAXY:Cobalt", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "f5bf6853-3f6e-452c-a7b7-8f81c9a27476", "created_at": "2023-01-06T13:46:38.677391Z", "updated_at": "2026-04-10T02:00:03.064818Z", "deleted_at": null, "main_name": "Careto", "aliases": [ "The Mask", "Ugly Face" ], "source_name": "MISPGALAXY:Careto", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775433999, "ts_updated_at": 1775791878, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/ea1b020661fd5714bc1902a2501a020e7f4bb4d9.pdf", "text": "https://archive.orkl.eu/ea1b020661fd5714bc1902a2501a020e7f4bb4d9.txt", "img": "https://archive.orkl.eu/ea1b020661fd5714bc1902a2501a020e7f4bb4d9.jpg" } }