{ "id": "7d1f20ab-1aa6-4213-a645-0297552f0eb3", "created_at": "2026-04-06T00:21:15.980937Z", "updated_at": "2026-04-10T03:21:15.595729Z", "deleted_at": null, "sha1_hash": "3ceb35c545b6a3d85c392a111d958256689a9c2a", "title": "Defeating BazarLoader Anti-Analysis Techniques", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 854700, "plain_text": "Defeating BazarLoader Anti-Analysis Techniques\r\nBy Mark Lim\r\nPublished: 2022-04-25 · Archived: 2026-04-05 16:27:50 UTC\r\nExecutive Summary\r\nMalware authors embed multiple anti-analysis techniques in their code to retard the analysis processes of human\r\nanalysts and sandboxes. However, there are ways defenders can defeat these techniques in turn. This blog post\r\ndescribes two methods for faster analysis of malware that employs two distinctive anti-analysis techniques. The\r\nfirst technique is API function hashing, a known trick to obfuscate which functions are called. The second is\r\nopaque predicate, a technique used for control flow obfuscation.\r\nThe scripts that we are going to show here can be applied to BazarLoader, as well as other malware families that\r\nutilize similar anti-analysis techniques. As an illustration, we will show the IDAPython scripts we created during a\r\nrecent analysis of BazarLoader with the reverse engineering tool IDA Pro to defeat these anti-analysis techniques.\r\nBazarLoader is a Windows backdoor that is used by various ransomware groups.\r\nPalo Alto Networks customers are protected from malware families using similar anti-analysis techniques with\r\nCortex XDR or the Next-Generation Firewall with the WildFire and Threat Prevention security subscriptions.\r\nReusing Malware Code to Defeat Obfuscated API Calls\r\nMalware compiled as native files has to call Windows API functions to carry out malicious behaviors. The\r\ninformation on which functions are used is usually stored in the Import Address Table (IAT) in the file. Therefore,\r\nthis table is often a good place to start the analysis process to get an idea of what the malware is trying to do.\r\nTo demonstrate, we focused on a BazarLoader sample we recently detected. After peeling away the packer layer\r\nof our BazarLoader sample, we saw that it doesn’t have an IAT (see Figure 1). Also, there is no IAT constructed\r\nduring execution, a technique sometimes seen in other malware. BazarLoader obfuscates its function calls to make\r\nanalysis more difficult and to evade detection techniques that rely on reading the IAT.\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 1 of 11\n\nFigure 1. Missing IAT in BazarLoader as seen with CFF Explorer.\r\nIn fact, BazarLoader resolves every API function to be called individually at run time. After we figured out that\r\nthe functions are resolved during execution, the following function caught our attention as it was referenced more\r\nthan 300 times:\r\nFigure 2. Function for resolving the obfuscated Windows API functions (marked in yellow).\r\nWhile most pieces of malware rely on publicly known hashing algorithms to resolve the functions’ addresses, the\r\none used by BazarLoader is unique. The API function resolution procedure (sub_18000B9B0, labelled as\r\nFN_API_Decoder) requires three parameters and returns the address of the requested function.\r\nNow, we could reverse engineer the algorithm used in FN_API_Decoder and reimplement it in Python to get all\r\nfunctions resolved. However, this would take a lot of time and we would have to repeat the whole process for\r\nevery piece of malware that uses a different hashing algorithm.\r\nInstead, the approach we used is independent from the hashing algorithm as it makes use of the hashing function\r\nitself. For this, we used the Appcall feature with IDAPython in IDA Pro to call FN_API_Decoder and pass it the\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 2 of 11\n\nrequired parameters. The result from Appcall would be the resolved address of the Windows API function. The\r\nAppcall feature used while debugging the malware allows us to execute any function from the sample as if it were\r\na built-in function.\r\nUsing the following code, we can run FN_API_Decoder to resolve Windows API function addresses while\r\ndebugging the malware process.\r\nFigure 3. Using Appcall with IDAPython.\r\nNext, we gathered all the required parameters by looking up all the cross references to FN_API_Decoder. The\r\nfollowing code will search and extract the required parameters for resolving the API function calls.\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 3 of 11\n\nFigure 4. IDAPython code to search and extract the three parameters.\r\nFinally, by using the returned value from Appcall we are able to rename all the dynamic calls to the APIs to their\r\ncorresponding names and apply comments:\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 4 of 11\n\nFigure 5. IDAPython code to locate dynamic calls.\r\nPutting the above steps together, we deobfuscated the API function calls:\r\nFigure 6. Before executing the above IDAPython scripts.\r\nFigure 7. Renamed API function call with added comment.\r\nAfter all the API function calls are renamed, we can now easily locate other interesting functions in the malware.\r\nFor example, sub_1800155E0 is the procedure in BazarLoader that carries out code injection.\r\nFigure 8. Before renaming API calls.\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 5 of 11\n\nFigure 9. Obfuscated API calls labeled with APIs related to code injection.\r\nWith the help of our IDAPython scripts, we are now able to faster assess which functionality this BazarLoader\r\nsample contains.\r\nAutomating Opaque Predicate Removal\r\nOpaque Predicate (OP) is used in BazarLoader to protect it from reverse engineering tools. OP is an expression\r\nthat evaluates to either true or false at runtime. Malware authors make use of multiple OPs together with\r\nunexecuted code blocks to add complexities that static analysis tools have to deal with.\r\nThe following disassembled code shows one of the OPs in Bazarloader:\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 6 of 11\n\nFigure 10. One example of OP in BazarLoader.\r\nFrom the above control flow graph (CFG), the code flow won’t end up in infinite loops (Figure 10, red code\r\nblocks). Therefore, the above OP will be evaluated to avoid the infinite loop.\r\nWe can demonstrate the extent of the challenge OPs pose to malware analysts. The following CFG shows the\r\nunexecuted code blocks (Figure 11, red code blocks) in one of the smaller functions (sub_18000F640) in the\r\nsample.\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 7 of 11\n\nFigure 11. sub_18000F640 function in BazarLoader with unexecuted code blocks colored in red.\r\nWe could manually patch away the code blocks that are not executed as we analyze each function in the sample,\r\nbut this is not very practical and takes a lot of time. Instead, we will choose a smarter way by doing it\r\nautomatically.\r\nFirst, we have to locate all the OPs. The most common way to do this is to make use of the binary search\r\nmechanism in IDA Pro to find all the byte sequences of the OPs. This turns out not to be possible, as the OPs were\r\nlikely generated by a compiler during the build process of the malware sample. There are just too many variants of\r\nthe OPs that could be covered using the byte sequence.\r\nNot only do we need to locate the OPs, we also have to know the exact point when the malware sample decides to\r\navoid the unexecuted code blocks.\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 8 of 11\n\nUsing the following code, we locate the OPs in a function:\r\nFigure 12. IDAPython code to locate the OPs in a function.\r\nNext, we have to patch the instructions in OPs to force the code flow away from the unexecuted code blocks.\r\nUsing the following code, we patch the OPs in a function:\r\nFigure 13. IDAPython code to patch the OPs.\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 9 of 11\n\nThe OPs also messed with the output of the HexRays decompiler. This is how the function (sub_18000F640)\r\nlooks before the OPs are patched:\r\nFigure 14. Decompiled sub_18000F640 function.\r\nAfter applying the two techniques above, we have decompiled pseudocode that is much easier to read and\r\nunderstand.\r\nAfter patching all the OPs and renaming the obfuscated API calls, we could then tell that the function\r\n(sub_18000F640) is just a wrapper function for GetModuleFileNameW().\r\nFigure 15. Decompiled sub_18000F640 function after removing the OPs.\r\nMalware Analysts vs Malware Authors\r\nMalware authors often include anti-analysis techniques with the hope that they will increase the time and\r\nresources taken for malware analysts. With the above script snippets showing how to defeat these techniques for\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 10 of 11\n\nBazarLoader, you can reduce the time needed to analyze malware samples of other families that use similar\r\ntechniques.\r\nPalo Alto Networks customers are further protected from malware families using similar anti-analysis techniques\r\nwith Cortex XDR or the Next-Generation Firewall with the WildFire and Threat Prevention cloud-delivered\r\nsecurity subscriptions.\r\nIndicators of Compromise\r\nBazarLoader Sample ce5ee2fd8aa4acda24baf6221b5de66220172da0eb312705936adc5b164cc052\r\nSource: https://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nhttps://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/\r\nPage 11 of 11", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "references": [ "https://unit42.paloaltonetworks.com/bazarloader-anti-analysis-techniques/" ], "report_names": [ "bazarloader-anti-analysis-techniques" ], "threat_actors": [], "ts_created_at": 1775434875, "ts_updated_at": 1775791275, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/3ceb35c545b6a3d85c392a111d958256689a9c2a.pdf", "text": "https://archive.orkl.eu/3ceb35c545b6a3d85c392a111d958256689a9c2a.txt", "img": "https://archive.orkl.eu/3ceb35c545b6a3d85c392a111d958256689a9c2a.jpg" } }