{
	"id": "5dab1b90-d0f1-4c05-8fed-f93a3e269409",
	"created_at": "2026-04-06T00:21:00.119501Z",
	"updated_at": "2026-04-10T13:12:04.267877Z",
	"deleted_at": null,
	"sha1_hash": "ec47460d74fca9b12a0defb273c9c927197b2450",
	"title": "De-obfuscating ALCATRAZ",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2697891,
	"plain_text": "De-obfuscating ALCATRAZ\r\nBy Daniel Stepanic\r\nPublished: 2025-05-23 · Archived: 2026-04-05 16:30:52 UTC\r\nIntroduction\r\nElastic Security Labs analyzes diverse malware that comes through our threat hunting pipelines and telemetry queues. We\r\nrecently ran into a new malware family called DOUBLELOADER, seen alongside the RHADAMANTHYS infostealer. One\r\ninteresting attribute of DOUBLELOADER is that it is protected with an open-source obfuscator, ALCATRAZ first released\r\nin 2023. While this project had its roots in the game hacking community, it’s also been observed in the e-crime space, and\r\nhas been used in targeted intrusions.\r\nThe objective of this post is to walk through various obfuscation techniques employed by ALCATRAZ, while highlighting\r\nmethods to combat these techniques as malware analysts. These techniques include control flow flattening, instruction\r\nmutation, constant unfolding, LEA constant hiding, anti-disassembly tricks and entrypoint obfuscation.\r\nKey takeaways\r\nThe open-source obfuscator ALCATRAZ has been seen within new malware deployed alongside\r\nRHADAMANTHYS infections\r\nObfuscation techniques such as control flow flattening continue to serve as road blocks for analysts\r\nBy understanding obfuscation techniques and how to counter them, organizations can improve their ability to\r\neffectively triage and analyze protected binaries.\r\nElastic Security Labs releases tooling to deobfuscate ALCATRAZ protected binaries are released with this post\r\nDOUBLELOADER\r\nStarting last December, our team observed a generic backdoor malware coupled with RHADAMANTHYS stealer\r\ninfections. Based on the PDB path, this malware is self-described as DOUBLELOADER.\r\nPDB path in DOUBLELOADER\r\nThis malware leverages syscalls such as NtOpenProcess , NtWriteVirtualMemory , NtCreateThreadEx launching\r\nunbacked code within the Windows desktop/file manager ( explorer.exe ). The malware collects host information, requests\r\nan updated version of itself and starts beaconing to a hardcoded IP ( 185.147.125.81 ) stored within the binary.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 1 of 19\n\nOutbound C2 traffic from DOUBLELOADER\r\nDOUBLELOADER samples include a non-standard section ( .0Dev ) with executable permissions, this is a toolmark left\r\nbased on the author's handle for the binary obfuscation tool, ALCATRAZ .\r\nSection creation using ALCATRAZ\r\nObfuscators such as ALCATRAZ end up increasing the complexity when triaging malware. Its main goal is to hinder binary\r\nanalysis tools and increase the time of the reverse engineering process through different techniques; such as hiding the\r\ncontrol flow or making decompilation hard to follow. Below is an example of obfuscated control flow of one function inside\r\nDOUBLELOADER.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 2 of 19\n\nObfuscated control flow in DOUBLELOADER\r\nThe remainder of the post will focus on the various obfuscation techniques used by ALCATRAZ. We will use the first-stage\r\nof DOUBLELOADER along with basic code examples to highlight ALCATRAZ's features.\r\nALCATRAZ\r\nALCATRAZ Overview\r\nAlcatraz is an open-source obfuscator initially released in January 2023. While the project is recognized within the game\r\nhacking community as a foundational tool for learning obfuscation techniques, it’s also been observed being abused by e-https://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 3 of 19\n\ncrime and APT groups.\r\nAlcatraz’s code base contains 5 main features centered around standard code obfuscation techniques along with\r\nenhancement to obfuscate the entrypoint. Its workflow follows a standard bin2bin format, this means the user provides a\r\ncompiled binary then after the transformations, they will receive a new compiled binary. This approach is particularly\r\nappealing to game hackers/malware developers due to its ease of use, requiring minimal effort and no modifications at the\r\nsource code level.\r\nALCATRAZ - menu\r\nThe developer can choose to obfuscate all or specific functions as well as choose which obfuscation techniques to apply to\r\neach function. After compilation, the file is generated with the string ( obf ) appended to the end of the filename.\r\nExample of binary before and after obfuscation\r\nObfuscation techniques in ALCATRAZ\r\nThe following sections will go through the various obfuscation techniques implemented by ALCATRAZ.\r\nEntrypoint obfuscation\r\nDealing with an obfuscated entrypoint is like getting a flat tire at the start of a family roadtrip. The idea is centered on\r\nconfusing analysts and binary tooling where it’s not directly clear where the program starts, causing confusion at the very\r\nbeginning of the analysis process.\r\nThe following is the view of a clean entrypoint ( 0x140001368 ) from a non-obfuscated program within IDA Pro.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 4 of 19\n\nNon-obfuscated entrypoint\r\nBy enabling entrypoint obfuscation, ALCATRAZ moves the entrypoint then includes additional code with an algorithm to\r\ncalculate the new entrypoint of the program. Below is a snippet of the decompiled view of the obfuscated entry-point.\r\nDecompilation of obfuscated entrypoint\r\nAs ALCATRAZ is an open-source obfuscator, we can find the custom entrypoint code to see how the calculation is\r\nperformed or reverse our own obfuscated example. In our decompilation, we can see the algorithm uses a few fields from\r\nthe PE header such as the Size of the Stack Commit , Time Date Stamp along with the first four bytes from the .0dev\r\nsection. These fields are parsed then used with bitwise operations such as rotate right (ROR) and exclusive-or (XOR) to\r\ncalculate the entrypoint.\r\nBelow is an example output of IDA Python script (Appendix A) that parses the PE and finds the true entrypoint, confirming\r\nthe original starting point ( 0x140001368 ) with the non-obfuscated sample.\r\nReal entrypoint after obfuscation\r\nAnti-disassembly\r\nMalware developers and obfuscators use anti-disassembly tricks to confuse or break disassemblers in order to make static\r\nanalysis harder. These techniques abuse weaknesses during linear sweeps and recursive disassembly, preventing clean code\r\nreconstruction where the analyst is then forced to manually or automatically fix the underlying instructions.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 5 of 19\n\nALCATRAZ implements one form of this technique by modifying any instructions starting with the 0xFF byte by adding a\r\nshort jump instruction ( 0xEB ) in front. The 0xFF byte can represent the start of multiple valid instructions dealing with\r\ncalls, indirect jumps, pushes on the stack. By adding the short jump 0xEB in front, this effectively jumps to the next byte\r\n0xFF . While it’s not complex, the damage is done breaking disassembly and requiring some kind of intervention.\r\nAnti-disassembly technique in ALCATRAZ\r\nIn order to fix this specific technique, the file can be patched by replacing each occurrence of the 0xEB byte with NOPs.\r\nAfter patching, the code is restored to a cleaner state, allowing the following call instruction to be correctly disassembled.\r\nAnti-disassembly recovery\r\nInstruction Mutation\r\nOne common technique used by obfuscators is instruction mutation, where instructions are transformed in a way that\r\npreserves their original behavior, but makes the code harder to understand. Frameworks such as Tigress or Perses are great\r\nexamples of obfuscation research around instruction mutation.\r\nBelow is an example of this technique implemented by ALCATRAZ, where any addition between two registers is altered,\r\nbut its semantic equivalence is kept intact. The simple add instruction gets transformed to 5 different instructions ( push ,\r\nnot , sub , pop , sub ).\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 6 of 19\n\nExample of instruction mutation via ALCATRAZ\r\nIn order to correct this, we can use pattern matching to find these 5 instructions together, disassemble the bytes to find which\r\nregisters are involved, then use an assembler such as Keystone to generate the correct corresponding bytes.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 7 of 19\n\nRecovering instructions from mutation technique\r\nConstant Unfolding\r\nThis obfuscation technique is prevalent throughout the DOUBLELOADER sample and is a widely used method in various\r\nforms of malware. The concept here is focused on inversing the compilation process; where instead of optimizing\r\ncalculations that are known at compile time, the obfuscator “unfolds” these constants making the disassembly and\r\ndecompilation complex and confusing. Below is a simple example of this technique where the known constant ( 46 ) is\r\nbroken up into two mathematical operations.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 8 of 19\n\nUnfolding process example\r\nIn DOUBLELOADER, we run into this technique being used anytime when immediate values are moved into a register.\r\nThese immediate values are replaced with multiple bitwise operations masking these constant values, thus disrupting any\r\ncontext and the analyst’s flow. For example, in the disassembly below on the left-hand side, there is a comparison instruction\r\nof EAX value at address ( 0x18016CD93 ). By reviewing the previous instructions, it’s not obvious or clear what the EAX\r\nvalue should be due to multiple obscure bitwise calculations. If we debug the program, we can see the EAX value is set to\r\n0 .\r\nViewing unfolding technique in debugger\r\nIn order to clean this obfuscation technique, we can confirm its behavior with our own example where we can use the\r\nfollowing source code and see how the transformation is applied.\r\n#include \u003ciostream\u003e\r\nint add(int a, int b)\r\n{\r\nreturn a + b;\r\n}\r\nint main()\r\n{\r\nint c;\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 9 of 19\n\nc = add(1, 2);\r\nprintf(\"Meow %d\",c);\r\nreturn 0;\r\n}\r\nAfter compiling, we can view the disassembly of the main function in the clean version on the left and see these two\r\nconstants ( 2,1 ) moved into the EDX and ECX register. On the right side, is the transformed version, the two constants are\r\nhidden among the newly added instructions.\r\nMutation transformation: before vs after\r\nBy using pattern matching techniques, we can look for these sequences of instructions, emulate the instructions to perform\r\nthe various calculations to get the original values back, and then patch the remaining bytes with NOP’s to make sure the\r\nprogram will still run.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 10 of 19\n\nUsing emulation to repair immediate moves\r\nLEA Obfuscation\r\nSimilar to the previously discussed technique, LEA (Load Effective Address) obfuscation is focused on obscuring the\r\nimmediate values associated with LEA instructions. An arithmetic calculation with subtraction will follow directly behind\r\nthe LEA instruction to compute the original intended value. While this may seem like a minor change, it can have a\r\nsignificant impact breaking cross-references to strings and data — which are essential for effective binary analysis.\r\nBelow is an example of this technique within DOUBLELOADER where the RAX register value is disguised through a\r\npattern of loading an initial value ( 0x1F4DFCF4F ), then subtracting ( 0x74D983C7 ) to give us a new computed value\r\n( 0x180064B88 ).\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 11 of 19\n\nLEA obfuscation pattern in ALCATRAZ\r\nIf we go to that address inside our sample, we are taken to the read-only data section, where we can find the referenced\r\nstring bad array new length .\r\nReferenced string after LEA obfuscation\r\nIn order to correct this technique, we can use pattern matching to find these specific instructions, perform the calculation,\r\nthen re-construct a new LEA instruction. Within 64-bit mode, LEA uses RIP-relative addressing so the address is calculated\r\nbased on the current instruction pointer (RIP). Ultimately, we end up with a new instruction that looks like this: lea rax,\r\n[rip - 0xFF827] .\r\nBelow are the steps to produce this final instruction:\r\nDisplacement calculation for LEA instruction\r\nWith this information, we can use IDA Python to patch all these patterns out, below is an example of a fixed LEA\r\ninstruction.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 12 of 19\n\nPatching LEA instructions in DOUBLELOADER\r\nControl Flow Obfuscation\r\nControl flow flattening is a powerful obfuscation technique that disrupts the traditional structure of a program’s control\r\nflow by eliminating conventional constructs like conditional branches and loops. Instead, it restructures execution using a\r\ncentralized dispatcher, which determines the next basic block to execute based on a state variable, making analysis and\r\ndecompilation significantly more difficult. Below is a simple diagram that represents the differences between an unflattened\r\nand flattened control flow.\r\nStandard control flow vs flattened control flow\r\nOur team has observed this technique in various malware such as DOORME and it should come as no surprise in this case,\r\nthat flattened control flow is one of the main features within the ALCATRAZ obfuscator. In order to approach un-flattening,\r\nwe focused on established tooling by using IDA plugin D810 written by security researcher Boris Batteux.\r\nWe will start with our previous example program using the common _security_init_cookie function used to detect buffer\r\noverflows. Below is the control flow diagram of the cookie initialization function in non-obfuscated form. Based on the\r\ngraph, we can see there are six basic blocks, two conditional branches, and we can easily follow the execution flow.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 13 of 19\n\nControl flow of non-obfuscated security_init_cookie function\r\nIf we take the same function and apply ALCATRAZ's control flow flattening feature, the program’s control flow looks\r\nvastly different with 22 basic blocks, 8 conditional branches, and a new dispatcher. In the figure below, the color-filled\r\nblocks represent the previous basic blocks from the non-obfuscated version, the remaining blocks in white represent added\r\nobfuscator code used for dispatching and controlling the execution.\r\nObfuscated control flow of security_init_cookie function\r\nIf we take a look at the decompilation, we can see the function is now broken into different parts within a while loop\r\nwhere a new state variable is used to guide the program along with remnants from the obfuscation including\r\npopf/pushf instructions.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 14 of 19\n\nObfuscated decompilation of security_init_cookie function\r\nFor cleaning this function, D810 applies two different rules ( UnflattenerFakeJump ,\r\nFixPredecessorOfConditionalJumpBlock ) that apply microcode transformations to improve decompilation.\r\n2025-04-03 15:44:50,182 - D810 - INFO - Starting decompilation of function at 0x140025098\r\n2025-04-03 15:44:50,334 - D810 - INFO - glbopt finished for function at 0x140025098\r\n2025-04-03 15:44:50,334 - D810 - INFO - BlkRule 'UnflattenerFakeJump' has been used 1 times for a total of 3 patches\r\n2025-04-03 15:44:50,334 - D810 - INFO - BlkRule 'FixPredecessorOfConditionalJumpBlock' has been used 1 times for a total o\r\nWhen we refresh the decompiler, the control-flow flattening is removed, and the pseudocode is cleaned up.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 15 of 19\n\nControl-flow obfuscation removed from decompilation by D810\r\nWhile this is a good example, fixing control-flow obfuscation can often be a manual and timely process that is function-dependent. In the next section, we will gather up some of the techniques we learned and apply it to DOUBLELOADER.\r\nCleaning a DOUBLELOADER function\r\nOne of the challenges when dealing with obfuscation in malware is not so much the individual obfuscation techniques, but\r\nwhen the techniques are layered. Additionally, in the case of DOUBLELOADER, large portions of code are placed in\r\nfunction chunks with ambiguous boundaries, making it challenging to analyze. In this section, we will go through a practical\r\nexample showing the cleaning process for a DOUBLELOADER function protected by ALCATRAZ.\r\nUpon launch at the Start export, one of the first calls goes to loc_18016C6D9 . This appears to be an entry to a larger\r\nfunction, however IDA is not properly able to create a function due to undefined instructions at 0x18016C8C1 .\r\nExample of DoubleLoader causing error in IDA Pro\r\nIf we scroll to this address, we can see the first disruption is due to the short jump anti-disassembly technique which we saw\r\nearlier in the blog post ( EB FF ).\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 16 of 19\n\nAnti-disassembly technique in DoubleLoader\r\nAfter fixing 6 nearby occurrences of this same technique, we can go back to the start address ( 0x18016C6D9 ) and use the\r\nMakeFunction feature. While the function will decompile, it is still heavily obfuscated which is not ideal for any analysis.\r\nDoubleLoader function with ALCATRAZ obfuscation\r\nGoing back to the disassembly, we can see the LEA obfuscation technique used in this function below where the string\r\nconstant ”Error” is now recovered using the earlier solution.\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 17 of 19\n\nRestoring string constant from LEA obfuscation\r\nAnother example below shows the transformation of an obfuscated parameter for a LoadIcon call where the lpIconName\r\nparameter gets cleaned to 0x7f00 ( IDI_APPLICATION ).\r\nRestoring LoadIcon parameter from immediate mov obfuscation\r\nNow that the decompilation has improved, we can finalize the cleanup by removing control flow obfuscation with the D810\r\nplugin. Below is a demonstration showing the before and after effects.\r\nDecompilation cleanup of DoubleLoader function using D810\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 18 of 19\n\nThis section has covered a real-world scenario of working towards cleaning a malicious obfuscated function protected by\r\nALCATRAZ. While malware analysis reports often show the final outcomes, a good portion of time is often spent up-front\r\nworking towards removing obfuscation and fixing up the binary so it can then be properly analyzed.\r\nIDA Python Scripts\r\nOur team is releasing a series of proof-of-concept IDA Python scripts used to handle the default obfuscation techniques\r\nimposed by the ALCATRAZ obfuscator. These are meant to serve as basic examples when dealing with these techniques,\r\nand should be used for research purposes. Unfortunately, there is no silver bullet when dealing with obfuscation, but having\r\nsome examples and general strategies can be valuable for tackling similar challenges in the future.\r\nYARA\r\nElastic Security has created YARA rules to identify this activity.\r\nWindows.Trojan.DoubleLoader\r\nObservations\r\nThe following observables were discussed in this research.\r\nObservable Type Name Reference\r\n3050c464360ba7004d60f3ea7ebdf85d9a778d931fbf1041fa5867b930e1f7fd SHA256 DoubleLo.dll DOUBLELOADER\r\nReferences\r\nThe following were referenced throughout the above research:\r\nhttps://github.com/weak1337/Alcatraz\r\nhttps://gitlab.com/eshard/d810\r\nhttps://eshard.com/posts/d810-deobfuscation-ida-pro\r\nhttp://keowu.re/posts/Analyzing-Mutation-Coded-VM-Protect-and-Alcatraz-English/\r\nSource: https://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nhttps://www.elastic.co/security-labs/deobfuscating-alcatraz\r\nPage 19 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.elastic.co/security-labs/deobfuscating-alcatraz"
	],
	"report_names": [
		"deobfuscating-alcatraz"
	],
	"threat_actors": [],
	"ts_created_at": 1775434860,
	"ts_updated_at": 1775826724,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ec47460d74fca9b12a0defb273c9c927197b2450.pdf",
		"text": "https://archive.orkl.eu/ec47460d74fca9b12a0defb273c9c927197b2450.txt",
		"img": "https://archive.orkl.eu/ec47460d74fca9b12a0defb273c9c927197b2450.jpg"
	}
}