{
	"id": "085d2902-3020-4389-ae69-f2199bdfbefe",
	"created_at": "2026-04-06T00:19:34.217359Z",
	"updated_at": "2026-04-10T03:24:23.98411Z",
	"deleted_at": null,
	"sha1_hash": "30e7dbb6ac8ad7bd0b1ee2da0ff6e4e4b4cc5250",
	"title": "Blowing Cobalt Strike Out of the Water With Memory Analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1309374,
	"plain_text": "Blowing Cobalt Strike Out of the Water With Memory Analysis\r\nBy Dominik Reichel, Esmid Idrizovic, Bob Jung\r\nPublished: 2022-12-02 · Archived: 2026-04-05 14:28:20 UTC\r\nExecutive Summary\r\nUnit 42 researchers examine several malware samples that incorporate Cobalt Strike components, and discuss\r\nsome of the ways that we catch these samples by analyzing artifacts from the deltas in process memory at key\r\npoints of execution. We will also discuss the evasion tactics used by these threats, and other issues that make their\r\nanalysis problematic.\r\nCobalt Strike is a clear example of the type of evasive malware that has been a thorn in the side of detection\r\nengines for many years. It is one of the most well-known adversary simulation frameworks for red team\r\noperations. However, it’s not only popular among red teams, but it is also abused by many threat actors for\r\nmalicious purposes.\r\nAlthough the toolkit is only sold to trusted entities to conduct realistic security tests, due to source code leaks, its\r\nvarious components have inevitably found their way into the arsenal of malicious actors ranging from ransomware\r\ngroups to state actors. Malware authors abusing Cobalt Strike even played a role in the infamous SolarWinds\r\nincident in 2020.\r\nOverview of Cobalt Strike\r\nThe main driver for the proliferation of Cobalt Strike is that it is very good at what it does. It was designed from\r\nthe ground up to help red teams armor their payloads to stay ahead of security vendors, and it regularly introduces\r\nnew evasion techniques to try to maintain this edge.\r\nOne of the main advantages of Cobalt Strike is that it mainly operates in memory once the initial loader is\r\nexecuted. This situation poses a problem for detection when the payload is statically armored, exists only in\r\nmemory and refuses to execute. This is a challenge to many security software products, as scanning memory is\r\nanything but easy.\r\nIn many cases, Cobalt Strike is a natural choice for gaining an initial footprint in a targeted network. A threat actor\r\ncan use a builder with numerous deployment and obfuscation options to create the final payload based on a\r\ncustomizable template.\r\nThis payload is typically embedded into a file loader in encrypted or encoded form. When the file loader is\r\nexecuted by a victim, it decrypts/decodes the payload into memory and runs it. As the payload is present in\r\nmemory in its original form, it can be detected easily due to some specific characteristics.\r\nAs malware researchers, we often see potentially interesting malicious samples that turn out to just be loaders for\r\nCobalt Strike. It’s also often unclear if a loader was created by a red team or a real malicious actor, thus making\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 1 of 18\n\nattribution even more challenging.\r\nIn the next few sections, we’re going to take a closer look into three different Cobalt Strike loaders that were\r\ndetected out of the box by a new hypervisor based sandbox we designed to allow us to analyze artifacts in\r\nmemory. Each sample loads a different implant type, namely an SMB, HTTPS and stager beacon. We dubbed\r\nthese Cobalt Strike loaders KoboldLoader, MagnetLoader and LithiumLoader. We will also discuss some of the\r\nmethods we can use to detect these payloads.\r\nKoboldLoader SMB Beacon\r\nThe sample we’re looking at was detected during a customer incident.\r\nSHA256: 7ccf0bbd0350e7dbe91706279d1a7704fe72dcec74257d4dc35852fcc65ba292\r\nThis 64-bit KoboldLoader executable uses various known tricks to try to bypass sandboxes and to make the\r\nanalysis process more time consuming.\r\nTo bypass sandboxes that hook only high-level user mode functions, it solely calls native API functions. To make\r\nthe analyst's life harder, it dynamically resolves the functions by hash instead of using plain text strings. The\r\nmalware contains code to call the following functions:\r\nNtCreateSection\r\nNtMapViewOfSection\r\nNtCreateFile (unused)\r\nNtAllocateVirtualMemory (unused)\r\nRtlCreateProcessParameters\r\nRtlCreateUserProcess\r\nRtlCreateUserThread\r\nRtlExitUserProcess\r\nThe malware creates two separate tables of function hash/address pairs. One table contains one pair for all native\r\nfunctions, while the second table only pairs for Nt* functions.\r\nFor the Rtl* functions that were used, it loops through the first table and searches for the function hash to get the\r\nfunction address. For the Nt* functions that were used, it loops through the second table and simultaneously\r\nincreases a counter variable.\r\nWhen the hash is found, it takes the counter value that is the system call number of the corresponding native\r\nfunction, and it enters a custom syscall stub. This effectively bypasses many sandboxes, even if the lower level\r\nnative functions are hooked instead of the high-level ones.\r\nThe overall loader functionality is relatively simple and uses mapping injection to run the payload. It spawns a\r\nchild process of the Windows tool sethc.exe, creates a new section and maps the decrypted Cobalt Strike beacon\r\nloader into it. The final execution of the Cobalt Strike loader that in turn loads an SMB beacon happens by calling\r\nRtlCreateUserThread.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 2 of 18\n\nYou can find the decrypted beacon configuration data in the Appendix section.\r\nIn-Memory Evasion\r\nWith our new hypervisor-based sandbox, we were able to detect the decrypted Cobalt Strike SMB beacon in\r\nmemory. This beacon loader even uses some in-memory evasion features that create a strange sort of chimeric file.\r\nWhile it’s actually a DLL, the “MZ'' magic PE bytes and subsequent DOS header are overwritten with a small\r\nloader shellcode as shown in Figure 1.\r\nFigure 1. Disassembled Cobalt Strike beacon loader shellcode.\r\nThe shellcode loader jumps to the exported function DllCanUnloadNow, which prepares the SMB beacon module\r\nin memory. To do this, it first loads the Windows pla.dll library and zeroes out a chunk of bytes inside its code\r\nsection (.text). It then writes the beacon file into this blob and fixes the import address table, thus creating an\r\nexecutable memory module.\r\nDuring the analysis of the file, we could figure out some of the in-memory evasion features that were used, as\r\nshown in Table 1.\r\nEvasion\r\nfeature\r\nDescription\r\nUsed in\r\nour sample\r\nallocator\r\nSet how beacon's ReflectiveLoader allocates memory for the agent.\r\nOptions are: HeapAlloc, MapViewOfFile and VirtualAlloc.\r\nNo\r\ncleanup\r\nAsk beacon to attempt to free memory associated with the reflective DLL\r\npackage that initialized it.\r\nYes\r\nmagic_mz_x64\r\nOverride the first bytes (MZ header included) of beacon's reflective DLL.\r\nValid x86 instructions are required. Follow instructions that change CPU\r\nstate with instructions that undo the change.\r\nYes\r\nmagic_pe\r\nOverride the PE character marker used by beacon's ReflectiveLoader with\r\nanother value.\r\nNo\r\nmodule_x64\r\nAsk the x86 reflective loader to load the specified library and overwrite its\r\nspace instead of allocating memory with VirtualAlloc.\r\nYes\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 3 of 18\n\nobfuscate\r\nObfuscate the reflective DLL’s import table, overwrite unused header\r\ncontent, and ask ReflectiveLoader to copy beacon to new memory without\r\nits DLL headers.\r\nYes\r\nsleep_mask Obfuscate beacon and its heap, in-memory, prior to sleeping. No\r\nsmartinject\r\nUse embedded function pointer hints to bootstrap beacon agent without\r\nwalking kernel32 Export Address Table (EAT).\r\nNo\r\nstomppe\r\nAsk ReflectiveLoader to stomp MZ, PE and e_lfanew values after it loads\r\nbeacon payload.\r\nNo\r\nuserwx\r\nAsk ReflectiveLoader to use or avoid read, write or execute (RWX)\r\npermissions for Beacon DLL in memory.\r\nNo\r\nTable 1. Cobalt Strike evasion techniques that were used.\r\nTo sum up, the beacon loader and the beacon itself are the same file. Parts of the PE header are used for a\r\nshellcode that jumps to an exported function, which in turn creates a module of itself inside a Windows DLL.\r\nFinally, the shellcode jumps to the entry point of the beacon module to execute it in memory.\r\nAs discussed, there is no way for us to detect this beacon of our KoboldLoader sample successfully unless we can\r\npeer inside memory during execution.\r\nMagnetLoader\r\nThe second loader we will look into is a 64-bit DLL that imitates a legitimate library.\r\nSHA256: 6c328aa7e0903702358de31a388026652e82920109e7d34bb25acdc88f07a5e0\r\nThis MagnetLoader sample tries to look like the Windows file mscms.dll in a few ways, by using the following\r\nsimilar features:\r\nThe same file description\r\nAn export table with many of the same function names\r\nAlmost identical resources\r\nA very similar mutex\r\nThese features are also shown in Figure 2, where the malware file is contrasted with the valid mscml.dll.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 4 of 18\n\nFigure 2. Comparison of file description, export table and resources of MagnetLoader (left) and\r\nmscml.dll (right) as seen with EXE Explorer.\r\nMagnetLoader not only tries to mimic the legitimate Windows library statically, but also at runtime.\r\nAll of the exported functions of MagnetLoader internally call the same main malware routine. When one of them\r\nis called, the DLL entry point is run first. In the entry point, the malware loads the original mscms.dll and it\r\nresolves all the functions it fakes.\r\nThe addresses of these original functions are stored and called after a fake method is executed. Thus, whenever an\r\nexported function of MagnetLoader is called, it runs the main malware routine and afterward calls the original\r\nfunction in mscms.dll.\r\nThe main malware routine is relatively simple. It first creates a mutex named SM0:220:304:WilStaging_02_p1h\r\nthat looks very similar to the original one created by mscms.dll.\r\nThe Cobalt Strike beacon loader gets decrypted into a memory buffer and executed with the help of a known trick.\r\nInstead of calling the beacon loader directly, the loader uses the Windows API function EnumChildWindows to\r\nrun it.\r\nThis function contains three parameters, one of which is a callback function. This parameter can be abused by\r\nmalware to indirectly call an address via the callback function and thus conceal the execution flow.\r\nYou can also find the decrypted beacon configuration data in the Appendix section.\r\nLithiumLoader\r\nThis last Cobalt Strike sample is part of a DLL side-loading chain where a custom installer for a type of security\r\nsoftware was used. DLL side-loading is a technique that hijacks a legitimate application to run a separate,\r\nmalicious DLL.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 5 of 18\n\nSHA256: 8129bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f\r\nThis 32-bit LithiumLoader DLL is part of a custom attacker-created Fortinet VPN installation package submitted\r\nto VirusTotal as FortiClientVPN_windows.exe (SHA256:\r\na1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786).\r\nThe FortiVPN.exe file is not malicious or compromised. Because the file is signed, attackers used it to evade\r\nantivirus detection.\r\nThe installer is a self-extracting RAR archive that contains the following files:\r\nFile name Description\r\nFortiVPN.exe Legit signed FortiClient VPN Online installer v7.0.1.83\r\nGUP.exe Legit signed WinGup for Notepad++ tool v5.2.1.0\r\ngup.xml WinGup config file\r\nlibcurl.dll LithiumLoader\r\nTable 2a. FortiClientVPN_windows.exe file contents.\r\nThe self-extracting script commands are as follows:\r\nTable 2b. List of self-extracting script commands.\r\nWhen the installer is run, all files get silently dropped to the local %AppData% folder and both executable files\r\nget started. While the FortiClient VPN installer executes, the WinGup tool side-loads the libcurl.dll\r\nLithiumLoader malware. The malware does so because it imports the following functions from a legit copy of the\r\nlibcurl library as shown in Figure 3.:\r\nFigure 3. Import address table of WinGup.exe.\r\nThis threat also tries to add the %AppData% folder path to the exclusion list in Windows Defender via\r\nPowerShell.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 6 of 18\n\nOn the startup of GUP.exe, the malicious libcurl.dll file is loaded into the process space as it statically imports the\r\nfunctions shown in Figure 3, above. While all four libcurl functions are run, only curl_easy_cleanup contains a\r\nmalicious routine that was injected while compiling a new version of the library. Thus, we’re not dealing with a\r\npatched version of the legitimate DLL. This is a cleaner solution that doesn’t break the code after the inserted\r\nmalicious routine, as is often seen in other malware.\r\nThis curl_easy_cleanup function usually contains only one subroutine (Curl_close) and has no return value (as\r\nshown in its source code on GitHub). The altered function is as shown in Figure 4.\r\nFigure 4. Modified curl_easy_cleanup export function of libcurl.dll.\r\nThe load_shellcode function decrypts the shellcode via XOR and key 0xA as shown in Figure 5.\r\nFigure 5. Shellcode loader function load_shellcode().\r\nThis function runs the Cobalt Strike stager shellcode indirectly via EnumSystemGeoID instead of directly\r\njumping to it. This Windows API function has three parameters, the last one of which is a callback function\r\nabused by LithiumLoader.\r\nThe Cobalt Strike stager shellcode is borrowed from Metasploit and is the reverse HTTP shell payload, which uses\r\nthe following API functions:\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 7 of 18\n\nLoadLibrary\r\nInternetOpenA\r\nInternetConnectA\r\nHttpOpenRequestA\r\nInternetSetOptionA\r\nHttpSendRequestA\r\nGetDesktopWindow\r\nInternetErrorDlg\r\nVirtualAllocStub\r\nInternetReadFile\r\nThe shellcode connects to the IP address of a university in Thailand.\r\nLithiumLoader Detection Issues\r\nAt the time of writing this analysis, the Cobalt Strike beacon payload was no longer available. Without a payload\r\nor any actionable information in the execution report of API calls, it’s often challenging for a sandbox to\r\ndetermine whether the sample is malicious. This sample doesn’t have any functionality that can be classified as\r\nmalicious per se.\r\nCatching Cobalt Strike Through Analyzing Its Memory\r\nIn all three of these examples there are some common detection challenges. These samples do not execute in\r\nnormal sandbox environments. But as we discussed, there is a wealth of information that we can use for detection\r\nif we look inside memory during execution, like function pointers, decoded stages of the loader, and other\r\nartifacts.\r\nFor many years now, it has been standard practice for sandbox systems to instrument and observe the activity of\r\nexecuting programs. If our team has learned anything over the years, it’s that this alone is not enough for highly\r\nevasive malware. This is why we’ve been working hard the past few years on figuring out how we can add more\r\nthorough processing for this type of highly evasive malware.\r\nFor accurate detection, one of the key features we’ve found to address highly evasive malware is that we need to\r\nlook at memory as samples execute in addition to using the system API to get a better understanding of what’s\r\nhappening.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 8 of 18\n\nFigure 6. High level Advanced WildFire detection strategy.\r\nWe’ve found that, in malware detection, it’s useful to look at the deltas in memory at key points of execution to\r\nextract meaningful information and artifacts. As our system processes a vast number of samples, there have been a\r\nlot of challenges to make this work at scale. However, a lot of clever engineering built on top of our flagship\r\ncustom hypervisor tailored for malware analysis has helped make this idea a reality.\r\nIn these next few sections, we will detail some of the main types of data that we are currently collecting from\r\nmemory to aid detection. This data can be utilized by both our analysts for manual signatures as well as machine\r\nlearning pipelines, which we’ll be discussing in a future post.\r\nAlthough we are focusing on memory here, we are by no means suggesting that instrumenting and logging API\r\ncalls are not useful for detection. Our belief is that bringing execution logs and memory analysis data together\r\ncreates a sum greater than its parts.\r\nAutomatic Payload Extraction\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 9 of 18\n\nAs previously discussed, it is increasingly common for malware authors to obfuscate their initial payloads. While\r\nusing executable packers that can compress and obfuscate files to accomplish this is nothing new, it becomes\r\nproblematic when it’s used in combination with evasion strategies, because there is no static or dynamic data\r\nthat’s useful for an accurate detection.\r\nThere are infinite combinations of strategies for encoding, compressing, encrypting or downloading additional\r\nstages for execution. The ability to craft signatures for these payloads is obviously an important way that our\r\nanalysts can catch lots of different malware components from frameworks like Cobalt Strike. If we can catch them\r\nin memory, it ultimately doesn’t matter if the malware decides not to execute.\r\nThe following simplified diagram in Figure 7 shows an example of what we might see in a couple of stages that\r\nwere never present in the initial executable file.\r\nFigure 7. Typical stages we might see in a packed malware executable.\r\nOn the left side of the diagram, we see an example of a shellcode stage. Although the term “shellcode” was\r\noriginally coined for hand crafted assembly utilized in exploits to pop a shell on a target system, the word has\r\nevolved to encompass any blobs of custom assembly written for nefarious purposes. Some malware stages are\r\nblobs of custom assembly with no discernable executable structure. A common pattern for malware authors taking\r\nthis approach is to dynamically resolve all of the function pointers into a table for ease of access.\r\nOn the right side of the diagram, we see that the later stage is an example of a well-formed executable. Some\r\nmalware stages or payloads are well-formed executables. These can be loaded by the OS via the system API, or\r\nthe malware author might use their own PE loader if they’re trying to be stealthy in avoiding calling any APIs to\r\ndo this for them.\r\nFunction Pointer Data\r\nAnother rich set of data we can pull from memory that we’ve begun to use for detection is dynamically resolved\r\nfunction pointers, as shown in Figure 8. Malware authors learned long ago that if they explicitly call out all of the\r\nWINAPI functions they plan to use in the import table, it can be used against them. It is now standard practice to\r\nhide the functions that will be used by the malware or any of its stages.\r\nShellcode hashing is another common stealthy strategy used to resolve pointers for functions without needing their\r\nstring.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 10 of 18\n\nFigure 8. Examples of dynamically resolved WINAPI pointers we might see in a memory segment.\r\nIn Advanced WildFire we have begun to selectively search for and use this information about which WINAPI\r\nfunction pointers were resolved in our detection logic.\r\nOS Structure Modifications\r\nAnother useful source of detection data we’ve found from analyzing memory is to look for any changes to\r\nWindows bookkeeping structures (Malware authors love to mess with these!). These structures are important for\r\nthe OS to maintain state about the process, such as what libraries have been loaded, where the executable image\r\nwas loaded, and various other characteristics about the process that the OS might need to know later. Given that\r\nmany of these fields should never be modified, it’s often useful to keep track of when and how malware samples\r\nare manipulating them.\r\nThe diagram in Figure 9 shows how a sample might unhook a module it loaded from the LDR Module list.\r\nUnhooking a module would mean that there is no longer a record that the module exists. So, for example, after\r\ndoing this the Task Manager in Windows would no longer list it.\r\nThis diagram represents only one of many different OS Structure modifications we’ve seen, but it shows that there\r\nare many different types of OS structure modifications that are useful for the malware detection problem.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 11 of 18\n\nFigure 9. An example of how a module might be unhooked from the LDR Modules List.\r\nPage Permissions\r\nFinally, another useful source of detection data is a full log of all changes made to page permissions. Authors of\r\npacked malware often need to change memory permissions in order to properly load and execute further stages.\r\nUnderstanding which pages of memory had their permissions changed often provides important insights into\r\nwhere code was loaded and executed, which can be useful for detection.\r\nConclusion\r\nAlthough Cobalt Strike has been around for some years, detecting it is still a challenge to many security software\r\nproviders. That is because this tool works mostly in memory and doesn’t touch the disk much, other than with the\r\ninitial loader.\r\nWe’ve looked into three new loaders and showed how they can be detected using a variety of techniques. These\r\ndetection techniques are available within our new hypervisor based sandbox.\r\nFigure 10 illustrates our detection reasons for KoboldLoader.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 12 of 18\n\nFigure 10. Internal KoboldLoader sample analysis report.\r\nPalo Alto Networks customers receive protections from these threats:\r\nAdvanced WildFire identifies the Cobalt Strike loaders and beacons as malicious.\r\nCortex XDR protects endpoints and identifies the loaders as malicious.\r\nIndicators of Compromise\r\nKoboldLoader\r\n7ccf0bbd0350e7dbe91706279d1a7704fe72dcec74257d4dc35852fcc65ba292\r\n6ffedd98d36f7c16cdab51866093960fe387fe6fd47e4e3848e721fd42e11221\r\nfc4b842b4f6a87df3292e8634eefc935657edf78021b79f9763548c74a4d62b8\r\n062aad51906b7b9f6e8f38feea00ee319de0a542a3902840a7d1ded459b28b8d\r\na221c7f70652f4cc2c76c2f475f40e9384a749acd1f0dbaefd1a0c5eb95598d2\r\nMagnetLoader\r\n6c328aa7e0903702358de31a388026652e82920109e7d34bb25acdc88f07a5e0\r\nLithiumLoader\r\n8129bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f\r\n82dcf67dc5d3960f94c203d4f62a37af7066be6a4851ec2b07528d5f0230a355\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 13 of 18\n\nLithiumLoader Installer\r\na1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786\r\ncbaf79fb116bf2e529dd35cf1d396aa44cb6fcfa6d8082356f7d384594155596\r\nAppendix\r\nKoboldLoader beacon configuration data:\r\nBeaconType - SMB\r\nPort - 4444\r\nSleepTime - 10000\r\nMaxGetSize - 1048576\r\nJitter - 0\r\nMaxDNS - 0\r\nPublicKey_MD5 - 633dc5c9b3e859b56af5edf71a178590\r\nC2Server -\r\nUserAgent -\r\nHttpPostUri -\r\nMalleable_C2_Instructions - Empty\r\nPipeName - \\\\.\\pipe\\servicepipe.zo9keez4weechei8johR.0521cc13\r\nDNS_Idle - Not Found\r\nDNS_Sleep - Not Found\r\nSSH_Host - Not Found\r\nSSH_Port - Not Found\r\nSSH_Username - Not Found\r\nSSH_Password_Plaintext - Not Found\r\nSSH_Password_Pubkey - Not Found\r\nSSH_Banner - Not Found\r\nHttpGet_Verb - Not Found\r\nHttpPost_Verb - Not Found\r\nHttpPostChunk - Not Found\r\nSpawnto_x86 - %windir%\\syswow64\\dfrgui.exe\r\nSpawnto_x64 - %windir%\\sysnative\\dfrgui.exe\r\nCryptoScheme - 0\r\nProxy_Config - Not Found\r\nProxy_User - Not Found\r\nProxy_Password - Not Found\r\nProxy_Behavior - Not Found\r\nWatermark_Hash - Not Found\r\nWatermark - 666\r\nbStageCleanup - True\r\nbCFGCaution - True\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 14 of 18\n\nKillDate - 0\r\nbProcInject_StartRWX - True\r\nbProcInject_UseRWX - False\r\nbProcInject_MinAllocSize - 35485\r\nProcInject_PrependAppend_x86 - b'\\x90\\x90\\x90\\x90\\x90\\x90\\x90'\r\nb'\\x90\\x90\\x90\\x90\\x90\\x90\\x90'\r\nProcInject_PrependAppend_x64 - b'\\x90\\x90\\x90\\x90\\x90\\x90\\x90'\r\nb'\\x90\\x90\\x90\\x90\\x90\\x90\\x90'\r\nProcInject_Execute - ntdll.dll:RtlUserThreadStart\r\nNtQueueApcThread\r\nNtQueueApcThread-s\r\nSetThreadContext\r\nRtlCreateUserThread\r\nkernel32.dll:LoadLibraryA\r\nProcInject_AllocationMethod - NtMapViewOfSection\r\nbUsesCookies - Not Found\r\nHostHeader - Not Found\r\nheadersToRemove - Not Found\r\nDNS_Beaconing - Not Found\r\nDNS_get_TypeA - Not Found\r\nDNS_get_TypeAAAA - Not Found\r\nDNS_get_TypeTXT - Not Found\r\nDNS_put_metadata - Not Found\r\nDNS_put_output - Not Found\r\nDNS_resolver - Not Found\r\nDNS_strategy - Not Found\r\nDNS_strategy_rotate_seconds - Not Found\r\nDNS_strategy_fail_x - Not Found\r\nDNS_strategy_fail_seconds - Not Found\r\nRetry_Max_Attempts - Not Found\r\nRetry_Increase_Attempts - Not Found\r\nRetry_Duration - Not Found\r\nMagnetLoader beacon configuration data:\r\nBeaconType - HTTPS\r\nPort - 443\r\nSleepTime - 3600000\r\nMaxGetSize - 1402498\r\nJitter - 70\r\nMaxDNS - Not Found\r\nPublicKey_MD5 - 965fe5c869f3eea5e211fa7ee12130d3\r\nC2Server - tileservice-weather.azureedge[.]net,/en-au/livetile/front/\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 15 of 18\n\nUserAgent - Microsoft-WebDAV-MiniRedir/10.0.19042\r\nHttpPostUri - /en-CA/livetile/preinstall\r\nMalleable_C2_Instructions - Remove 1380 bytes from the end\r\nRemove 3016 bytes from the beginning\r\nBase64 URL-safe decode\r\nHttpGet_Metadata - ConstHeaders\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\r\nCache-Control: max-age=0\r\nConnection: keep-alive\r\nHost: tileservice-weather.azureedge[.]net\r\nOrigin: https://tile-service-weather.azureedge[.]net\r\nReferer: https://tile-service.weather.microsoft[.]com/\r\nMetadata\r\nbase64url\r\nappend \"/45.40,72.73\"\r\nuri_append\r\nHttpPost_Metadata - ConstHeaders\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\r\nCache-Control: max-age=0\r\nConnection: keep-alive\r\nHost: tileservice-weather.azureedge[.]net\r\nOrigin: https://tile-service-weather.azureedge[.]net\r\nReferer: https://tile-service.weather.microsoft[.]com/\r\nConstParams\r\nregion=CA\r\nSessionId\r\nbase64url\r\nparameter \"appid\"\r\nOutput\r\nbase64\r\nprint\r\nPipeName - Not Found\r\nDNS_Idle - Not Found\r\nDNS_Sleep - Not Found\r\nSSH_Host - Not Found\r\nSSH_Port - Not Found\r\nSSH_Username - Not Found\r\nSSH_Password_Plaintext - Not Found\r\nSSH_Password_Pubkey - Not Found\r\nSSH_Banner -\r\nHttpGet_Verb - GET\r\nHttpPost_Verb - POST\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 16 of 18\n\nHttpPostChunk - 0\r\nSpawnto_x86 - %windir%\\syswow64\\conhost.exe\r\nSpawnto_x64 - %windir%\\sysnative\\conhost.exe\r\nCryptoScheme - 0\r\nProxy_Config - Not Found\r\nProxy_User - Not Found\r\nProxy_Password - Not Found\r\nProxy_Behavior - Use IE settings\r\nWatermark_Hash - Not Found\r\nWatermark - 1700806454\r\nbStageCleanup - True\r\nbCFGCaution - False\r\nKillDate - 0\r\nbProcInject_StartRWX - False\r\nbProcInject_UseRWX - False\r\nbProcInject_MinAllocSize - 17500\r\nProcInject_PrependAppend_x86 - b'\\x90\\x90'\r\nEmpty\r\nProcInject_PrependAppend_x64 - b'\\x90\\x90'\r\nEmpty\r\nProcInject_Execute - CreateThread\r\nSetThreadContext\r\nProcInject_AllocationMethod - NtMapViewOfSection\r\nbUsesCookies - False\r\nHostHeader -\r\nheadersToRemove - Not Found\r\nDNS_Beaconing - Not Found\r\nDNS_get_TypeA - Not Found\r\nDNS_get_TypeAAAA - Not Found\r\nDNS_get_TypeTXT - Not Found\r\nDNS_put_metadata - Not Found\r\nDNS_put_output - Not Found\r\nDNS_resolver - Not Found\r\nDNS_strategy - round-robin\r\nDNS_strategy_rotate_seconds - -1\r\nDNS_strategy_fail_x - -1\r\nDNS_strategy_fail_seconds - -1\r\nRetry_Max_Attempts - Not Found\r\nRetry_Increase_Attempts - Not Found\r\nRetry_Duration - Not Found\r\nTo decrypt the configuration data we used SentinelOne’s Cobalt Strike Parser.\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 17 of 18\n\nSource: https://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nhttps://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/cobalt-strike-memory-analysis/"
	],
	"report_names": [
		"cobalt-strike-memory-analysis"
	],
	"threat_actors": [
		{
			"id": "610a7295-3139-4f34-8cec-b3da40add480",
			"created_at": "2023-01-06T13:46:38.608142Z",
			"updated_at": "2026-04-10T02:00:03.03764Z",
			"deleted_at": null,
			"main_name": "Cobalt",
			"aliases": [
				"Cobalt Group",
				"Cobalt Gang",
				"GOLD KINGSWOOD",
				"COBALT SPIDER",
				"G0080",
				"Mule Libra"
			],
			"source_name": "MISPGALAXY:Cobalt",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434774,
	"ts_updated_at": 1775791463,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/30e7dbb6ac8ad7bd0b1ee2da0ff6e4e4b4cc5250.pdf",
		"text": "https://archive.orkl.eu/30e7dbb6ac8ad7bd0b1ee2da0ff6e4e4b4cc5250.txt",
		"img": "https://archive.orkl.eu/30e7dbb6ac8ad7bd0b1ee2da0ff6e4e4b4cc5250.jpg"
	}
}