{
	"id": "215c108f-0e67-49de-885c-fbaeae2d90e6",
	"created_at": "2026-04-06T00:09:59.202519Z",
	"updated_at": "2026-04-10T03:21:53.307434Z",
	"deleted_at": null,
	"sha1_hash": "94ff6207e7137bb5f107f10c36106068ad01ff51",
	"title": "Analyzing Modern Malware Techniques - Part 3",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 120562,
	"plain_text": "Analyzing Modern Malware Techniques - Part 3\r\nBy Danus\r\nPublished: 2020-02-03 · Archived: 2026-04-05 18:46:41 UTC\r\nAnalyzing Modern Malware Techniques - Part 3\r\nA case of Powershell, Excel 4 Macros and VB6(part 2 of 2)\r\nPreface:\r\nWhen I was watching The Cycle Of Cyber Threat Intelligence the other day I learned about the concept called\r\n“Biases” and how it interferes with researchers and cause them time delays and make big mistakes in general\r\nwhen it comes to research. In this part of the research I was no stranger to my own biases, I like to get my hands\r\ndirty, dig deep into binaries and understand EVERYTHING that goes under the hood. It’s simply my nature and\r\nmy curiosity that can get the better of me. As I was researching this sample, I insisted for the first few days to\r\nanalyze everything by myself, instead of using great tools that were in my disposal. I ended up spending A LOT of\r\ntime attempting to unpack the loader instead of using other tools in my arsenal that aided me further analyze the\r\nmalware itself including the heavily obfuscated loader, thus proving that I do as everyone else have my own biases\r\nand sometimes its better off to simply stop, reassess your goals and re attempt to understand the big picture. So\r\nhere we go - Part 3 hope you enjoy this one :slight_smile:\r\nBackground knowledge required:\r\n1. Knowledge in C and Assembly\r\n2. Knowledge in WINAPI\r\n3. Knowledge in IDA and x64dbg\r\n4. Novice experience with analyzing obfuscated and packed code\r\n5. Knowledge in PE Injection techniques(Process Hollowing especially for this one)\r\nTools used\r\n1. Any.Run\r\n2. IDA\r\n3. PEBear and PEID\r\n4. Resource Hacker\r\n5. Process Monitor\r\n6. Process Explorer\r\n7. x64dbg\r\nGoals:\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 1 of 18\n\n1. Unpack malware\r\n2. Understand covert launching\r\n3. Disable anti debugging and anti vm techniques(if there are any)\r\n4. Identify basic host based signatures\r\n5. Identify basic network based signatures\r\nBasic Static and Dynamic Analysis:\r\nSome side notes:\r\nThis malware performs process injection, the memory addresses you’ll see in my debugging pictures\r\nwill be different because I had to re-execute the malware several times and because of the dynamic\r\nnature of memory allocation, you’ll sometimes see different addresses being shown.\r\nUsing Hybrid Analysis I’ve collected some dry information about the activity of the sample:\r\nAnti debugging:\r\nProcess Injection:\r\nDropped artifacts:\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 2 of 18\n\nThen I decided to load IDA and x64dbg to analyze the malware, which caused a significant delay in my analysis, I\r\ndecided to stop and reassess the situation. The binary was so heavily obfuscated that It was getting real hard to\r\nimpossible to analyze it without the usage of external tools. I decided to use API Monitor to collect a list of APIs\r\nthe malware calls that could perhaps aid my debugging but the anti debugging techniques this malware deploys\r\ncan crash, stop and confuse any debugger I threw at it including API monitor. The malware would simply not\r\nexecute under any debugger attached. As a final resort I decided I’ll use process explorer and process monitor to\r\nunderstand what is going on exactly upon execution. Luckily for me - the malware did execute under a VM.\r\nProcess Monitor \u0026 Process Explorer:\r\nIt could be observed, under execution that first the sample would launch and begin to eat up CPU usage that\r\nindicates its unpacking, Then it would launch a sub process called RegAsm.exe, which is a known Microsoft\r\napplication for registering .NET assembly. Malware frequently uses this binary to inject code into, and indeed as\r\nmentioned before hybrid analysis detected that memory is being injected into this binary.\r\nThe malware launches RegAsm.exe and it seems to launch with the sample path in the command parameters.\r\nThen it can be observed that as soon as RegAsm.exe is launched, a conhost.exe(cmd.exe) is launched with strange\r\nparameters:\r\nAfter waiting for a while we can observe TCP network connections being made to remote addresses:\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 3 of 18\n\nIn addition we know that the malware drops a file into disk called “OOlqs” into the %appdata%/aljwSjH/\r\ndirectory, this file is created with hidden attributes. after executing the malware I examined the file and it seems to\r\nbe a copy of RegAsm specifically the version the malware is launching as the victim sub process (v2.0.50727).\r\nThey contain the exact SHA-256 checksum which leads me to believe that the malware will launch its own\r\ndropped RegAsm.exe variant incase the specific version of RegAsm.exe is not found on the computer.\r\nIn addition RegAsm.exe is attempting to query sensitive data files:\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 4 of 18\n\nFor the above example it is attempting to open Chrome and FireFox data files which strikes me as very suspicious.\r\nLater on I noticed the following:\r\nThese are sensitive data files for various browser and other applications(Yandex, Chrome, Comodo, Firefox), this\r\nbinary without a doubt is performing very suspicious activity.\r\nAdvanced Static and Dynamic Analysis:\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 5 of 18\n\nWe’ll have to find a way to dump the payload from memory. As I mentioned before, attaching to RegAsm.exe will\r\ncause it to crash, so this option is a no go. What we must do Is attach to the sample which I named infected.exe\r\n(just in case the malware deploys any tricks looking for SHA-256 checksum named processes or processes\r\nrunning containing the strings “sample”, “malware” etc).\r\nLooking at this malware strings or imports in IDA yields nothing, no imports and no strings. We go straight into\r\ndebugging.\r\nIn addition, to ease our analysis - lets install SycllaHide which will stop some of the anti debugging techniques\r\nthis sample employs(thanks @0x00dtm for the advice). Lets turn on all the options for anti-anti debugging as this\r\nwill aid us greatly in analyzing this sample.\r\nIn my previous article we loaded up the sample in IDA to find out its a VB6 file. I fixed it up with an IDC script\r\nbut it didn’t help much, So this time I simply decided to execute it in x64dbg and make an educated guess that if\r\nwe set a breakpoint on VirtualAlloc might lead us somewhere:\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 6 of 18\n\nThe breakpoint was hit about 7 times, but each time it was hit outside our main module, on the 8th try I viewed the\r\ncall stack and it seems to been executed from the main module this time:\r\nInteresting, I decided to view the contents of the newly allocated address:\r\nObviously it’s empty, how ever I wanted to check if it would fill up. To check we must add a hardware breakpoint\r\non the address 0x00250000 and make the debugger break if this memory region gets accessed. so let’s do just that:\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 7 of 18\n\nAnd ..\r\nbut alas, this is no PE file header, and we try to continue looking for more breaks on VirtualAlloc, and continue\r\nexecuting the application it will crash. But then, perhaps this code is a shellcode, that might get executed? Hmm,\r\nlets try to find this allocated section again by re executing the sample.\r\nSo again I found the allocated area this time it hit on 0x00240000. I decided to analyze the memory as code by\r\nviewing it in disassembly:\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 8 of 18\n\nAnd it looks like valid code, So I decided to place a breakpoint on it.\r\nbut it did not execute.. hmm, Probably because I set it as a memory breakpoint and this binary is riddled with anti\r\ndebugging traps, I decide to put a hardware on execution breakpoint on the allocated area and what do you know:\r\nWe break on the allocated shellcode!\r\nThe call stack indicates it was called from 0x0041B17F\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 9 of 18\n\nFirst thing I did was dump the shellcode using the Syclla and moved the memory dump into my Static Analysis\r\nmachine, this code is not executable but we can analyze it on IDA. Since each execution this shellcode will be\r\nallocated in different areas it will be a bit harder to analyze it but the last 4 bytes of the code addresses have the\r\nsame offset all the time so it’s still possible.\r\nUsually, when I hit this kind of code that I have no idea what it does so I decided to traverse around it to see if I\r\nfind anything interesting. the first artifact I find is located at offset 0x52AF from the begging of the allocated\r\ncode, a call to LoadLibraryA is performed at address offset 0x52B8 and then a Call to GetProcAddress is\r\nperformed inside sub_offset52E4 at offset 0x52FD:\r\nIDA View:\r\nx64dbg View:\r\nWe can see that various API’s are being resolved and this is not uncommon for this type of heavily obfuscated\r\nmalware, it is deploying what is called Dynamic API resolving which means all APIs will be resolved dynamically\r\nmaking the analysis much harder. As we Recall, I assumed that this malware will perform Process Hollowing on\r\nRegAsm.exe and the dry analysis we performed using Hybrid-Analysis actually gave us more prove that this in\r\nfact MIGHT be correct. Since we found the API resolving method for this malware, we can set up a breakpoint on\r\nfunc_LoadLibraryCall(at offset 0x52AF) for this function and see if any API’s that are related to process\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 10 of 18\n\nhollowing or code injection will be met. I have reason to suspect this is might actually work because if we check\r\nthe references for func_LoadLibraryCall we can see its being called a lot during execution.\r\nSo let’s be on the lookout for:\r\nVirtualAllocEx\r\nGetFileSize\r\nCreateProcess\r\nNtGetContextThread\r\nNtReadVirtualMemory\r\nNtWriteVirtualMemory\r\nNtResumeThread\r\nNtUnmapViewOfSection\r\nNtProtectVirtualMemory\r\nA list of APIs I’ve encountered in the API resolving routine:\r\nTerminateProcess\r\nEnumWindows\r\nNtProtectVirtualMemory\r\nDbgBreakPoint\r\nDbgUiRemoteBreakin\r\nNtSetInformationThread\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 11 of 18\n\nNtAllocateVirtualMemory\r\nNtGetContextThread\r\nNtSetContextThread\r\nNtWriteVirtualMemory\r\nNtCreateSection\r\nNtMapViewOfSection\r\nNtOpenFile\r\nNtClose\r\nNtResumeThread\r\nCreateProcessInternalW\r\nGetLongPathNameW\r\nSleep\r\nCreateThread\r\nWaitForSingleObject\r\nTerminateThread\r\nAddVectoredExceptionHandler\r\nCreateFileW\r\nWriteFile\r\nCloseHandle\r\nGetFileSize\r\nReadFile\r\nShellExecuteW\r\nSHCreateDirectoryExW\r\nRegCreateKeyExA\r\nRegSetValueExA\r\nAs expected I’ve extracted APIs that might indicated process hollowing.\r\nI’ve noticed two interesting things about this sample regarding the API resolving, One is that each run these\r\nstrings are loaded from the exact sample location 0x44XX - 0x4XXX, this means that we dump this memory\r\nsection again and look at the strings in their decrypted form! also I think the author made a mistake because if\r\nwe’ll view the strings through IDA we can see that he didn’t encrypt all of them:\r\nAnyway, on with the analysis, we can actually notice that during this API resolving the malware already spawned\r\nRegAsm.exe as a child process and we finishing looping around the API resolving function the malware\r\nterminates itself and we can see RegAsm.exe begins to execute independently.\r\nWe must restart the program but this time we need to choose the correct APIs to break on, If we break on these\r\nAPIs using memory breakpoints the malware will detect this and force the debugger to stop execution on a\r\ndebugger trap so we must perform this using hardware breakpoints.\r\nWe can only set 4 at a time, So let’s choose the following APIs:\r\n1. CreateProcessInternalW\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 12 of 18\n\n2. ZwWriteVirtualMemory\r\n3. NtResumeThread\r\n4. ShellExecuteW\r\nAfter the APIs are resolved we break at CreateProcessInternalW:\r\nWe can view the parameters being passed to the function, and unfortunately this API is not documented AT ALL.\r\nbut we can kinda make sense from whats going by looking at CreateProcessA which calls\r\nCreateProcessInternalW.\r\nBOOL CreateProcessA(\r\nLPCSTR lpApplicationName = RegAsm.exe\r\nLPSTR lpCommandLine = Our sample\r\nLPSECURITY_ATTRIBUTES lpProcessAttributes,\r\nLPSECURITY_ATTRIBUTES lpThreadAttributes,\r\nBOOL bInheritHandles,\r\nDWORD dwCreationFlags = CREATE_SUSPENDED(0x00000004)\r\nLPVOID lpEnvironment,\r\nLPCSTR lpCurrentDirectory,\r\nLPSTARTUPINFOA lpStartupInfo,\r\nLPPROCESS_INFORMATION lpProcessInformation\r\n);\r\nThis is our first indication of process injection. First the malware spawns RegAsm as a suspended process which\r\ncan be viewed in process explorer:\r\nLet’s continue.\r\nThen we break on ZwWriteVirtualMemory:\r\nThe undocumented Internals website states that:\r\n“NtWriteVirtualMemory is similar to WINAPI WriteProcessMemory. See Ms SDK for detailed\r\ndescription of parameters.”\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 13 of 18\n\nSide note, In userland calls to Nt prefix and Zw prefix dont matter they are both the same, I assume\r\nmalware utilizes these calls to avoid AV detection since these APIs might not be monitored.\r\nSo let’s look at that:\r\nBOOL WriteProcessMemory(\r\nHANDLE hProcess,\r\nLPVOID lpBaseAddress,\r\nLPCVOID lpBuffer,\r\nSIZE_T nSize,\r\nSIZE_T *lpNumberOfBytesWritten\r\n);\r\nhProcess holds the handle to the process we want to write, 0x100 corresponds to the RegAsm.exe Process, this\r\ncan be seen in the Process Explorer:\r\nwe’re writing 0x5DC bytes starting from address 0x005F7D00. I looked it up in the dump it doesn’t seem to\r\ncontain much of interest to us. so I’ll continue with execution.\r\nWe break on ZwWriteVirtualMemory again!:\r\nThis goes on 2 mores times until I hit something interesting:\r\nhuh.. it seems to inject the shellcode we are debugging right now straight into RegaAsm.exe, we can check this by\r\nviewing 0x4B0000 in disassembly view in x64dbg:\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 14 of 18\n\nNext API that is NtResumeThread that will probably cause the newly created thread in RegAsm.exe to execute\r\nand we don’t want to execute that because the malware will continue execution! Now what’s really cool here, is\r\nthat we can attach to RegAsm.exe and put a breakpoint on the shellcode and resume the new thread and break on\r\nthe malware again!\r\nNow I’ve attached to RegAsm.exe\r\nIf we got in the Threads tab in x64dbg We see a suspicious thread with EIP 0xD0000(Will be different on your\r\nmachine) but the and it seems to be marked as the main thread, this is highly suspicious behavior. let’s go into that\r\nthread and place a breakpoint at its start address and simply resume it.\r\nAnd we hit it our breakpoint!\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 15 of 18\n\nIn the case of this malware, it was not a classic process hollowing attack but an interesting case of code Injection,\r\nbecause in classic case of process hollowing, the attacker must unmap the original PE out of the process and thus\r\nhollow the process and then remap his own PE into the process. In this case it seems that the malware maps just its\r\ncode into the memory of the other process and sets the main thread to execute on this newly allocated code. This\r\nmethod is easier to execute but more detectable, as it would seem that new shellcode is being run from a\r\nsuspicious area in the code that does not match the original entry point of the image located in the Optional\r\nHeader field. In addition the malware author did not bother masking the injection and we can see that the\r\nexecuting code is going to be executing in memory which is in READ, WRITE and EXECUTE privileges:\r\nThis is highly suspicious.\r\nNext Let’s put a breakpoint on our API resolve routine at offset 0x52B8 and see what new API’s are going to be\r\ncalled in this new executing code.\r\nTerminateProcess\r\nEnumWindows\r\nNtProtectVirtualMemory\r\nDbgBreakPoint\r\nDbgUiRemoteBreakin\r\nNtSetInformationThread\r\nNtAllocateVirtualMemory\r\nNtGetContextThread\r\nNtSetContextThread\r\nNtWriteVirtualMemory\r\nNtCreateSection\r\nNtMapViewOfSection\r\nNtOpenFile\r\nNtClose\r\nNtResumeThread\r\nCreateProcessInternalW\r\nGetLongPathNameW\r\nSleep\r\nCreateThread\r\nWaitForSingleObject\r\nTerminateThread\r\nAddVectoredExceptionHandler\r\nCreateFileW\r\nWriteFile\r\nCloseHandle\r\nGetFileSize\r\nReadFile\r\nShellExecuteW\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 16 of 18\n\nSHCreateDirectoryExW\r\nRegCreateKeyExA\r\nRegSetValueExA\r\nInternetOpenA\r\nInternetSetOptionA\r\nInternetOpenUrlA\r\nInternetReadFile\r\nInternetCloseHandleA\r\nOne can notice that this time, the code resolved 5 more APIs! these are the internet APIs.\r\nNow after we resolved the APIs and probably decrypted the payload we can do two things, One is collect all the\r\nAPI’s we find of value that can contribute to our understanding of this malware and dump the decrypted form of\r\nthe malware as we can we can extract some strings out of it which can be done at your own machine because as\r\nwe saw the strings are always located at offset 0xXXXX44XX and can viewed in the IDA string view here is an\r\nexample:\r\n)\r\n602x79\r\nThese decrypted strings can aid greatly in understanding this malware more in depth. The strings marked in red\r\nindicate that the malware might be downloading more artifacts off the internet and might be attempting to hide\r\nitself in traffic using legitimate looking network strings.\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 17 of 18\n\nWow, Alright! we gathered a lot of information, and we might get lost if we don’t summarize our findings and\r\nunderstand what is our current status so let’s stop for a second and reassess.\r\nWhere should I continue from here?\r\nWe’ve covered a lot here and this article is getting really long. There is so much to go from here -\r\nWe’ve managed to unpack the malware first stage loader and the payload\r\nWe have a list of APIs that can aid us explore the loader and the payload\r\nWe understood the malwares stealth injection technique\r\nWe managed to load the payload into memory and gain control over it\r\nWe got a lot of artifacts and IOC’s that can aid us greatly in deeply analyzing this piece of malware.\r\nThis was no easy task, we had to defeat a packer and really tough obfuscation techniques. When I began writing\r\nthis post only 12 AV engines managed to detect this file as malicious so let’s give us a tap on the back.\r\nSee you guys next time!\r\nSources:\r\nSample used(SHA - 256) -\r\n6ffb945247085ceb6b2478c643dc337a35d5c0c17d2e4709c3a5842c9bcb3e3/5e25c5f7a2b4a8790d7d1bbf\r\nHow To Defeat Anti-VM and Anti-Debug Packers With IDA Pro\r\nSource: https://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nhttps://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://0x00sec.org/t/analyzing-modern-malware-techniques-part-3/18943"
	],
	"report_names": [
		"18943"
	],
	"threat_actors": [],
	"ts_created_at": 1775434199,
	"ts_updated_at": 1775791313,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/94ff6207e7137bb5f107f10c36106068ad01ff51.pdf",
		"text": "https://archive.orkl.eu/94ff6207e7137bb5f107f10c36106068ad01ff51.txt",
		"img": "https://archive.orkl.eu/94ff6207e7137bb5f107f10c36106068ad01ff51.jpg"
	}
}