{
	"id": "0fc68007-2a56-4dd9-a794-9da0acc5c8dd",
	"created_at": "2026-04-06T00:11:30.532498Z",
	"updated_at": "2026-04-10T03:36:48.074585Z",
	"deleted_at": null,
	"sha1_hash": "efe8996bf4dc5abfc3adef0dee72767efe9d11c1",
	"title": "Bypassing MassLogger Anti-Analysis — a Man-in-the-Middle Approach | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3084327,
	"plain_text": "Bypassing MassLogger Anti-Analysis — a Man-in-the-Middle\r\nApproach | Mandiant\r\nBy Mandiant\r\nPublished: 2020-08-06 · Archived: 2026-04-05 18:24:56 UTC\r\nThe FireEye Front Line Applied Research \u0026 Expertise (FLARE) Team attempts to always stay on top of the most\r\ncurrent and emerging threats. As a member of the FLARE Reverse Engineer team, I recently received a request to\r\nanalyze a fairly new credential stealer identified as MassLogger. Despite the lack of novel functionalities and\r\nfeatures, this sample employs a sophisticated technique that replaces the Microsoft Intermediate Language (MSIL)\r\nat run time to hinder static analysis. At the time of this writing, there is only one publication discussing the\r\nMassLogger obfuscation technique in some detail. Therefore, I decided to share my research and tools to help\r\nanalyze MassLogger and other malware using a similar technique. Let us take a deep technical dive into the\r\nMassLogger credential stealer and the .NET runtime.\r\nTriage\r\nMassLogger is a .NET credential stealer. It starts with a launcher\r\n(6b975fd7e3eb0d30b6dbe71b8004b06de6bba4d0870e165de4bde7ab82154871) that uses simple anti-debugging\r\ntechniques which can be easily bypassed when identified. This first stage loader eventually XOR-decrypts the\r\nsecond stage assembly which then decrypts, loads and executes the final MassLogger payload\r\n(bc07c3090befb5e94624ca4a49ee88b3265a3d1d288f79588be7bb356a0f9fae) named Bin-123.exe. The final\r\npayload can be easily extracted and executed independently. Therefore, we will focus exclusively on this final\r\npayload where the main anti analysis technique is used.\r\nBasic static analysis doesn’t reveal anything too exciting. We notice some interesting strings, but they are not\r\nenough to give us any hints about the malware’s capabilities. Executing the payload in a controlled environment\r\nshows that the sample drops a log file that identifies the malware family, its version, and most importantly some\r\nconfiguration options. A sample log file is described in Figure 1. We can also extract some interesting strings from\r\nmemory as the sample runs. However, basic dynamic analysis is not sufficient to extract all host-based indicators\r\n(HBIs), network-based indicators (NBIs) and complete malware functionality. We must perform a deeper analysis\r\nto better understand the sample and its capabilities.\r\nUser Name: user\r\nIP: 127.0.0.1\r\nLocation: United States\r\nOS: Microsoft Windows 7 Ultimate 32bit\r\nCPU: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz\r\nGPU: VMware SVGA 3D\r\nAV: NA\r\nScreen Resolution: 1438x2460\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 1 of 15\n\nCurrent Time: 6/17/2020 1:23:30 PM\r\nMassLogger Started: 6/17/2020 1:23:21 PM\r\nInterval: 2 hour\r\nMassLogger Process: C:\\Users\\user\\Desktop\\Bin-123.exe\r\nMassLogger Melt: false\r\nMassLogger Exit after delivery: false\r\nAs Administrator: False\r\nProcesses:\r\nName:cmd, Title:Administrator: FakeNet-NG - fakenet\r\nName:iexplore, Title:FakeNet-NG - Internet Explorer\r\nName:dnSpy-x86, Title:dnSpy v6.0.5 (32-bit)\r\nName:cmd, Title:Administrator: C:\\Windows\\System32\\cmd.exe\r\nName:ProcessHacker, Title:Process Hacker [WIN-R23GG4KO4SD\\user]+ (Administrator)\r\n### WD Exclusion ###\r\nDisabled\r\n### USB Spread ###\r\nDisabled\r\n### Binder ###\r\nDisabled\r\n### Window Searcher ###\r\nDisabled\r\n### Downloader ###\r\nDisabled\r\n### Bot Killer ###\r\nDisabled\r\n### Search And Upload ###\r\nDisabled\r\n### Telegram Desktop ###\r\nNot Installed\r\n### Pidgin ###\r\nNot Installed\r\n### FileZilla ###\r\nNot Installed\r\n### Discord Tokken ###\r\nNot Installed\r\n### NordVPN ###\r\nNot Installed\r\n### Outlook ###\r\nNot Installed\r\n### FoxMail ###\r\nNot Installed\r\n### Thunderbird ###\r\nNot Installed\r\n### QQ Browser ###\r\nNot Installed\r\n### FireFox ###\r\nNot Installed\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 2 of 15\n\n### Chromium Recovery ###\r\nNot Installed\r\n### Keylogger And Clipboard ###\r\n \r\n[20/06/17] [Welcome to Chrome - Google Chrome]\r\n[ESC]\r\n[20/06/17] [Clipboard]\r\nVewgbprxvhvjktmyxofjvpzgazqszaoo\r\nFigure 1: Sample MassLogger log\r\nJust Decompile It\r\nLike many other .NET malwares, MassLogger obfuscates all of its methods names and even the method control\r\nflow. We can use de4dot to automatically deobfuscate the MassLogger payload. However, looking at the\r\ndeobfuscated payload, we quickly identify a major issue: Most of the methods contain almost no logic as shown in\r\nFigure 2.\r\nFigure 2: dnSpy showing empty methods\r\nLooking at the original MassLogger payload in dnSpy’s Intermediate Language (IL) view confirms that most\r\nmethods do not contain any logic and simply return nothing. This is obviously not the real malware since we\r\nalready observed with dynamic analysis that the sample indeed performs malicious activities and logging to a log\r\nfile. We are left with a few methods, most notably the method with the token 0x0600049D called first thing in the\r\nmain module constructor.\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 3 of 15\n\nFigure 3: dnSpy IL view showing the method's details\r\nMethod 0x0600049D control flow has been obfuscated into a series of switch statements. We can still somewhat\r\nfollow the method’s high-level logic with the help of dnSpy as a debugger. However, fully analyzing the method\r\nwould be very time consuming. Instead, when first analyzing this payload, I chose to quickly scan over the entire\r\nmodule to look for hints. Luckily, I spot a few interesting strings I missed during basic static analysis: clrjit.dll,\r\nVirtualAlloc, VirtualProtect and WriteProcessMemory as seen in Figure 4.\r\nFigure 4: Interesting strings scattered throughout the module\r\nA quick internet search for “clrjit.dll” and “VirtualProtect” quickly takes us to a few publications describing a\r\ntechnique commonly referred to as Just-In-Time Hooking. In essence, JIT Hooking involves installing a hook at\r\nthe compileMethod() function where the JIT compiler is about to compile the MSIL into assembly (x86, x64, etc).\r\nWith the hook in place, the malware can easily replace each method body with the real MSIL that contains the\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 4 of 15\n\noriginal malware logic. To fully understand this process, let’s explore the .NET executable, the .NET methods, and\r\nhow MSIL turns into x86 or x64 assembly.\r\n.NET Executable Methods\r\nA .NET executable is just another binary following the Portable Executable (PE) format. There are plenty of\r\nresources describing the PE file format, the .NET metadata and the .NET token tables in detail. I recommend our\r\nreaders to take a quick detour and refresh their memory on those topics before continuing. This post won’t go into\r\nfurther details but will focus on the .NET methods instead.\r\nEach .NET method in a .NET assembly is identified by a token. In fact, everything in a .NET assembly, whether\r\nit’s a module, a class, a method prototype, or a string, is identified by a token. Let’s look at method identified by\r\nthe token 0x0600049D, as shown in Figure 5. The most-significant byte (0x06) tells us that this token is a method\r\ntoken (type 0x06) instead of a module token (type 0x00), a TypeDef token (type 0x02), or a LocalVarSig token\r\n(type 0x11), for example. The three least significant bytes tell us the ID of the method, in this case it’s 0x49D\r\n(1181 in decimal). This ID is also referred to as the Method ID (MID) or the Row ID of the method.\r\nFigure 5: Method details for method 0x0600049D\r\nTo find out more information about this method, we look within the tables of the “#~” stream of the .NET\r\nmetadata streams in the .NET metadata directory as show in Figure 6. We traverse to the entry number 1181 or\r\n0x49D of the Method table to find the method metadata which includes the Relative Virtual Address (RVA) of the\r\nmethod body, various flags, a pointer to the name of the method, a pointer to the method signature, and finally, an\r\npointer to the parameters specification for this method. Please note that the MID starts at 1 instead of 0.\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 5 of 15\n\nFigure 6: Method details from the PE file header\r\nFor method 0x0600049D, the RVA of the method body is 0xB690. This RVA belongs to the .text section whose\r\nRVA is 0x2000. Therefore, this method body begins at 0x9690 (0xB690 – 0x2000) bytes into the .text section. The\r\n.text section starts at 0x200 bytes into the file according to the section header. As a result, we can find the method\r\nbody at 0x9890 (0x9690 + 0x200) bytes offset into the file. We can see the method body in Figure 7.\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 6 of 15\n\nFigure 7: Method 0x0600049D body in a hex editor\r\n.NET Method Body\r\nThe .NET method body starts with a method body header, followed by the MSIL bytes. There are two types of\r\n.NET methods: a tiny method and a fat method. Looking at the first byte of the method body header, the two least-significant bits tell us if the method is tiny (where the last two bits are 10) or fat (where the last two bits are 11).\r\n.NET Tiny Method\r\nLet’s look at method 0x06000495. Following the same steps described earlier, we check the row number 0x495\r\n(1173 in decimal) of the Method table to find the method body RVA is 0x7A7C which translates to 0x5C7C as the\r\noffset into the file. At this offset, the first byte of the method body is 0x0A (0000 1010 in binary).\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 7 of 15\n\nFigure 8: Method 0x06000495 metadata and body\r\nSince the two least-significant bits are 10, we know that 0x06000495 is a tiny method. For a tiny method, the\r\nmethod body header is one byte long. The two least-significant bits are 10 to indicate that this is the tiny method,\r\nand the six most-significant bits tell us the size of the MSIL to follow (i.e. how long the MSIL is). In this case,\r\nthe six most-significant bits are 000010, which tells us the method body is two bytes long. The entire method body\r\nfor 0x06000495 is 0A 16 2A, followed by a NULL byte, which has been disassembled by dnSpy as shown in\r\nFigure 9.\r\nFigure 9: Method 0x06000495 in dnSpy IL view\r\n.NET Fat Method\r\nComing back to method 0x0600049D (entry number 1181) at offset 0x9890 into the file (RVA 0xB690), the first\r\nbyte of the method body is 0x1B (or 0001 1011 in binary). The two least-significant bits are 11, indicating that\r\n0x0600049D is a fat method. The fat method body header is 12-byte long whose structure is beyond the scope of\r\nthis blog post. The field we really care about is a four-byte field at offset 0x04 byte into this fat header. This field\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 8 of 15\n\nspecifies the length of the MSIL that follows this method body header. For method 0x0600049D, the entire\r\nmethod body header is “1B 30 08 00 A8 61 00 00 75 00 00 11” and the length of the MSIL to follow is “A8 61 00\r\n00” or 0x61A8 (25000 in decimal) bytes.\r\nFigure 10: Method 0x0600049D body in a hex editor\r\nJIT Compilation\r\nWhether a method is tiny or fat, it does not execute as is. When the .NET runtime needs to execute a method, it\r\nfollows exactly the process described earlier to find the method body which includes the method body header and\r\nthe MSIL bytes. If this is the first time the method needs to run, the .NET runtime invokes the Just-In-Time\r\ncompiler which takes the MSIL bytes and compiles them into x86 or x64 assembly depending on whether the\r\ncurrent process is 32- or 64-bit. After some preparation, the JIT compiler eventually calls the compileMethod()\r\nfunction. The entire .NET runtime project is open-sourced and available on GitHub. We can easily find out that\r\nthe compileMethod() function has the following prototype (Figure 11):\r\nCorJitResult __stdcall compileMethod (\r\n ICorJitInfo *comp, /* IN */\r\n CORINFO_METHOD_INFO *info, /* IN */\r\n unsigned /* code:CorJitFlag */ flags, /* IN */\r\n BYTE **nativeEntry, /* OUT */\r\n ULONG *nativeSizeOfCode /* OUT */\r\n);\r\nFigure 11: compileMethod() function protype\r\nFigure 12 shows the CORINFO_METHOD_INFO structure.\r\nstruct CORINFO_METHOD_INFO\r\n{\r\n CORINFO_METHOD_HANDLE ftn;\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 9 of 15\n\nCORINFO_MODULE_HANDLE scope;\r\n BYTE * ILCode;\r\n unsigned ILCodeSize;\r\n unsigned maxStack;\r\n unsigned EHcount;\r\n CorInfoOptions options;\r\n CorInfoRegionKind regionKind;\r\n CORINFO_SIG_INFO args;\r\n CORINFO_SIG_INFO locals;\r\n};\r\nFigure 12: CORINFO_METHOD_INFO structure\r\nThe ILCode is a pointer to the MSIL of the method to compile, and the ILCodeSize tells us how long the MSIL is.\r\nThe return value of compileMethod() is an error code indicating success or failure. In case of success, the\r\nnativeEntry pointer is populated with the address of the executable memory region containing the x86 or the x64\r\ninstruction that is compiled from the MSIL.\r\nMassLogger JIT Hooking\r\nLet’s come back to MassLogger. As soon as the main module initialization runs, it first decrypts MSIL of the other\r\nmethods. It then installs a hook to execute its own version of compileMethod() (method 0x06000499). This\r\nmethod replaces the ILCode and ILCodeSize fields of the info argument to the original compileMethod() with the\r\nreal malware’s MSIL bytes.\r\nIn addition to replacing the MSIL bytes, MassLogger also patches the method body header at module initialization\r\ntime. As seen from Figure 13, the method body header of method 0x060003DD on disk (at file offset 0x3CE0) is\r\ndifferent from the header in memory (at RVA 0x5AE0). The only two things remaining quite consistent are the\r\nleast significant two bits indicating whether the method is tiny or fat. To successfully defeat this anti-analysis\r\ntechnique, we must recover the real MSIL bytes as well as the correct method body headers.\r\nFigure 13: Same method body with different headers when resting on disk vs. loaded in memory\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 10 of 15\n\nDefeating JIT Method Body Replacement With JITM\r\nTo automatically recover the MSIL and the method body header, one possible approach suggested by another\r\nFLARE team member is to install our own hook at compileMethod() function before loading and allowing the\r\nMassLogger module constructor to run. There are multiple tutorials and open-sourced projects on hooking\r\ncompileMethod() using both managed hooks (the new compileMethod() is a managed method written in C#) and\r\nnative hooks (the new compileMethod() is native and written in C or C++). However, due to the unique way\r\nMassLogger hooks compileMethod(), we cannot use the vtable hooking technique implemented by many of the\r\naforementioned projects. Therefore, I’d like to share the following project: JITM, which is designed use inline\r\nhooking implemented by PolyHook library. JITM comes with a wrapper for compileMethod() which logs all the\r\nmethod body headers and MSIL bytes to a JSON file before calling the original compileMethod().\r\nIn addition to the hook, JITM also includes a .NET loader. This loader first loads the native hook DLL\r\n(jitmhook.dll) and installs the hook. The loader then loads the MassLogger payload and executes its entry point.\r\nThis causes MassLogger’s module initialization code to execute and install its own hook, but hooking jitmhook.dll\r\ncode instead of the original compileMethod(). An alternative approach to executing MassLogger’s entry point is to\r\ncall the RuntimeHelpers.PrepareMethod() API to force the JIT compiler to run on all methods. This approach is\r\nbetter because it avoids running the malware, and it potentially can recover methods not called in the sample’s\r\nnatural code path. However, additional work is required to force all methods to be compiled properly.\r\nTo load and recover MassLogger methods, first run the following command (Figure 14):\r\njitm.exe Bin-123.exe [optional_timeout]\r\nFigure 14: Command to run jitm\r\nOnce the timeout expires, you should see the files jitm.log and jitm.json created in the current directory. jitm.json\r\ncontains the method tokens, method body headers and MSIL bytes of all methods recovered from Bin-123.exe.\r\nThe only thing left to do is to rebuild the .NET metadata so we can perform static analysis.\r\nFigure 15: Sample jitm.json\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 11 of 15\n\nRebuilding the Assembly\r\nSince the decrypted method body headers and MSIL bytes may not fit in the original .NET assembly properly, the\r\neasiest thing to do is to add a new section and a section header to MassLogger. There are plenty of resources on\r\nhow to add a PE section header and data, none of which is trivial or easy to automate. Therefore, JITM also\r\ninclude the following Python 2.7 helper script to automate this process: Scripts\\addsection.py.\r\nWith the method body header and MSIL of each method added to a new PE section as shown in Figure 16, we can\r\neasily parse the .NET metadata and fix each method’s RVA to point to the correct method body within the new\r\nsection. Unfortunately, I did not find any Python library to easily parse the .NET metadata and the MethodDef\r\ntable. Therefore, JITM also includes a partially implemented .NET metadata parser: Script\\pydnet.py. This script\r\nuses pefile and vivisect modules and parses the PE file up to the Method table to extract all methods and their\r\nassociated RVAs.\r\nFigure 16: Bin-123.exe before and after adding an additional section named FLARE\r\nFinally, to tie everything together, JITM provides Script\\fix_assembly.py to perform the following tasks:\r\n1. Write the method body header and MSIL of each method recovered in jitm.json into a temporary binary\r\nfile named “section.bin” while at the same time remember the associated method token and the offset into\r\nsection.bin.\r\n2. Use addsection.py to add section.bin into Bin-123.exe and save the data into a new file, e.g. Bin-123.fixed.exe.\r\n3. Use pydnet.py to parse Bin-123.fixed.exe and update the RVA field of each method entry in the MethodDef\r\ntable to point to the correct RVA into the new section.\r\nThe final result is a partially reconstructed .NET assembly. Although additional work is necessary to get this\r\nassembly to run correctly, it is good enough to perform static analysis to understand the malware’s high-level\r\nfunctionalities.\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 12 of 15\n\nLet’s look at the reconstructed method 0x0600043E that implements the decryption logic for the malware\r\nconfiguration. Compared to the original MSIL, the reconstructed MSIL now shows that the malware uses AES-256 in CBC mode with PKCS7 padding. With a combination of dynamic analysis and static analysis, we can also\r\neasily identify the key to be “Vewgbprxvhvjktmyxofjvpzgazqszaoo” and the IV to be part of the Base64-encoded\r\nbuffer passed in as its argument.\r\nFigure 17: Method 0x0600043 before and after fixing the assembly\r\nArmed with that knowledge, we can write a simple tool to decrypt the malware configuration and recover all HBIs\r\nand NBIs (Figure 18).\r\n BinderBytes: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\n BinderName: Mzvmy_Nyrrd\r\n BinderOnce: false\r\n DownloaderFilename: Hrebxs\r\n DownloaderOnce: false\r\n DownloaderUrl: Vrwus\r\n EmailAddress: appfoil@outlook.com\r\n EmailClient: smtp.outlook.com\r\n EmailEnable: true\r\n EmailPass: services000\r\n EmailPort: 587\r\n EmailSendTo: appfoil@outlook.com\r\n EmailSsl: True\r\n EnableAntiDebugger: false\r\n EnableAntiHoneypot: false\r\n EnableAntiSandboxie: false\r\n EnableAntiVMware: false\r\n EnableBinder: false\r\n EnableBotKiller: false\r\n EnableBrowserRecovery: true\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 13 of 15\n\nEnableDeleteZoneIdentifier: false\r\n EnableDownloader: false\r\n EnableForceUac: false\r\n EnableInstall: false\r\n EnableKeylogger: true\r\n EnableMemoryScan: false\r\n EnableMutex: false\r\n EnableScreenshot: false\r\n EnableSearchAndUpload: false\r\n EnableSpreadUsb: false\r\n EnableWDExclusion: false\r\n EnableWindowSearcher: false\r\n ExectionDelay: 6\r\n ExitAfterDelivery: false\r\n FtpEnable: false\r\n FtpHost: ftp://127.0.0.1\r\n FtpPass:\r\n FtpPort: 21\r\n FtpUser: Foo\r\n InstallFile: Pkkbdphw\r\n InstallFolder: %AppData%\r\n InstallSecondFolder: Eqrzwmf\r\n Key:\r\n Mutex: Ysjqh\r\n PanelEnable: false\r\n PanelHost: http://example.com/panel/upload.php\r\n SearchAndUploadExtensions: .jpeg, .txt, .docx, .doc,\r\n SearchAndUploadSizeLimit: 500000\r\n SearchAndUploadZipSize: 5000000\r\n SelfDestruct: false\r\n SendingInterval: 2\r\n Version: MassLogger v1.3.4.0\r\n WindowSearcherKeywords: youtube, facebook, amazon,\r\nFigure 18: Decrypted configuration\r\nConclusion\r\nUsing a JIT compiler hook to replace the MSIL is a powerful technique that makes static analysis almost\r\nimpossible. Although this technique is not new, I haven’t seen many .NET malwares making use of it, let alone\r\ntrying to implement their own adaptation instead of using widely available protectors like ConfuserEx. Hopefully,\r\nwith this blog post and JITM, analysts will now have the tools and knowledge to defeat MassLogger or any future\r\nvariants that use a similar technique.\r\nIf this is the type of work that excites you; and, if you thrive to push the state of the art when it comes to malware\r\nanalysis and reverse engineering, the Front Line Applied Research and Expertise (FLARE) team may be a good\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 14 of 15\n\nplace for you. The FLARE team faces fun and exciting challenges on a daily basis; and we are constantly looking\r\nfor more team members to tackle these challenges head on. Check out FireEye’s career page to see if any of our\r\nopportunities would be a good fit for you.\r\nContributors (Listed Alphabetically)\r\nTyler Dean (@spresec): Technical review of the post\r\nMichael Durakovich: Technical review of the post\r\nStephen Eckels (@stevemk14ebr): Help with porting JITM to use PolyHook\r\nJon Erickson (@evil-e): Technical review of the post\r\nMoritz Raabe (@m_r_tz): Technical review of the post\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nhttps://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html\r\nPage 15 of 15\n\nFigure 6: Method For method 0x0600049D, details from the the PE file header RVA of the method body is 0xB690. This RVA belongs to the .text section whose\nRVA is 0x2000. Therefore, this method body begins at 0x9690 (0xB690 -0x2000) bytes into the .text section. The\n.text section starts at 0x200 bytes into the file according to the section header. As a result, we can find the method\nbody at 0x9890 (0x9690 + 0x200) bytes offset into the file. We can see the method body in Figure 7.\n   Page 6 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html"
	],
	"report_names": [
		"bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html"
	],
	"threat_actors": [
		{
			"id": "9f101d9c-05ea-48b9-b6f1-168cd6d06d12",
			"created_at": "2023-01-06T13:46:39.396409Z",
			"updated_at": "2026-04-10T02:00:03.312816Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"CHROMIUM",
				"ControlX",
				"TAG-22",
				"BRONZE UNIVERSITY",
				"AQUATIC PANDA",
				"RedHotel",
				"Charcoal Typhoon",
				"Red Scylla",
				"Red Dev 10",
				"BountyGlad"
			],
			"source_name": "MISPGALAXY:Earth Lusca",
			"tools": [
				"RouterGod",
				"SprySOCKS",
				"ShadowPad",
				"POISONPLUG",
				"Barlaiy",
				"Spyder",
				"FunnySwitch"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "18a7b52d-a1cd-43a3-8982-7324e3e676b7",
			"created_at": "2025-08-07T02:03:24.688416Z",
			"updated_at": "2026-04-10T02:00:03.734754Z",
			"deleted_at": null,
			"main_name": "BRONZE UNIVERSITY",
			"aliases": [
				"Aquatic Panda",
				"Aquatic Panda ",
				"CHROMIUM",
				"CHROMIUM ",
				"Charcoal Typhoon",
				"Charcoal Typhoon ",
				"Earth Lusca",
				"Earth Lusca ",
				"FISHMONGER ",
				"Red Dev 10",
				"Red Dev 10 ",
				"Red Scylla",
				"Red Scylla ",
				"RedHotel",
				"RedHotel ",
				"Tag-22",
				"Tag-22 "
			],
			"source_name": "Secureworks:BRONZE UNIVERSITY",
			"tools": [
				"Cobalt Strike",
				"Fishmaster",
				"FunnySwitch",
				"Spyder",
				"njRAT"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "6abcc917-035c-4e9b-a53f-eaee636749c3",
			"created_at": "2022-10-25T16:07:23.565337Z",
			"updated_at": "2026-04-10T02:00:04.668393Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"Bronze University",
				"Charcoal Typhoon",
				"Chromium",
				"G1006",
				"Red Dev 10",
				"Red Scylla"
			],
			"source_name": "ETDA:Earth Lusca",
			"tools": [
				"Agentemis",
				"AntSword",
				"BIOPASS",
				"BIOPASS RAT",
				"BadPotato",
				"Behinder",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"Doraemon",
				"FRP",
				"Fast Reverse Proxy",
				"FunnySwitch",
				"HUC Port Banner Scanner",
				"KTLVdoor",
				"Mimikatz",
				"NBTscan",
				"POISONPLUG.SHADOW",
				"PipeMon",
				"RbDoor",
				"RibDoor",
				"RouterGod",
				"SAMRID",
				"ShadowPad Winnti",
				"SprySOCKS",
				"WinRAR",
				"Winnti",
				"XShellGhost",
				"cobeacon",
				"fscan",
				"lcx",
				"nbtscan"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "d53593c3-2819-4af3-bf16-0c39edc64920",
			"created_at": "2022-10-27T08:27:13.212301Z",
			"updated_at": "2026-04-10T02:00:05.272802Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"Earth Lusca",
				"TAG-22",
				"Charcoal Typhoon",
				"CHROMIUM",
				"ControlX"
			],
			"source_name": "MITRE:Earth Lusca",
			"tools": [
				"Mimikatz",
				"PowerSploit",
				"Tasklist",
				"certutil",
				"Cobalt Strike",
				"Winnti for Linux",
				"Nltest",
				"NBTscan",
				"ShadowPad"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434290,
	"ts_updated_at": 1775792208,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/efe8996bf4dc5abfc3adef0dee72767efe9d11c1.pdf",
		"text": "https://archive.orkl.eu/efe8996bf4dc5abfc3adef0dee72767efe9d11c1.txt",
		"img": "https://archive.orkl.eu/efe8996bf4dc5abfc3adef0dee72767efe9d11c1.jpg"
	}
}