{ "id": "95f1aebe-120a-4171-9911-460cefe0ca25", "created_at": "2026-04-06T00:07:30.30092Z", "updated_at": "2026-04-10T03:24:24.437917Z", "deleted_at": null, "sha1_hash": "3466d11eb132c577a42e94641579f4c3a1875125", "title": "Yet Another Cobalt Strike Stager: GUID Edition", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 209472, "plain_text": "Yet Another Cobalt Strike Stager: GUID Edition\r\nBy GuidePoint Security\r\nPublished: 2021-03-30 · Archived: 2026-04-05 17:51:01 UTC\r\n03/30/21 at 4:00pm ET\r\nIntroduction\r\nLike most Mondays in the DFIR world, the week started off with a bang. On this particular day, our DFIR team\r\nwas supporting an incident response. Information from the incident indicated that the client was most likely\r\nimpacted by a large installation of Cobalt Strike in an ongoing attack from an unknown adversary. Our task was to\r\nanalyze an unknown file with a random name and random file extension to determine if it could be related to\r\nCobalt Strike and determine if there are other indicators of compromise that could assist the DFIR team with\r\nscoping operations and response.\r\nSpoiler alert: It was a Cobalt Strike stager and it used a pretty cool technique to obfuscate its shellcode using\r\nGUIDs.\r\nIn this blog we will cover:\r\nInitial static analysis of the unknown file\r\nGUID based shellcode extraction and analysis\r\nBeacon retrieval from the team server\r\nLet’s dig in.\r\nAlong Came a DLL\r\nInitially we were provided with an interestingly named file that was suspected of being malware. In this case, the\r\nfile in question was a DLL found at the location C:\\Windows\\Temp and was named 3z5pjb0l.ab4 . Based on the\r\nnaming convention and the fact that it was a DLL, we were pretty well convinced that this was going to be some\r\nsort of malware.\r\nRunning through some quick static checks of this sample, we were able to find some quick wins that would point\r\nus in the right direction. To begin, we did a quick strings check with FLOSS and saw the following:\r\nFigure 1: FLOSS strings output\r\nThe string beacon32.dll is one of the tell-tale signs of a Cobalt Strike component. We were well on our way to\r\nconfirming the initial reports that this sample is related to Cobalt Strike. We attempted to parse this DLL as a\r\nCobalt Strike beacon, but, unfortunately, no dice. It’s possible that we are dealing with a new variation of a\r\nbeacon, or it could be a stager. We will need to dive deeper to find out.\r\nhttps://www.guidepointsecurity.com/yet-another-cobalt-strike-loader-guid-edition/\r\nPage 1 of 5\n\nWhile quickly checking into a few more static properties of the sample, we did notice a couple of additional\r\ninteresting properties about this DLL. According to output from pestudio, this sample was signed and attempted to\r\nmake itself appear like it was a valid Microsoft binary through its version information. Pretty solid attempts at\r\nlegitimizing the DLL, in our opinion.\r\nFigure 2: Version information\r\nFigure 3: Certificate Information\r\nBefore we moved on, we also noticed something quite interesting in the FLOSS output under the Unicode strings,\r\na whole series of strings that looked like GUIDs.\r\nFigure 4: GUID like strings from FLOSS output\r\nAt this stage of our analysis, we noted this as interesting, but didn’t know what their role could be just yet. So we\r\njumped into IDA for a deeper look at the DLL and decided to circle back around to this shortly.\r\nGUID-ing Deeper with IDA\r\nAs details trickled in from the incident, we were provided with additional information regarding the execution\r\nmechanism of this DLL on impacted systems. In this case, the execution mechanism uses regsvr32 and was\r\nexecuted using the following syntax: regsvr32.exe /s /i 3z5pjb0l.ab4 . When used with the /i switch,\r\nregsvr32 will invoke the DllInstall export with the specified argument, and this is where we started our\r\nreview in IDA.\r\nPulling up the decompiled code of DllInstall in IDA, we got a glimpse into the intended functionality of the\r\nDLL. The DllInstall function allocates memory, performs a data manipulation routine to fix up the shellcode for\r\nexecution, changes the memory page permissions to PAGE_EXECUTE_READWRITE and executes the shellcode. \r\nLocated below is a commented version of the DllInstall export showing the intended execution flow of the\r\nDLL.\r\nFigure 5: DllInstall decompiled code\r\nNow, to figure out what shellcode was going to be executed, we needed to take a deeper look into the decoding\r\nfunction we named mw_Decoding_Routine . Interestingly enough, this function was the only function that IDA\r\nhttps://www.guidepointsecurity.com/yet-another-cobalt-strike-loader-guid-edition/\r\nPage 2 of 5\n\ncould not identify during its analysis of the binary. To us, this meant that the overall functionality of the DLL was\r\nlikely for a singular purpose, you know, maybe for something like a Cobalt Strike stager.\r\nFigure 6: Shellcode decoding routine\r\nA quick look at this short function tells us that the intent is to iterate through a data set and call\r\nGUIDFromStringW . Full disclosure: it took me a few minutes to figure out why this was important to the suspected\r\nstager. After a short period of Google Fu and searching my brain for leads, I remembered two things: 1) we saw\r\nsome GUID looking strings in the FLOSS output from earlier (circling around as promised!) and 2) GUIDs are a\r\nspecial type of data in Microsoft Windows. \r\nAccording to Microsoft’s official documentation for GUID structures, GUIDs are 128-bit values and are most\r\ncommonly used for COM interfaces, COM class objects, or a manager entry-point vector (EPV). At this point, our\r\nwheels started churning a bit faster. What if the purpose of calling GUIDFromStringW was to allow for a binary\r\ntype object to be derived from the strings found in the DLL? Sounds like a pretty great way to obfuscate shellcode\r\nto me. Let’s verify with the help of our good friend PowerShell.\r\nFirst, we placed all of the GUID-looking strings identified from the FLOSS output into a text file. Then we used\r\nthe PowerShell script below to consume and iterate through all of the GUID-looking strings, convert them to an\r\nactual GUID, convert the new GUID into bytes, and append them onto a byte array. Once we had the complete\r\nbyte array, we wrote the raw bytes to a file that we could use for further analysis.\r\nFigure 7: PowerShell script to extract shellcode\r\nSo if our assumptions were accurate, we now had a file containing the deobfuscated shellcode from the sample. \r\nWe validated that our hypothesis was correct by running output.bin through SpeakEasy to emulate the\r\nsuspected shellcode. \r\nFigure 8: SpeakEasy output from shellcode emulation\r\nAww yis! That’s what we like to see from our shellcode extractions. This is one of the hallmarks of  Cobalt Strike,\r\nthe malleable C2 profile. Take a look at this Spectre Ops blog for further details on setting up malleable C2\r\nprofiles in Cobalt Strike. The shellcode we uncovered used a series of strings converted into GUIDs as shellcode\r\nto download a Cobalt Strike payload from a team server and execute it in memory. Pretty cool stuff.\r\nAt this stage, we have accomplished most of our initial goals. We confirmed that the sample provided from the\r\nincident was in fact, a stager for a Cobalt Strike payload. Additionally, we identified the domain being used by the\r\nteam server used by the threat actors. \r\nhttps://www.guidepointsecurity.com/yet-another-cobalt-strike-loader-guid-edition/\r\nPage 3 of 5\n\nWe’ve been helpful up until this point, but let’s take it a step further and retrieve a beacon for science.\r\nBeckoning a Beacon from the Team Server\r\nIt is well known that Cobalt Strike is flexible and capable of implementing protections on team servers to prevent\r\njust anyone from successfully interacting with it. However, we have the deobfuscated shellcode that the stager\r\nuses to download and execute the beacon, so let’s use that to our advantage.   From the screenshot above several\r\nof the HTTP headers, we can see that an actual Cobalt Strike stager will use to retrieve a beacon before loading it\r\ninto memory and executing it. So let’s use that information to craft a curl command that will (hopefully) retrieve\r\nthe beacon from the team server.\r\nFigure 9: curl command for retrieving the Cobalt Strike beacon from the team server\r\nAt this stage, it’s important to mention OpSec considerations. We chose to utilize Orjail in conjunction with a non-attributable network connection to retrieve the beacon payload from this Cobalt Strike team server. Consider your\r\norganization’s OpSec policies and strategies before attempting to interact with an adversary’s infrastructure. And,\r\nas always, keep it legal.\r\nAfter executing our crafted curl command, we were the proud owners of a Cobalt Strike beacon. We were able to\r\nmove forward with parsing the beacon contents to gather further information to supply  our DFIR team working\r\nthe incident. \r\nFigure 10: Cobalt Strike beacon configuration\r\nFrom this parsed beacon configuration, we can pass on many of the same details we discovered from stager\r\nshellcode (domain, port, protocol, user agent, etc.). However, we also got some additional information that will\r\nhelp scope  operations during the incident. We now know that the beacon intends to spawn into svchost.exe -k\r\nnetsvcs . With this information we can begin examining svchost processes that are exhibiting interesting behavior\r\nthat needs to be addressed further.\r\nRecommendations\r\nCobalt Strike is notorious for evading detection before it established a foothold in the environment, which\r\nhappened to be the case in this incident as well. Here are some recommendations for proactively detecting Cobalt\r\nStrike within your environment:\r\n1. Proactive threat hunting in your environment is a great way to detect threats based on anomalies and\r\nintelligence proactively. Using environment baselines to hunt for active threats is a great method of\r\nidentifying active threats in the environment.\r\n2. Developing hunts and signatures around anomalous regsvr32 executions would have detected this Cobalt\r\nStrike stager early in the attack chain. Focusing on suspiciously named DLLs would be a quick win in this\r\ncategory (Looking for regsvr32 processes communicating with external IP addresses)\r\nhttps://www.guidepointsecurity.com/yet-another-cobalt-strike-loader-guid-edition/\r\nPage 4 of 5\n\n3. Establishing detections with suspicious command-line arguments would have decreased the dwell time of\r\nthis threat in the environment. Implementing detections for command line arguments containing TEMP\r\nwould be a good starting point.\r\nConclusion\r\nCobalt Strike continues to be used by red teamers and adversaries alike. Defense evasion capabilities continue to\r\nbecome more complex and effective. Using a series of GUIDs to generate shellcode may not be new or novel, but\r\nthe fact remains that the stager was effective (and it was pretty cool). The stager DLL ran on a high volume of\r\nsystems with no detections from antivirus or EDR products allowing the adversary to gain a substantial foothold\r\ninto the environment. Rapid malware analysis in this scenario was key to confirming the tool and giving our DFIR\r\nteam the edge to continue responding to this threat.\r\nFrom our perspective, sharing adversary tactics like these and our methods of defeating them with the community\r\nis critical for our blue team collective. If we all get better at detecting, analyzing, and responding to adversarial\r\ntactics, that’s a win for all of us.\r\nUntil next time, happy hunting.\r\nSource: https://www.guidepointsecurity.com/yet-another-cobalt-strike-loader-guid-edition/\r\nhttps://www.guidepointsecurity.com/yet-another-cobalt-strike-loader-guid-edition/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.guidepointsecurity.com/yet-another-cobalt-strike-loader-guid-edition/" ], "report_names": [ "yet-another-cobalt-strike-loader-guid-edition" ], "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": 1775434050, "ts_updated_at": 1775791464, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/3466d11eb132c577a42e94641579f4c3a1875125.pdf", "text": "https://archive.orkl.eu/3466d11eb132c577a42e94641579f4c3a1875125.txt", "img": "https://archive.orkl.eu/3466d11eb132c577a42e94641579f4c3a1875125.jpg" } }