{
	"id": "488d1f17-85ef-4bea-8edd-fb68fade52b8",
	"created_at": "2026-04-06T00:15:41.239512Z",
	"updated_at": "2026-04-10T03:24:03.45371Z",
	"deleted_at": null,
	"sha1_hash": "ba1e86cab43b260be1cd6f45bb95b97e42f15226",
	"title": "Layers of Deception: Analyzing the Complex Stages of XLoader 4.3 Malware Evolution",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 14252953,
	"plain_text": "Layers of Deception: Analyzing the Complex Stages of XLoader 4.3\r\nMalware Evolution\r\nBy Shayan Ahmed Khan\r\nPublished: 2024-04-25 · Archived: 2026-04-05 17:45:58 UTC\r\nXLoader, an advanced evolution of the FormBook malware, stands out as a highly sophisticated cyber threat\r\nrenowned for its dual functionality as an information stealer and a versatile downloader for malicious payloads.\r\nNoteworthy for its resilient nature, xLoader constantly adapts to the latest and most intricate evasion techniques,\r\nmaking it a formidable challenge for cybersecurity defenses. Its notoriety is heightened by its role as a commercial\r\nMalware-as-a-service solution, enabling cybercriminals to tailor and deploy the malware for diverse malicious\r\nactivities. The malware’s continuous evolution and ability to elude detection emphasize the critical need for robust\r\ncybersecurity measures to counter its intricate and multifaceted attacks, which target both individuals and\r\norganizations alike.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 1 of 47\n\nKey Findings:\r\nInitial Dropper: Xloader uses a similar initial dropper as some of the other infostealers like Remcos RAT\r\nand Agent Tesla. The initial dropper is a dotnet executable file, which contains multiple embedded DLLs\r\nwhich are extracted and decrypted at run-time to launch the payload which is the actual malware. The\r\npayload is launched using Process Hollowing in either itself or another running process, depending upon\r\nthe configuration of the initial dropper.\r\nNative Assembly Paylaod: Xloader is written in native low level asm/c language. There are no strings,\r\nimports and libraries found in this payload. Native assembly with the combination of c language already\r\nmakes it much harder to analyze and detect than other infostealers like Remcos, Agent Tesla, NanoCore\r\netc.\r\nAnti-Analysis/VM Techniques: It uses advance techniques that detects if the malware is running in an\r\nanalysis environment. The usage of advanced techniques makes sure that, anti-vm checks are not easily\r\nbypassed as simply as patching a jump condition or return condition.\r\nCustom Encryption Algorithms: It uses a Custom RC4 encryption/decryption algorithm with additional\r\nsubtraction operations.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 2 of 47\n\nAPI/String/Libraries Hashing: Xloader uses CRC32/BZIP2 hashing algorithm for its strings, libraries\r\nand APIs to hide its internal working.\r\nEncrypted Core Functions: Xloader’s core malicious functions are all encrypted that are decrypted at-run\r\ntime and assembly is renewed or regenerated after all anti-vm checks have been bypassed and a key has\r\nbeen generated.\r\nUnhooked Clean Ntdll: It uses a clean copy of ntdll manually mapped into its memory which bypass all\r\nhooks for ntdll APIs. It uses Native APIs for its malicious activities which are hidden from EDR solutions.\r\nThe process is known as “Lagos Island Method” according to FireEye.\r\nPersistence: Xloader adds persistence using Run Registry Keys and copying itself in Program Files (x86).\r\nPrivilege Escalation: It escalates privileges only for copying itself in the Program Files (x86) and adding\r\npersistence. The privilege escalation is achieved by abusing DllHost.exe and COM objects.\r\nProcess Injection: Xloader relies heavily on process injection. It infects multiple processes in its execution\r\nand even migrate to a different process.\r\nDecoy C2s: It uses a combination of decoy C2 servers and made significant effort to hide its real C2.\r\nForm Grabber: Xloader is not just an infostealer. It also works as a form grabber. Inline hooks are\r\ninjected into multiple victim processes to grab information before encryption is performed.\r\nCheck out my Github Repo for Malware Analysis Series!!!\r\nOverview\r\nXLoader emerges as an exceptionally sophisticated infostealer and form grabber malware, distinguished by its\r\nadept use of advanced defense evasion techniques to maintain stealth and resilience. Beyond its evasive\r\nmaneuvers, XLoader incorporates a myriad of anti-VM techniques, strategically avoiding execution in analysis\r\nenvironments. This malware’s primary objective is data exfiltration, achieved through the theft and capture of\r\nsensitive information from a broad spectrum of applications, including browsers, email clients, FTP clients, and\r\ninstant messaging apps. Notably, XLoader is designed to operate seamlessly across a variety of platforms,\r\namplifying its threat level. Its multifaceted attack flow encompasses a strategic and systematic approach, making\r\nit a potent tool for cybercriminals seeking to compromise both individual users and organizational systems. The\r\nconstant evolution of XLoader underscores the need for robust cybersecurity measures to counter its intricate and\r\nadaptable nature.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 3 of 47\n\nXloader Attack Chain\r\nThreat Report: XLoader 4.3\r\nThis section of the report provides a detailed technical analysis of Xloader 4.3 malware. The flow of this report\r\nwill be in order of steps that I performed during my analysis. This is one of the most complex pieces of malware\r\nthat I have analyzed, and there are so many stages to its execution. I have tried to cover as much as possible in the\r\ngiven time, but if some things remain unanswered then I apologize beforehand. Now let us dive down into the\r\ntechnical details and internal workings of Xloader 4.3 previously known as Formbook infostealer.\r\nInitial Detonation:\r\nStarting with the initial detonation of xloader. I have detonated the malware in my isolated analysis environment\r\nin the presence of procmon, wireshark and other such analysis tools. Nothing happened!!! Which likely suggests\r\nthat there are anti-analysis techniques in the malware. I tried detonating the malware again but this time, I had\r\nrenamed my analysis tools and the execution started.\r\n· Process tree shows that it started another instance of itself.\r\n· Multiple DNS \u0026 HTTP request are sent to different domains.\r\n· Deleted itself\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 4 of 47\n\n· Request are sent through explorer.exe\r\nFew of the resolved domains are listed below:\r\nhxxp:\\\\www.twin68s.online\r\nhxxp:\\\\www.cicreception2023.org\r\nhxxp:\\\\www.morubixaba.com\r\nhxxp:\\\\www.gestionamostualquiler.org\r\nhxxp:\\\\www.superios.info\r\nhxxp:\\\\www.bocahkota.xyz\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 5 of 47\n\nhxxp:\\\\www.lolisex77.top\r\nhxxp:\\\\www.fhsbfjbsljsdfsd.xyz\r\nhxxp:\\\\www.mifurgoentuangar.fun\r\nhxxp:\\\\www.necessarymusthave.shop\r\nhxxp:\\\\www.abk-importexport.com\r\nhxxp:\\\\www.adoniadou.com\r\nhxxp:\\\\www.delret.tech\r\nhxxp:\\\\www.humidlandscaping.com\r\nhxxp:\\\\www.wlkwinn.net\r\nhxxp:\\\\www.8ai.ooo\r\nhxxp:\\\\www.minevisn.com\r\nhxxp:\\\\www.moheganmart.com\r\nhxxp:\\\\www.jacksonmoddy.com\r\nStage 1: Dropper\r\nThe initial dropper is a dotnet executable. It is similar to what other infostealers or RAT uses for dropping their\r\npayloads like Agent Tesla or Remcos RAT. The first step is always static analysis, which extracts suspicious\r\nstrings for me and provide insight to the malware.\r\nPress enter or click to view image in full size\r\nThe extracted strings suggest 3 main points:\r\nDropper is obfuscated that loads other assemblies at run-time\r\nFurther resources are inverted to avoid signature-based detection\r\nMust have more than 1 assemblies\r\nIn the initial dropper, there is a lot of junk code added to divert the focus of analyst. The few lines of malicious\r\ncode are spread through the whole code.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 6 of 47\n\nThe relevant lines of code shows that malware is loading binary from 3 different resources:\r\n· Quartz which is also reversed\r\n· Versa\r\n· Zinc\r\nGet Shayan Ahmed Khan’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nThese 3 are the malicious resources that are combined and loaded at run-time for further execution. After going\r\nthrough a lot of junk code, I came across the line of code that resolves this assembly at run-time and create\r\ninstance of resource followed by loading the first method using System.Activator class.\r\nSince, stage1 malware resolves assemblies at run-time and activate the method from resolved assemblies therefore\r\nstatic analysis is not possible ahead of this step, so I shifted to dynamic analysis.\r\nThe runtime binary that has been loaded can be seen in the modules window.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 7 of 47\n\nThe name of runtime generated binary is pendulum. In the code, the malware is invoking the first member\r\nreturned by the GetExportedTypes which means the first member of exports would be executed.\r\nWe can locate the first function in the pendulum binary and set the breakpoint ahead to stop and debug it.\r\nThere are further binaries being resolved from the resource of first loaded DLL which is Pendulum. In the\r\nmodules tab, we can trace which dlls are being added and keep following through.\r\nAnother binary that is being loaded at run-time from the resource of pendulum is the cruiser.dll which\r\ncould be seen in the modules window. This binary undergoes gzip decompression and loaded using\r\nActivator class.\r\nThis binary contains a few methods called “CausalitySource and SearchResult” which performs some\r\nkind of decryption of another third resource which will also be loaded on runtime.\r\nThe last resource that has been decrypted and loaded is called Discompard.dll.\r\nIn the method of ParsingState, it could be seen that a method from this assembly is being called for further\r\nexecution of malware.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 8 of 47\n\nWe can also see the names of classes and methods that are being called from this assembly in the locals.\r\nUsing this information, we can then setup another breakpoint in the Discompard.dll method and continue\r\ndebugging the 3rd resource.\r\nAgain, we can explore the third binary and setup a breakpoint on the function that it tries to call.\r\nWe have now entered the method called by the previous dll. This binary is highly obfuscated with random variable\r\nand class names. Normally, what I do is that I check if a deobfuscator like de4dot or some other tool is able to\r\ndeobfuscate such a binary. If it is possible then I patch the resource and continue my debugging with the\r\ndeobfuscated version. But in this case, it is very tricky because this resource is dependent upon two other binaries\r\nthat are being called first and to patch all these will be such a headache. So, I decided to move forward with the\r\nobfuscated version and see if I could understand what it is doing from the local variables and return values.\r\nI kept stepping over and checking the variables and function returns.\r\nIt skipped most of the flags but then I stepped over a function and a return value shows that another binary\r\nhas been returned. The MZ bytes (4D 5A) could be seen in the array.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 9 of 47\n\nIt confirms that this malware might perform some kind of injection or dump the binary in a file and execute\r\nit as a 2nd stage malware.\r\nI stepped into a function that is obfuscated but it looks like it is performing process hollowing, as the\r\nmalware opens itself in a suspended state and ready to inject in the address space of this process.\r\nStepped over few of the functions while checking RWX memory region of the process\r\nAt one point it reserved the memory and then started writing shellcode into that memory in chunks\r\nIt changes the execution of base image to the injected shellcode and finally resume the process using\r\nResumeThread API.\r\nThis is the exact behavior of process hollowing.\r\nI dumped this shellcode to analyze the malware separately as a second stage payload.\r\nThe stage2 malware is the real xloader payload.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 10 of 47\n\nStage2: Xloader 4.3\r\nXloader is an infostealer malware that is the updated version of Formbook malware. It is sold on dark web for\r\ncheap prices with a MaaS architecture (Malware-as-a-Service). The authors of this malware put great effort in\r\nadding latest defense evasion techniques.\r\nXloader aka Formbook is written in pure native assembly with a combination of c language\r\nThe entropy is very high which suggests that there is embedded code or it might be packed\r\nThere are 0 libraries, imports, strings found in this payload\r\nThere are no valid strings other than the DOS message\r\nThe start of malware is fairly simple, it loads some necessary libraries before going to the malicious code\r\nIt also performs some other kind of computations, probably decompressing some of its malicious code\r\nAfter the calculations, I came across a call to edx which leads to an unidentified code\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 11 of 47\n\nThe “call edx” instruction moves the program flow to a set of native assembly which is unidentified by\r\nIDA at this moment\r\nThis means that, the code to which edx register now points was not understood by IDA which indicates that\r\nit might be encrypted at first\r\nFrom there the execution of real formbook payload starts\r\nIDA resolves this chunk of assembly at run-time to continue debugging this dump.\r\nThis is one of the many anti-analysis techniques added in the xloader payload.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 12 of 47\n\nAfter going through the newly resolved chunk of code, my program exited without doing anything else. I\r\nunderstood that there are anti-analysis techniques involved in this malware. So, my battle started with defeating\r\nanti-analysis techniques provided in the section below.\r\nDefeating Anti-Analysis:\r\nTAKE # 1: FAILED\r\nIn first take, I simply changed the jump condition to divert the program from exiting the malware to\r\ncontinue with the actual program flow\r\nChanged the zero flag from 1 to 0 which sets the condition appropriately to let the program continue\r\nIt continues the program, however it throughs exception right after stepping over a few functions.\r\nThis patch will not work\r\nThe malware is dependent upon the values that this flag is setting somewhere\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 13 of 47\n\nTAKE # 2: FAILED\r\nThe configuration object:\r\nXloader payload initializes a configuration object on which it bases most of its execution flow\r\nThe configuration obj is initialized with FFFFFFFF value and after that each function contributes to it.\r\nSome encrypted values are pushed onto this configuration object.\r\nThe first function, saves lots of encrypted strings or hash codes. The purpose of these will be cleared later\r\non in the execution\r\nNext to FF values, the base address of executing malware is saved\r\nOn the third line another address is stored which is actually the address of LdrLoadDll function from ntdll.\r\nThis will be used to laod further libraries\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 14 of 47\n\nI stepped over each function and monitored changes in memory side by side.\r\nEvery function is contributing to the conf obj.\r\nThe function in the screenshot below is loading a clean ntdll in the memory and saves it address on the\r\nconf obj\r\nAlso, it is setting value in anti-vm flags that starts from the 45th element of the conf obj.\r\nThe address of injected ntdll in memory starts on 0x1950000 and similarly in the 4 bytes after 24th element\r\nwe have the address of injected ntdll saved.\r\nThe flag value of 1 is also set in anti-vm flags.\r\nContinuing with the execution.\r\nIt checks other anti-vm checks\r\nLike taking snapshot of running processes and filtering out if any of those processes are listed by the\r\nmalware\r\nIn the screenshot, we can see that it detected procmon in running processes\r\nAfter performing some of the anti-vm checks, it updated the flags on anti-analysis bytes as shown in\r\nscreenshot below:\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 15 of 47\n\nThe last function is matching the anti-vm flags with the sequence it requires to progress.\r\nAs can be seen in the screenshot, my sequence doesn’t match to what it should be,\r\nIt means the malware has either detected the debugger or tools like procmon or some other parameter\r\nTherefore, the program exits.\r\nSo, in take # 2 of defeating anti-reverse engineering or anti-vm techniques, I simply patched the sequence\r\nof these flags in the memory to the required sequence.\r\nPatching memory, and moving onto the execution should work, because these flags are being used\r\nsomewhere ahead in the program. So, simply changing the conditional jump would always crash the\r\nprogram.\r\nHowever, in case of memory patch, these values would be continued in the program and this issue should\r\nbe fixed.\r\nPatched the memory and now it goes back to the condition which is true\r\nHowever, something is wrong here.\r\nBecause the names of the dll being searched is very weird.\r\nNow I understand, that these sequences of bytes are being used in a decryption algorithm to decrypt the\r\nnames of libraries and APIs.\r\nBut since I patched the bytes in memory, it should have been able to decrypt accurately which it is not.\r\nThat means that the sequence is used somewhere else before performing the anti-analysis check.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 16 of 47\n\nI let the malware continue and again it crashed, because it was not able to decrypt its configuration and\r\nhence looking for encrypted dll names.\r\nSo that means, I might be missing some important function and because it is detecting the debugger, it\r\nwould be skipping some important function.\r\nTAKE # 3: PASSED\r\nIn third take, I have debugged a lot of the code and finally, found the function over which the program was\r\nskipping because of a single flag condition not being met.\r\nSo, I changed the values of condition to allow it to execute as well as changed the value of register that was\r\nbeing pushed to the conf obj.\r\nIn my environment, there were always 3 flags that were changed. The value on the third element was 0\r\nhowever it should be 1, and the two elements at 11,12th position.\r\nI also know that those two were changed because of procmon and other such analysis tools. So, it is easier\r\nto just change the name of procmon and continue.\r\nInstead of applying memory patches, I have changed the values at run-time before they were pushed onto\r\nthe memory stack and voila, the malware executed perfectly without any exceptions.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 17 of 47\n\nNow this time, I stepped over the function that loads libraries and instead of encrypted names, the full\r\nnames of libraries have been seen and successfully loaded as can be seen in procmon.\r\nI let the program continue without any other interaction and the debugger exited with status code 0, which\r\nmeans now there is no exception.\r\nHowever, it still hasn’t performed all the functionality which indicates there are more anti-analysis\r\ntechniques ahead.\r\nI found a very good resource, that explains all the flags that previous formbook version looked for in its analysis.\r\nLuckily in the latest xloader, it is still using a similar approach and we can map those flags easily. The following\r\nslide shows all the anti-analysis flags that the xloader uses in its configuration.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 18 of 47\n\nReference: https://www.botconf.eu/botconf-presentation-or-article/in-depth-formbook-malware-analysis/\r\nDecryption/Deobfuscation Routine:\r\nXloader relies heavily on encryption and obfuscation to avoid being detected from EDR solutions. There is multi-layered encryption performed on its code. The APIs are all hashes, the string and libraries are also hashes. Even\r\nthe hashes are encrypted in the conf obj. The core functions of xloader are all encrypted and decrypted at run-time\r\nafter anti-analysis checks are cleared.\r\nDecrypting Library Names:\r\nThe decryption routine starts, I stepped through the next function after anti-vm checks have been cleared\r\nand it looks like the anti-vm flag bytes are used as decryption seed value.\r\nThe library names are being decrypted one by one.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 19 of 47\n\nThese libraries are then loaded by the native function LdrLoadDll\r\nDecrypting API Names:\r\nSome of the APIs that are being decrypted suggests that it looks for further Process Injection\r\n1. LookupPrivilegeValueW\r\n2. SeDebugPrivilege\r\n3. AdjustPrivilegeToken\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 20 of 47\n\nPress enter or click to view image in full size\r\nComputing String Hashes:\r\nThere is a hashing algorithm used for strings, apis etc.\r\nIt loads all the string hashes and compare the running processes with each hash value, if it finds any such\r\nprocess, it adds desired value on the anti-vm flag on conf obj.\r\nIn the screenshot below, it is checking the process name hash with the value of pre-defined set of hashes\r\nthat it stored.\r\nThe hash value that is it is comparing to is 23 E0 C7 CD which in hex is (0xCDC7E023).\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 21 of 47\n\nI have checked 32-bit hashing algorithms by calculating the hash of procmon and found the hashing\r\nalgorithm that it uses.\r\nIt uses CRC-32/BZIP2 hashing for its strings\r\nAll the hashes that it checks are listed below:\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 22 of 47\n\nComputing API Hashes:\r\nSimilar to strings hashes\r\nThe APIs that are being loaded from injected ntdll (Lagos Island Method) are also called by hashes instead\r\nof names\r\nThis method makes detection very hard even for manually analyzing the malware.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 23 of 47\n\nThe malware loads all exports of ntdll one by one and computes the CRC-32/BZIP2 hash of those apis then\r\ncompares it with its decrypted hashes.\r\nIf a match is found, then it retrieves the address and call the function, hence bypassing all API hooks.\r\nI wrote a little script that does the same, I provide the hash and it searches in a list of commonly used\r\nstrings,apis,paths etc, computes their hashes and then compares with the provided hash to check weather a\r\nmatch has been found or not.\r\nHere in this case, the hash matched on NtResumeThread API call, so malware will exit the loop and\r\ncontinues to retrieve the address and then call the api.\r\nIt manually searches for the address of desired API and calls it, this way the debugger is also not able to\r\ndetect which API is being called.\r\nIn the screenshot below, I have opened another instance of same dll in IDA with symbols and we can see\r\nthe hex value that is being pushed onto eax register is the same.\r\nI know the hashing function, so instead of stepping through this native assembly of hundreds of functions\r\nin a loop, I have just setup the breakpoint on that function by writing IDA python script and just continuing\r\nagain and again to see the decrypted APIs\r\nThe List of APIs that I found are listed below:\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 24 of 47\n\nDecrypting Core Malicious Functions:\r\nThe malware decrypts its core functions at run-time and then jumps to those functions continuing the\r\nexecution flow.\r\nXloader sets up a function by push ebp and mov ebp, esp and other starting instructions but below these\r\nall bytes are encrypted.\r\nIn previous versions of formbook, the core malicious functions could be identified by the magic bytes of\r\n48909090, 49909090 etc.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 25 of 47\n\nHowever, in the latest xloader 4.3 these starting bytes are random.\r\nAfter the anti-vm checks and establishing the RC4 decryption key. These functions are decrypted at run-time and the execution flow jumped to the decrypted assembly.\r\nIDA resolves the decrypted bytes and recreates assembly instructions to continue.\r\nUnderstanding the detailed technical methodology of decrypting these encryption and obfuscation techniques.\r\nThis following blog by zscaler is an excellent resource.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 26 of 47\n\nPartially Decrypted Shellcode:\r\nStepped over a few functions and it looks like it reads itself and most likely trying to inject itself in some\r\nother process\r\nThe malware is now preparing for another binary to inject further. As can be seen in the screenshot of the\r\ndump that I found in the memory\r\nThis memory dump is RWX memory region in itself as can be seen in the process hacker\r\nI stepped over a few functions while monitoring the memory region.\r\nThe malware is decrypting the shellcode from the binary\r\nOnly plain shellcode is left without MZ headers\r\nThis is the 3rd stage xloader which is partially decrypted\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 27 of 47\n\nI dumped the binary from memory and run a FLOSS string search on it which provides some useful\r\ninsights\r\nProcess Enumeration:\r\nXLoader uses NtQuerySystemInformation to get information of all running processes in the system and\r\nthen enumerates one-by-one checking and matching hashes with its own hash values stored in conf obj.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 28 of 47\n\nProcess Injection:\r\nXloader Injection Overview:\r\nXloader stage2 performs two process injections:\r\nInjection#1: in a random running process to start the win32 victim process in suspended state\r\nInjection#2: migrate itself into win32 suspended process and resume\r\nInjection # 1\r\nAnother memory has been reserved in the malware with RWX memory region.\r\nI have dumped this new region and extracted the strings\r\nIt has a single static string which contains the name of the target process\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 29 of 47\n\nIt means that this shellcode is used for starting the process chkdsk.exe which is randomized on every\r\nexecution.\r\nXloader selects these binaries from SysWOW64 directory, which are 32-bit processes\r\nIt injects this shellcode in one of the above enumerated running processes, which in my case is a 64-bit\r\nIDA that I had opened along with my debugger.\r\nThis is also one of the anti-analysis techniques used by xloader. It doesn’t directly open the process itself\r\nbut injects shellcode in some random process which in turn opens the SysWOW64 randomized binary in a\r\nsuspended state and then retrieves its process information and continue with the execution.\r\nIn Ida64, the shellcode is injected which starts the process and return the process information back to\r\nstage2 malware of xloader.\r\nThe RWX memory region could be seen in IDA64.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 30 of 47\n\nThis is just a dead code after opening the target process in suspended state.\r\nInjection # 2:\r\nThe second injection is performed in the chkdsk.exe (randomized SysWOW64 binary)\r\nThere are two buffers injected in the chkdsk.exe.\r\n1 buffer of 180KB and other of 40KB\r\nSince this malware is performing so many injections, it is very difficult to keep track of everything so we\r\ngot an idea of creating a tool for detecting process injections.\r\nI would like to give special thanks to Osama Ellahi, for creating this tool in short period of time which is\r\nvery useful in detecting injections of such malware.\r\nTool link: https://github.com/Jhangju/injectionview\r\nThe smaller buffer contains the original chkdsk.exe bytes.\r\nI also found the function that writes shellcode in the 180KB empty buffer.\r\nThis is also a shared memory region between the formbook payload and victim process of chkdsk.exe\r\nBecause the buffer is simultaneously being written in both processes.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 31 of 47\n\nHere in xloader payload, the memory region is also being written simultaneously\r\nThis is the same partially decrypted shellcode that I have displayed above, with most of the decrypted\r\nstrings.\r\nFrom here onwards, the stage3 of formbook will be executed.\r\nFinally, after resuming the suspended process in chkdsk.exe\r\nIt exits using ExitProcess API\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 32 of 47\n\nStage 3: Partially Decrypted Xloader 4.3\r\nBefore resuming the thread on injected process. I have attached x32dbg to the victim process to continue\r\ndebugging further. In the EAX register, the address of xloader injected code is already set by stage2 malware. So, I\r\njust jumped to address in disassembly and added breakpoint on it. Then from the stage2 malware I allowed the\r\nmalware to continue hence resuming the thread on stage3. Stage2 malware has exited and we have debugger\r\nattached to the entry point of stage3 malware which I will continue from here. This whole execution flow is very\r\nsimilar to stage2 malware. So, I will move forward with only key details in this section:\r\nDefeating Anti-Analysis:\r\nXloader has decrypted some of its functions and now migrated to the process msiexec.exe (which was\r\nchkdsk.exe in previous examples)\r\nBefore resuming the thread, I’ve attached debugger to the injected process and continued my analysis from\r\nthere.\r\nThis is the same cycle being repeated first.\r\nI have to defeat anti-analysis techniques again\r\nSimilar to stage2 I have bypassed anti-analysis techniques again and correct sequence of bytes have been\r\ngenerated as highlighted below\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 33 of 47\n\nDecryption/Deobfuscation:\r\nThis injected stage3 payload performs the same initial steps.\r\nIt performs anti-vm techniques and checks\r\nDecrypt further library names and load using LdrLoadDll\r\nDecrypt API names and match hashes. Finally load those APIs from the injected fresh copy of ntdll\r\nA few of the APIs that it uses for Process Injection are resolved:\r\n1. LookupPrivilegeValue\r\n2. SeDebugPrivilege\r\n3. NtAdjustPrivilegeToken\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 34 of 47\n\nIndicator Removal:\r\nIt will delete the stage2 malware with following sequence of APIs\r\n1. NtCreateFile\r\n2. NtQueryInformationFile\r\n3. NtReadFile\r\n4. NtClose\r\n5. ZwDeleteFile\r\nProcess Injection:\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 35 of 47\n\nThe next series of APIs being used are:\r\n1. NtCreateSection\r\n2. NtMapViewOfSection\r\n3. NtAllocateVirtualMemory\r\n4. NtOpenProcessToken\r\n5. NtQueryInformationToken\r\n6. ConvertSidToStringW\r\n7. NtAllocateVirtualMemory\r\nIt is preparing another shellcode to inject further in some process. There are a few more RWX sections\r\ncreated in the memory of infected process\r\nSystem Information Discovery:\r\nIt retrieves the system information from the Registry like the “Product Name”, “CurrentBuild” of OS etc\r\n1. NtCreateKey\r\n2. NtQueryValueKey\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 36 of 47\n\nDynamic Library/API resolution:\r\nLoading libraries wininet.dll using LdrLoadDll\r\nProcess Enumeration \u0026 Injection:\r\nLooks like the next injection will be in “explorer.exe”.\r\nIt enumerates all the process by looping through the list of processes returned by\r\n“NtQuerySystemInformation”\r\n2. NtCreateMutant\r\n3. NtCreateSection\r\n4. NtMapViewOfSection\r\n5. NtDelayExecution\r\n6. NtAllocateVirtualMemory\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 37 of 47\n\nPress enter or click to view image in full size\r\nBot registration:\r\nThe data it collects and sends in the first request is provided below:\r\nThe Magic word: XLNG\r\nBot ID: 202293EF\r\nXloader Version: 4.3\r\nOS: Windows 10 Enterprise x64\r\nUsername: base64_encoded\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 38 of 47\n\nStealer:\r\nXloader is an infostealer and form grabber.\r\nAfter registering the device, it looks for all the things it could steal from the victim\r\nThere are a large number of email clients, browsers, ftp clients, messaging apps that it tries to look for in\r\ndifferent paths to fetch and steal the data\r\nIf it finds anything, it then tries to steal that data\r\nLike in case of chrome, it founds login data and it will fetch the data using sqlite3 queries\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 39 of 47\n\nIt uses winsqlite3.dll to extract passwords\r\nThe query is “SELECT origin_url, username_value, password_value FROM logins”\r\nIt decrypts that data using crypt32.CryptUnprotectedData from the key found in local state\r\nIf it finds anything, it creates a file in temp folder with the static name of “3r9Pk-75”\r\nIf the file exists already, it first deletes the previous one and then write new with the updated date.\r\nReads the file by the following API sequence\r\n1. NtCreateFile\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 40 of 47\n\n2. NtQueryInformationFile\r\n3. NtReadFile\r\n4. NtWriteFile\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 41 of 47\n\nTargeted Processes \u0026 Applications\r\nDecrypted Functions:\r\nA lot of data is hidden at first because of encrypted functions\r\nSimilar to stage2 malware, the stage3 version also have encrypted functions in it\r\nThose are decrypted at run-time\r\nThose functions also contain encrypted hex-based strings for targeted processes\r\nThe strings for targeted applications and paths are pushed onto stack at run-time.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 42 of 47\n\nPrivilege Escalation:\r\nPrivileges are escalated by abusing the dllhost.exe and COM objects\r\nIt keeps trying to copy the stage2 malware in Program Files\r\nIf proper privileges are not provided, it then uses explorer to write stage2 malware in temp and by abusing\r\ndllhost, it copies the malware to Program Files\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 43 of 47\n\nPersistence:\r\nAfter the malware is copied in Program Files\r\nIt achieves persistence by adding Run Registry Keys\r\nIt uses the API NtCreateKey\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 44 of 47\n\nSetting Inline Hooks:\r\nXloader also works as a form grabber\r\nIt sets inline hooks in targeted processes for stealing plaintext data from the parameters of the functions\r\nThe data stolen from victim processes is saved in a shared memory between 3 processes\r\n1. Victim Process\r\n2. Stage3 Malware\r\n3. Explorer\r\nThe xloader is stuck in a loop here\r\nOn every loop, it does the following:\r\n1. Enumerates all running processes\r\n2. Set inline hooks in targeted processes if found (by injecting code)\r\n3. Steal clipboard data\r\n4. Tries to create a file in program files\r\n5. Adds registry in RunKeys\r\n6. Send a POST \u0026 GET request on one of the resolved c2 servers through explorer.exe. It has an injected\r\npayload in explorer.exe that it uses for exfiltrating stolen data.\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 45 of 47\n\nSetting hooks\r\nRef: https://www.botconf.eu/botconf-presentation-or-article/in-depth-formbook-malware-analysis/\r\nReferences:\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-formbook-new-variant-delivered-phishing-campaign-part-ii\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-xloader-s-code-obfuscation-version-4-3\r\nhttps://www.zscaler.com/blogs/security-research/analysis-xloader-s-c2-network-encryption\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 46 of 47\n\nhttps://www.botconf.eu/botconf-presentation-or-article/in-depth-formbook-malware-analysis/\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/formbook-malware-distribution-campaigns\r\nhttps://www.stormshield.com/news/in-depth-formbook-malware-analysis-obfuscation-and-process-injection/\r\nSource: https://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nhttps://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9\r\nPage 47 of 47",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://medium.com/@shaddy43/layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9"
	],
	"report_names": [
		"layers-of-deception-analyzing-the-complex-stages-of-xloader-4-3-malware-evolution-2dcb550b98d9"
	],
	"threat_actors": [
		{
			"id": "34eea331-d052-4096-ae03-a22f1d090bd4",
			"created_at": "2025-08-07T02:03:25.073494Z",
			"updated_at": "2026-04-10T02:00:03.709243Z",
			"deleted_at": null,
			"main_name": "NICKEL ACADEMY",
			"aliases": [
				"ATK3 ",
				"Black Artemis ",
				"COVELLITE ",
				"CTG-2460 ",
				"Citrine Sleet ",
				"Diamond Sleet ",
				"Guardians of Peace",
				"HIDDEN COBRA ",
				"High Anonymous",
				"Labyrinth Chollima ",
				"Lazarus Group ",
				"NNPT Group",
				"New Romanic Cyber Army Team",
				"Temp.Hermit ",
				"UNC577 ",
				"Who Am I?",
				"Whois Team",
				"ZINC "
			],
			"source_name": "Secureworks:NICKEL ACADEMY",
			"tools": [
				"Destover",
				"KorHigh",
				"Volgmer"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434541,
	"ts_updated_at": 1775791443,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ba1e86cab43b260be1cd6f45bb95b97e42f15226.pdf",
		"text": "https://archive.orkl.eu/ba1e86cab43b260be1cd6f45bb95b97e42f15226.txt",
		"img": "https://archive.orkl.eu/ba1e86cab43b260be1cd6f45bb95b97e42f15226.jpg"
	}
}