{ "id": "bf11c8c5-9f93-4a6a-a379-9b877a8d76bd", "created_at": "2026-04-06T00:11:37.70898Z", "updated_at": "2026-04-10T13:12:18.285336Z", "deleted_at": null, "sha1_hash": "8a0d35c3569ccabf539172f02fe9aecf106a37e6", "title": "Extracting the Cobalt Strike Config from a TEARDROP Loader | Securehat", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 84911, "plain_text": "Extracting the Cobalt Strike Config from a TEARDROP Loader |\r\nSecurehat\r\nPublished: 2021-02-09 · Archived: 2026-04-05 17:10:56 UTC\r\n1. 🔬Malware Analysis\r\nExtracting the Cobalt Strike Config from a TEARDROP Loader\r\nThis blog post will cover how to use dynamic analysis to extract the underlying Cobalt Strike config from a recent\r\nTEARDROP sample\r\nDuring the analysis of the SolarWinds supply chain compromise in 2020, a second-stage payload was identified\r\nand dubbed TEARDROP. Analysis of the discovered samples showed that TEARDROP ultimately loaded a\r\nCobalt Strike beacon into memory. A good overview of the\r\nSolarWinds supply chain attack and follow on compromise activity can be found here:\r\nDespite wide discussion and coverage in security industry, actual samples of the TEARDROP malware were not\r\ninitially made publicly accessible. However on 05-02-2021, the two TEARDROP samples referenced in the\r\nSymantec blog above were uploaded to VirusTotal.\r\nFor the remainder of this blog post we will analyse one of the uploaded TEARDROP samples\r\n with the goal of extracting the underlying Cobalt Strike\r\nconfig.\r\nThis blog post is not an exhaustive analysis of the TEARDROP loader and its behaviour, it focuses purely on\r\nextracting the Cobalt Strike beacon and the associated config information.\r\nAnalysis of the TEARDROP Sample\r\nhttps://blog.securehat.co.uk/malware-analysis/extracting-the-cobalt-strike-config-from-a-teardrop-loader\r\nPage 1 of 6\n\nLoading the sample into PEStudio we can see that we're dealing with a 64bit DLL with a lot of DLL exports:\r\nThe high number of DLL exports makes it slightly more challenging to move onto dynamic analysis as we first\r\nneed to identify which export we want to analyse. To keep this blog post digestible, we will skip this step for now\r\nand instead we can use the information provided in the Symantec report (as linked above) to give us the correct\r\nDLL export for the starting point of our analysis: Tk_CreateImageType\r\nHow to Analyse a Specific DLL Export in x64dbg\r\nNow that we know we want to analyse the Tk_CreateImageType export, we need to get to that location in our\r\nfavourite debugging tool. This is a little more challenging to do with a DLL as we can't directly call the export\r\nusing x64dbg, but fortunately it's still easy enough to achieve with the following steps:\r\n1. Open rundll32.exe in x64dbg\r\n2. Configure x64dbg to automatically break on DLL entry\r\n3. Configure the rundll32.exe command line arguments to call our DLL and desired export\r\n4. Breakpoint on the entrypoint of our desired DLL export and run until we get to that location\r\nFirst of all we're going to open rundll32.exe in x64dbg (File -\u003e Open -\u003e C:\\Windows\\System32\\rundll32.exe )\r\nand then also configure x64dbg to automatically pause on every DLL entry point (Options -\u003e Preferences -\u003e DLL\r\nEntry):\r\nNow we can change the command line arguments passed to rundll32.exe so that when it's launched it will\r\nexecute our DLL at the Tk_CreateImageType export. To do this go to File -\u003e Change Command Line:\r\nAfter hitting \"OK\", and restarting the debugging process (Debug -\u003e Restart), we can now allow execution to\r\nproceed knowing that x64dbg will automatically breakpoint at the entrypoint of every DLL, including our target\r\nDLL. Keep pressing F9 (or Debug -\u003e Run) while keeping an eye on current DLL location listed in the bottom bar\r\nof x64ddb until we see that we've hit our target DLL (teardrop.dll in this case):\r\nIn the screenshot above we can see that we've successfully hit teardrop.dll in x64dbg and specifically we are at\r\nthe first TLS Callback of the DLL. Thread Local Storage (TLS) callbacks execute before the main entry point of\r\nPE files and have both legitimate and non-legitimate use-cases. Some malware samples have been known to\r\nleverage TLS Callbacks as a way to check if the process is being analysed before the main execution of the sample\r\nis reached:\r\nFor now we will move past the TLS callbacks and circle back later on if we need to dig deeper into the sample.\r\nKeep pressing F9 until we reach DLLMain of teardrop.dll :\r\nNow that we're in the target DLL, all we need to do is breakpoint on the Tk_CreateImageType export. To do this\r\nwe can go to the Symbols tab, select teardrop.dll in the left pane and then right click on the correct export in\r\nthe right pane and select Toggle Breakpoint :\r\nhttps://blog.securehat.co.uk/malware-analysis/extracting-the-cobalt-strike-config-from-a-teardrop-loader\r\nPage 2 of 6\n\nFinally we can once again allow debugging to continue (Debug -\u003e Run) until the status bar in the bottom of the\r\nx64dbg window shows that we've reached the start of the Tk_CreateImageType export:\r\nAt this point you may want to change the preferences of x64dbg so that it no longer breaks on every DLL entry,\r\nthis will make debugging easier and we can easily jump back to the CreateImageType export now that we have a\r\nbreakpoint set.\r\nAs mentioned at the start of this blog post, the main aim of the TEARDROP loader is to load a Cobalt Strike\r\nbeacon into memory on the victim machine. Using this knowledge we can make an assumption that by\r\nbreakpointing on memory related API calls we should hopefully be able to find the Cobalt Strike beacon being\r\nloaded into memory.\r\nTo start off this analysis route, we will set breakpoints on the following APIs:\r\nVirtualAlloc - allocate memory regions in the current process\r\nVirtualProtect - used to change the protection on a memory region\r\nVirtualQuery - gather information about a memory region in the current process\r\nVirtualFree - releases a memory region in the current process\r\nIf suspect that a sample may do some form of process injection, we may also want to set breakpoints on APIs such\r\nas VirtualAllocEx, OpenProcess, CreateRemoteThread, CreateProcessInternalW etc. However for this\r\nsample these breakpoints won't be necessary.\r\nThe easiest way to do this is to type bp \u003cAPI\u003e in the command window towards the bottom of the x64dbg\r\nwindow:\r\nNow that we have our breakpoints set, the initial plan is to follow the steps below:\r\n1. Break on calls to VirtualAlloc\r\n2. Track the allocated memory regions returned by the API call\r\n3. Inspect these regions as execution continues to identify interesting content being loaded into memory\r\nIn its default configuration Cobalt Strike beacons are loaded into memory in the form of a PE file, so by tracking\r\nthe contents of allocated memory regions we should hopefully be able to spot the Cobalt Strike PE file being\r\nloaded into memory prior to execution.\r\nTracking the Memory Regions Allocated by VirtualAlloc\r\nAllow the execution of the program to continue until we hit the first instance of VirtualAlloc being called:\r\nhttps://blog.securehat.co.uk/malware-analysis/extracting-the-cobalt-strike-config-from-a-teardrop-loader\r\nPage 3 of 6\n\nInspecting the documentation for VirtualAlloc shows us\r\nthat the return value of a successful call is the \"base address of the allocated region of pages\". By clicking Debug\r\n-\u003e Return to User Code after the breakpoint on VirtualAlloc we can allow the API call to complete and the\r\nbase address of the new memory region should be now be stored in the RAX register. We can follow this memory\r\nregion by right clicking on the RAX register and selecting \"Follow in Dump\":\r\nAfter clicking on Follow in dump we can see the allocated memory region in the x64dbg dump window towards\r\nthe bottom on the screen:\r\nAs we allow the execution of the program to continue we should see the contents of this memory region change,\r\nand hopefully we will see a PE file appear in this window relating to the Cobalt Strike beacon. If we hit\r\nsubsequent VirtualAlloc calls, we can follow the same process as above and track the regions in the different\r\ndump tabs.\r\nAfter allowing the execution of the program to continue, tracking a number of allocated memory regions, and\r\nallowing execution to continue over a number of VirtualProtect breakpoints, we can spot the start of a PE file\r\nin one of the memory regions:\r\nDumping the PE File to Disk\r\nAlmost any time we see a PE file being loaded into memory during malware analysis, it's worth dumping it to disk\r\nand analysing it further. In this case we're hoping that this is our Cobalt Strike beacon, so to progress the analysis\r\nof this sample we can dump this region of memory to disk.\r\nTo do this we can do the following:\r\n1. Right click on the desired memory region in the dump tab\r\n2. Click \"Follow In Memory Map\"\r\n3. In the new window that appears, right click on the highlighted memory region\r\n4. Click \"Dump Memory to File\"\r\nExtracting the Cobalt Strike Config\r\nNow that we have the PE file on disk, the final step is to attempt to extract the Cobalt Strike config information so\r\nthat we can identify IOCs and configuration information. Although we haven't confirmed that this PE file is\r\ndefinitely a Cobalt Strike beacon at this point, it's a safe bet when we take into account that the Symantec blog\r\npost reported that the sample will ultimately load a beacon into memory.\r\nhttps://blog.securehat.co.uk/malware-analysis/extracting-the-cobalt-strike-config-from-a-teardrop-loader\r\nPage 4 of 6\n\nFortunately it's very easy to check by using Sentinal One's Cobalt Strike config extractor:\r\nInspecting the parser code we can see that it looks for one of three byte patterns in order to identify the presence of\r\na Cobalt Strike config. If any of the byte patterns are found, then the parser will attempt to decode and print the\r\nconfiguration information of the Cobalt Strike beacon. The byte patterns that the parser looks for are:\r\n START_PATTERNS = {\r\n 3: b'\\x69\\x68\\x69\\x68\\x69\\x6b..\\x69\\x6b\\x69\\x68\\x69\\x6b..\\x69\\x6a',\r\n 4: b'\\x2e\\x2f\\x2e\\x2f\\x2e\\x2c..\\x2e\\x2c\\x2e\\x2f\\x2e\\x2c..\\x2e'\r\n }\r\n START_PATTERN_DECODED = b'\\x00\\x01\\x00\\x01\\x00\\x02..\\x00\\x02\\x00\\x01\\x00\\x02..\\x00'\r\nThe first two patterns reflect the two different XOR keys used in version 3 (0x69) and version 4 (0x2e).\r\nRunning the parser over the PE file that we extracted from the TEARDROP sample confirms that the file is a\r\nCobalt Strike beacon and that we can successfully extract the config:\r\n-\u003e % python parse_beacon_config.py teardrop_pefile.bin\r\nBeaconType - HTTPS\r\nPort - 443\r\nSleepTime - 14400000\r\nMaxGetSize - 1049217\r\nJitter - 23\r\nMaxDNS - 255\r\nC2Server - infinitysoftwares[.]com,/files/information_055.pdf\r\nUserAgent - Not Found\r\nHttpPostUri - /wp-admin/new_file.php\r\nMalleable_C2_Instructions - Remove 313 bytes from the end\r\n Remove 324 bytes from the beginning\r\n XOR mask w/ random key\r\nHttpGet_Metadata - Not Found\r\nHttpPost_Metadata - Not Found\r\nSpawnTo - b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'\r\nPipeName -\r\nDNS_Idle - 208.67.220.220\r\nDNS_Sleep - 0\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\nHttpGet_Verb - GET\r\nHttpPost_Verb - POST\r\nHttpPostChunk - 0\r\nSpawnto_x86 - %windir%\\syswow64\\print.exe\r\nSpawnto_x64 - %windir%\\sysnative\\msiexec.exe\r\nhttps://blog.securehat.co.uk/malware-analysis/extracting-the-cobalt-strike-config-from-a-teardrop-loader\r\nPage 5 of 6\n\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 - 943010104\r\nbStageCleanup - True\r\nbCFGCaution - False\r\nKillDate - 0\r\nbProcInject_StartRWX - False\r\nbProcInject_UseRWX - False\r\nbProcInject_MinAllocSize - 8493\r\nProcInject_PrependAppend_x86 - b'\\x90\\x90'\r\n Empty\r\nProcInject_PrependAppend_x64 - b'\\x0f\\x1f\\x00'\r\n Empty\r\nProcInject_Execute - ntdll:RtlUserThreadStart\r\n CreateThread\r\n NtQueueApcThread\r\n SetThreadContext\r\nProcInject_AllocationMethod - NtMapViewOfSection\r\nbUsesCookies - True\r\nHostHeader -\r\nThis site uses cookies to deliver its service and to analyze traffic. By browsing this site, you accept the privacy\r\npolicy.\r\nSource: https://blog.securehat.co.uk/malware-analysis/extracting-the-cobalt-strike-config-from-a-teardrop-loader\r\nhttps://blog.securehat.co.uk/malware-analysis/extracting-the-cobalt-strike-config-from-a-teardrop-loader\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://blog.securehat.co.uk/malware-analysis/extracting-the-cobalt-strike-config-from-a-teardrop-loader" ], "report_names": [ "extracting-the-cobalt-strike-config-from-a-teardrop-loader" ], "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": 1775434297, "ts_updated_at": 1775826738, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8a0d35c3569ccabf539172f02fe9aecf106a37e6.pdf", "text": "https://archive.orkl.eu/8a0d35c3569ccabf539172f02fe9aecf106a37e6.txt", "img": "https://archive.orkl.eu/8a0d35c3569ccabf539172f02fe9aecf106a37e6.jpg" } }