{
	"id": "87d981dd-1f29-4eb4-b2e6-211c70483539",
	"created_at": "2026-04-06T00:12:37.078106Z",
	"updated_at": "2026-04-10T03:20:25.950756Z",
	"deleted_at": null,
	"sha1_hash": "5dde5f2d8d7a01e538ab048b0418aa72e83b1b9b",
	"title": "From ZLoader to DarkSide: A Ransomware Story",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2159388,
	"plain_text": "From ZLoader to DarkSide: A Ransomware Story\r\nBy GuidePoint Security\r\nPublished: 2021-05-14 · Archived: 2026-04-05 21:36:27 UTC\r\n19 min read\r\nMay 14, 6:00am ET\r\nIntroduction\r\nThe DarkSide ransomware group has been on the scene since late 2020, but has spent a fair amount of time in the\r\nspotlight. With recent high profile attacks, such as the attack on the Colonial Pipeline, and their “Robinhood”\r\nmentality, it is not surprising that this group receives a lot of attention. \r\nThe GuidePoint DFIR team was called to respond to a recent incident involving DarkSide ransomware. In the end\r\nwe determined that this incident started, as so many other incidents do, with a malicious email and one of those\r\noh-so-lovely Excel 4 macro enabled attachments. As is common with these emails, the malicious email had an\r\nattached “invoice” that was “created in a previous version” and needs you to “enable content” in order for you to\r\nsee everything appropriately. \r\nFigure 1: Malicious email\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 1 of 23\n\nFigure 2: Malicious attachment\r\nAs the unsuspecting user enabled the contents of this Excel spreadsheet, nothing obviously bad happened, and\r\nthen they got one of those extremely helpful, and ultimately telling, popup alerts indicating that “something went\r\nwrong” while opening the document.\r\nFigure 3: Excel “error” message\r\nFor the user, this was the end of the interaction, however, for the attacker, this was just the beginning of a months-long operation. Further analysis determined that this Excel attachment belongs to the infamous ZLoader family of\r\nmalware. This initial intrusion into the user’s computer was just the beginning of post-exploitation operations\r\nincluding reconnaissance and lateral movement using Cobalt Strike and a unique PowerShell RAT that ultimately\r\nresulted in the deployment of DarkSide ransomware. \r\nIn this blog we will cover:\r\nThe mechanics of the ZLoader Excel 4 Macro and post installation ZLoader activity\r\nThe use of a unique PowerShell RAT and Cobalt Strike for post-exploitation operations\r\nThe deployment of DarkSide ransomware\r\nLet’s get to it.\r\nIt All Started with ZLoader\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 2 of 23\n\nFigure 4: Attack Progression – ZLoader\r\nThe threat actor was successful in getting the targeted user to open the malicious attachment and enable the\r\nmacros on the document. But there was an error message, so it ultimately didn’t install the malware right?\r\nUnfortunately not. This commonly employed trick is used by threat actors to get the users to quickly move on\r\nfrom the document and think that nothing bad actually happened. Clever trick, Hackerman. Clever trick.\r\nPhase One Macro Contents\r\nWe needed to confirm the identity and functionality of this document to provide critical context to the\r\ninvestigation. To examine this malicious document, we first validated that we were dealing with an Excel 4 macro\r\nenabled document. This was pretty obvious based on the randomly named sheet that was included in the\r\ndocument. To confirm our hypothesis, we leveraged our good friend PowerShell and the Excel.Application\r\nCOM Object to list out the Excel 4 macro sheets.\r\nFigure 5: Excel 4 macro\r\nCan confirm, Excel 4 macros were present. So now we knew we were dealing with Excel 4 macros and we\r\nconfirmed that the randomly named sheet is where they were located. As an aside, it was really nice of the threat\r\nactor to not hide the Excel 4 macro sheet, it was one less step for us to have to take to get to the good stuff. As an\r\naside to the aside, if you come across a suspected Excel 4 macro enabled document and do not see the randomly\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 3 of 23\n\nnamed sheet like we did, it’s likely that the threat actor set the sheets to be very hidden . There are ways around\r\nthis, including using a small amount of VBA code to unhide the sheets, but that is a blog for a different time. Let’s\r\ndig into this macro content.\r\nWe knew from our analysis, and the fact that the threat actor was successful in exploiting the patient zero system\r\nin this incident, that there was some automatic functionality that existed within this macro. Based on our\r\nknowledge of previously seen Excel 4 macro sheets, we performed the tried and true Control + F for the\r\nkeyword Auto to look for any cells within the macro sheet that would lead us to where macro execution would\r\nbegin. In this case, no dice. We then used the Name Box to determine if there were any existing named cells. \r\nFigure 6: Macro sheet Name Box\r\nAs we looked at the contents of the name box, we found just what we were looking for, the lead to where the\r\nmacro is going to start execution. As we selected the Auto_Open named cell to determine where in the sheet it\r\nresided, we found ourselves at the location R131C7 (row 131, column 7). From here, we saw that we were placed\r\nright in the middle of the macro code. \r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 4 of 23\n\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 5 of 23\n\nFigure 7: Auto_Open cell\r\nAt this point, we were in more familiar territory. The heavily obfuscated macro contents were a big clue that we\r\nwere on the right path in our analysis. During execution of Excel 4 macros execute from top to bottom, left to\r\nright. Armed with that knowledge, a quick look down the macro contents yielded two immediately interesting\r\nfindings: 1) there was a lot of unnecessary content, presumably to clutter things up for us malware analysts, and 2)\r\nthere were several calls to GET.WORKSPACE before an IF/THEN statement that included a HALT() action.\r\nSomething smelled a little anti-analysis at that point. \r\nFigure 8: Anti-analysis statements\r\nExcel 4 macros are extremely powerful and provide a lot of functionality for the malware author to work with\r\nwhile less than adequate documentation is available to us Blue Teamers. One such function used in many\r\nmalicious Excel 4 macros is the function GET.WORKSPACE . This function allows the macro to collect information\r\nabout the environment it’s running in. Luckily, I found this great resource to help quickly identify what the macro\r\nwas attempting to gain information on in the environment.\r\nWorkspace Integer Description\r\n42 Returns TRUE if the computer is capable of playing sounds.\r\n31 Returns TRUE if the computer is capable of playing sounds.\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 6 of 23\n\nWorkspace Integer Description\r\n19 Returns TRUE if a mouse is present.\r\nTable 1: GET.WORKSPACE types\r\nArmed with this knowledge, we quickly determined that the IF/THEN statement was indeed an anti-analysis\r\ntechnique that was meant to halt the execution if the computer was not able to play sounds, was executing the\r\nmacro in single step mode, or if no mouse was present. Good effort on the part of the threat actor for defeating\r\nsome sandboxes, but we easily overcame this measure by just removing it from the macro contents to avoid any\r\nsuch halting of our analysis.\r\nAs we continued to skim down the contents of the macro, we also saw a reference to a cell range from\r\nSheet1!R98C2:R150C2 . As we had a quick peak back over to Sheet1 , we found something quite interesting.\r\nJibberish!\r\nFigure 9: ZLoader obfuscated contents\r\nSo at this point, there was some obfuscated content which meant there was almost certainly going to be a\r\ndecoding routine that would deobfuscate this content. One last look down our macro content and we saw a call to\r\na randomly named function right before a HALT() statement.\r\nFigure 10: ZLoader decode function\r\nAs we went spelunking for more details on where the UPIomGRimaeV() might reside in the macro code, we found\r\na reference to UPIomGRimaeV=R47C7 . It was likely this is where the function resided (hint: it totally did). A quick\r\nreview of the contents determined that this decoding routine uses a pair of nested while loops to decode data from\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 7 of 23\n\na given range of rows by extracting characters using the INDEX() function and shifting those characters based on\r\na set of integers. Once decoded, the data is written into the sheet and gets executed when the function returns. It\r\nwas a little difficult to follow, this is where commenting code becomes your friend.\r\nNow we were ready to get to the interactive debugging of this macro, but because of how Excel 4 macros work,\r\nwe were unable to use the same techniques as we would with VBA based macros. No problem, we still had some\r\ntricks we could use to allow the macro to do all the work for us. First, we needed to make sure we removed the\r\nAuto_Open functionality from the sheet. This was easy to overcome, all we needed to do was delete the row that\r\ncontained the cell we found initially. Once we did that, we could enable macros and nothing would automatically\r\nexecute. \r\nSince we would be single stepping through this code a bit, we made sure that we removed that anti-analysis\r\nIF/THEN statement from the sheet as well. Now we wouldn’t be bothered by a HALT() while stepping through\r\nthe sheet. At that point we were ready to start stepping through the macro content, but we needed one more tool to\r\nhelp us control the execution flow of the document. We leveraged the powers of Excel 4 macros to stop execution\r\nat strategically placed locations using the PAUSE() function. As we placed these throughout the macro code, we\r\nwere able to make the macro do our bidding (I love it when it works out that way).\r\nThe last question we asked ourselves before beginning was “Where do we place our PAUSE() functions?” To\r\ndetermine this, we needed to take one more look at our macro contents. Located in the UPIomGRimaeV() is a call\r\nto the function ADDRESS() . This function returns the address for a cell based on the input parameters. The syntax\r\nof the ADDRESS() function is:\r\nFigure 11: ADDRESS ( ) Syntax\r\nBased on our macro, we saw the following use of the ADDRESS() function:\r\nFigure 12: Macro Use of ADDRESS ( )\r\nOur first guess was that this was going to be the address where the deobfuscated data was going to be written.\r\nBack in our macro code we found the following initial values for cOMQLQKLhjz and LJggUFElrs :\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 8 of 23\n\nFigure 13: Initial destination values\r\nOur theory was that the writing of deobfuscated contents was going to start in R182C7 . We placed our first\r\nPAUSE() in R181C7 and began running the macro. To do this, we went to R181C7 , right clicked on the cell and\r\nselected Run . And when we were presented with the Macro dialog box, we selected Run once again to let the\r\nmacro run until our designated PAUSE() location.\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 9 of 23\n\nFigure 14: Macro phase two\r\nPhase Two Macro Contents\r\nOur initial guess was correct, UPIomGRimaeV() was the decoding routine we were expecting and the deobfuscated\r\ncontents were written exactly where we expected them to be written. As we started to review this new content, we\r\nsaw some potentially solid indicators of compromise. However, as we finished our initial review of the contents\r\nwe noticed there are quite a few interesting actions being performed in this phase of the Zloader execution flow\r\nand most of them were dedicated to preventing our analysis. \r\nThe first thing that we saw was a combination of FORMULA() functions that included references to\r\nGET.WINDOW() and GET.WORKSPACE().\r\nFigure 15: Anti-analysis, round two\r\nAnother interesting piece of this section of anti-analysis techniques was the references to content in column 18.\r\nFurther analysis of the decoding routine revealed that there was a range of values in rows 43-46 in column 18 that\r\nwere used to ensure the content is decoded properly. If the resultant values of the FORMULA() calls are not\r\nexpected (i.e. the macro is being analyzed), this will result in contents that are not properly decoded. A pretty\r\ndecent technique to prevent automatic analysis, but that didn’t stop us. A simple deletion of these rows allowed us\r\nto continue on with our analysis without having to pay too much attention to these anti-analysis tricks.\r\nThe next anti-analysis technique was a little bit more clever, in our opinion. \r\nFigure  16: A random file of data\r\nFrom the contents above, you can see that a file, C:\\Users\\Public\\OYgPwoC.dat , is opened, and data is written to\r\nit one CHAR at a time while the size is less than 8465 bytes. From the FWRITE() function call, we can see that\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 10 of 23\n\nthe CHAR written to the file is random between 33 – 125. Further review of the macro showed that this file is not\r\nreferenced or used later in the execution flow. This process was meant to thwart those of us that tried to single step\r\nthrough the execution of the macro. You would have to iterate through this loop 8465 times to get through it.\r\nThat’s a lot of clicks and it’s quite effective at preventing analysis from that perspective. Tip of the hat to you on\r\nthis one, Hackerman.\r\nFurther in the execution of this phase of the macro, we saw yet another automated sandbox anti-analysis\r\ntechnique. The macro exports the contents of HKCU\\Software\\Microsoft\\Office\\16.0\\Excel\\Security and saves\r\nit to a file, C:\\Users\\Public\\g4od6F.reg . The goal was to create VBScript that reads the contents from the\r\nexported registry key and writes details of HKCU\\Software\\Microsoft\\Office\\16.0\\Excel\\Security\\VBAWarnings\r\ninto C:\\Users\\Public\\j47.txt , as shown below.\r\nFigure 17: Anti-analysis VBScript\r\nFurther review into the macro revealed that there were several uses of SEARCH() to look for 001 or 1 within\r\nthe contents of the exported registry key. The macro was looking to see if the VBAWarnings value is set to 001 ,\r\nwhich means that all macros are trusted on the system. This setting is most commonly used in automated sandbox\r\nenvironments and would often be effective at hindering analysis in those scenarios, but in our case, we were safe\r\nfrom this anti-analysis method. \r\nAs we continued gandering down our macro contents, we arrived at another call to our decoding routine,\r\nUPIomGRimaeV() . We used the same method of identifying where data is going to be written, placed a PAUSE() ,\r\nand let the macro do the work for us. \r\nFigure 18: Decoding, round two\r\nIn this case, we expected the data to start being written to R248C7 . With this in mind, if we placed our PAUSE()\r\nat R247C7 , we would be good to go. Once, the PAUSE() was strategically placed, we continued running the\r\nmacro to reveal the next (last) phase.\r\nThe Macro’s Final Form\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 11 of 23\n\nFinally, we arrived at our final destination. There were two methods that the macro would pursue downloading the\r\nfinal ZLoader payload. Based on the results of GET.WORKSPACE(1) , if the version information returned contains\r\n32 (32-bit version of Excel), the macro will pursue downloading its payload using VBScript instead of calling\r\ndirectly through native macro functions. \r\nFigure 19: Final macro contents\r\nIn the snippet above, if Excel is running in a 64 bit environment, everything will be handled through native\r\nfunctions within the macro. Calls to URLDownloadToFileA are used to obtain the payload and rundll32 is used\r\nto execute the DllRegisterServer exported function. The payload masqueraded as an HTML file, however, it\r\nwas actually a DLL. Once downloaded, the macro uses the ALERT() function to display the error message we\r\nsaw during our testing. Although this method is efficient and straightforward, it also appeared to have less\r\nresilience than the 32 bit process outlined below. \r\nIf the environment is determined to be a 32 bit version of Excel, the macro creates two separate VBScripts, one for\r\ndownloading the final payload, and the other for executing the payload.\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 12 of 23\n\nFigure 20: Download functionality VBScript\r\nThe macro creates the VBScript above for the download process and continues to run this VBScript inside of a\r\nloop while the ITI.html file is not present on the system. Once the payload has been successfully downloaded,\r\nanother VBScript is used to execute it on the impacted system. The execution mechanism used in the 32 bit\r\nscenario leverages the COM object for ShellBrowserWindow to invoke ShellExecute. \r\nFigure 21: Execute functionality VBScript\r\nAnd at this point, the threat actor had successfully tricked the targeted user into running the malicious Excel\r\nattachment, retrieved the next stage payload, and installed ZLoader onto the impacted machine. \r\nPost Exploitation Activity with ZLoader\r\nZLoader is a fully featured malware family that shares similarities with the infamous ZeuS codebase that was\r\nleaked in 2011. According to Malwarebytes, ZLoader has been actively maintained since 2019, with some sources\r\ndating its origins further back to 2016-2017. ZLoader has been covered extensively by Malwarebytes in a report\r\nfrom May 2020 where they deep dive on ZLoader and its capabilities. The amazing technical detail discussed in\r\nthis report makes it the go-to resource for understanding the technical details of ZLoader. \r\nZLoader consists of a loader that is responsible for loading the core component. From there, the main bot has the\r\nability to leverage additional plugins for capabilities such as VNC, or perform specific actions such as executing\r\nadditional malware, stealing information from the system such as cookies and/or passwords, or facilitating one of\r\nthe many capabilities that have been added as development of ZLoader continues. \r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 13 of 23\n\nThis is where the incident picked up, months after the initial ZLoader infection via malicious Excel document\r\ntook place in late 2020. \r\nZLoader is known to inject itself into the process msiexec.exe to continue running on an impacted system. In early\r\n2021, there was an EDR alert that was generated for a suspicious base64 encoded PowerShell execution. \r\nFigure 22: ZLoader PowerShell execution\r\nUsing the EDR platform, we were able to trace the injection actions of afhegyy.dll into msiexec.exe , classic\r\nZLoader behavior. Next, msiexec.exe spawned an instance of PowerShell that executed a base64 encoded\r\ncommand. Under several layers of base64 obfuscation and XOR decoding, the commands to be executed were as\r\nfollows:\r\nFigure 23: Deobfuscated PowerShell commands\r\nThe above PowerShell command downloads contents from the command and control server using the domain\r\noddhealth[.]com and decodes that content before using PowerShell to further execute commands on the system.\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 14 of 23\n\nLevel-Setting the Investigation\r\nAt this stage in our investigation we were investigating two timelines that had no evidence of being linked to one\r\nanother. We had confirmed the installation of ZLoader onto one system in the environment beginning in 2020\r\nwhich had alerted within the EDR platform when it executed a potentially malicious base64 encoded PowerShell\r\ncommand and we were aware of the encryption events of DarkSide that took place within the environment. There\r\nwas a shortage of logs on the system impacted with ZLoader which made it hard to track all activities ZLoader\r\nactioned between the date of initial infection and the date of discovery.\r\nAfter the discovery of ZLoader in the environment, we began scoping operations for malicious PowerShell and\r\nfound a separate system executing an interesting and unique PowerShell RAT that shared a link with ZLoader and\r\nits use of the domain oddhealth[.]com . It turned out that this was the missing link we needed to tie our timelines\r\ntogether.\r\nPowerShell RAT with a Side of Cobalt Strike\r\nFigure 24: Attack Progression (PowerShell RAT and Cobalt Strike)\r\nPreviously, we blogged about a GUID based Cobalt Strike Stager that was used extensively during this incident\r\nand contributed to the threat actors success of laterally moving within the environment and conducting post-exploitation operations. This tactic was extremely effective in the environment for lateral movement and post-exploitation activities, however, we also found that the threat actor was utilizing a unique PowerShell RAT to\r\namplify their capabilities within the environment.\r\nSophos recently covered many of the modules and capabilities of the PowerShell RAT that we also observed\r\nduring our investigation. As Sophos outlined in their blog, the PowerShell RAT had a lot of capabilities that were\r\naimed at reconnaissance, defense evasion, and command execution. To add to Sophos’ already great detail on this\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 15 of 23\n\nPowerShell RAT, we wanted to highlight some of the finer details that stood out to us as making this RAT\r\ninteresting and unique.\r\nLateral Movement\r\nDuring our investigation we observed that the PowerShell RAT was used to deploy a module that was intent on\r\nexecuting the RAT on additional targeted systems. The module contained a base64 encoded version of the RAT\r\nsaved in a variable called $bulletB64 . The contents of the “bullet” were then to be transferred to the target\r\nsystem and stored in the ADMIN$ share with a randomly generated name.\r\nFigure 25: Bullet deployment\r\nOnce the “bullet” was deployed to the remote system, the module then used the service control manager to create\r\na service to execute the RAT. During lateral movement, the service name always takes the form VmHealthCheck\r\nwith a random number appended to the end and uses PowerShell to execute the RAT.\r\nFigure 26: Lateral movement\r\nThe Disappearing Act\r\nThe RAT has a built in function called Remove-Myself that is responsible for, well, removing itself from the\r\nimpacted system. This isn’t a novel concept, however, it is effective at not leaving traces of itself around the\r\nenvironment, which makes the investigation a little harder (especially if PowerShell logging is not enabled).\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 16 of 23\n\nFigure 27: Remove-Myself\r\nUse of Group IDs\r\nThe RAT includes a hardcoded GroupID within its code. Although we do not have a large sample set of this RAT\r\nfrom multiple incidents, it is possible that the GroupID may be leveraged for larger campaigns in the future, or\r\ndistributed amongst additional affiliates to be used to track what organization an infected system belongs to.\r\nFigure 28: GroupID\r\nDebug Statements\r\nThis PowerShell RAT is user friendly and has explicit functionality built in to provide debug statements to the\r\nuser, if desired. Adding this functionality was an intentional choice by the malware developer and demonstrates\r\ntheir willingness to make sure their tool works and provides adequate feedback. And if not, they have an easy way\r\nto debug issues they might be having on impacted systems.\r\nFigure 29: Debug functionality\r\nIn many cases, threat actors are not interested in making user friendly code, they just want something that works.\r\nIn this case, this author used good coding practices to make it much more friendly to use, and to read. Thanks\r\nHackerman, much appreciated.\r\nThe Use of PowerShell Jobs\r\nPowerShell includes the Start-Job cmdlet to allow for the execution of a command as a background job. This\r\nwill allow PowerShell to handle the command, and store the results, until the details of the job can be provided\r\nback to the original job creator. For a semi-interactive RAT like this, especially when larger modules are used for\r\nreconnaissance or otherwise, allowing PowerShell to handle these as jobs is extremely advantageous and efficient.\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 17 of 23\n\nFigure 30: PowerShell jobs\r\nConnecting the RAT to ZLoader\r\nAs we uncovered evidence surrounding the usage of the PowerShell RAT and its associated modules within the\r\nenvironment, we saw that the vast majority of instances of the PowerShell RAT used the hardcoded URL,\r\nhxxps://bestsecure2020[.]com/gate . That was until we found one system dating back to the same timeframe\r\nwe observed for the EDR alert mentioned above for a ZLoader execution in the environment. Upon reviewing the\r\ncontents of the PowerShell RAT installed on this system, we found that the hardcoded URL in this version of the\r\nRAT was hxxps://oddhealth[.]com/gate . Further, when we compared the RAT contents from this newly\r\ndiscovered system to other systems on the network, they shared the same GroupID value.\r\nThis was just the link we needed to connect the initial ZLoader infection with the PowerShell RAT activity we\r\nsaw throughout the environment. Several months after the initial infiltration by ZLoader, the threat actors\r\nleveraged a PowerShell RAT and Cobalt Strike to laterally move and embed themselves within the network.\r\nUnfortunately for this client, the endgame of this threat actor was to complete their attack with the devastating\r\ncombination of data exfiltration and encryption.\r\nWrapping Up Operations with DarkSide Ransomware\r\nMuch like most ransomware incidents, this scenario didn’t have a happy ending. In the end, the threat actors took\r\nadvantage of the several months that they had in the environment to exfiltrate data, and move into encrypting files\r\nin the environment.\r\nThe technical details of the DarkSide ransomware binary have been blogged about a number of times, including a\r\nrecent blog by FireEye where they deep dive on the inner workings of the binary and its capabilities. \r\nDarkSide is well known for being a Ransomware-as-a-service and having an affiliate program. This allows the\r\naffiliates to generate ransomware binaries from DarkSide’s portal and conduct their operations as they see fit (as\r\nlong as they stay within DarkSide’s guidelines for targets, etc.). This also means that there is an opportunity for\r\nunexpected variations in tactics and techniques as affiliates join and leave DarkSide. In this incident, we found\r\nsome tactics to be consistent with other reports, but we also found some variations in methodology that were not\r\nas common.\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 18 of 23\n\nFigure 32: DarkSide ransom note\r\nDeploying DarkSide Using Services\r\nEarly on in the deployment process, the threat actor leveraged RDP to interactively execute DarkSide on a limited\r\nnumber systems in the environment. This may have been a test to validate that the ransomware would execute as\r\nexpected. From there the service control manager was used to deploy ransomware via a service on a high number\r\nof systems. \r\nFigure 33: Service execution (Windows Event Log)\r\nFigure 34: Service configuration (Windows Registry)\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 19 of 23\n\nThe service is configured as a manual, user mode service and leverages a staged DarkSide binary in a maliciously\r\ncreated share on a Windows Active Directory domain controller. Through the installation of this service they were\r\nable to execute ransomware across many systems almost simultaneously. Knowing that the threat actors leveraged\r\nPowerShell and Cobalt Strike so heavily, this method of deployment was not surprising.\r\nBYOB (Bring Your Own Browser)\r\nFigure 35: Phyrox portable FireFox browser\r\nOn one of the main staging machines, the threat actors leveraged a portable FireFox browser called Phyrox\r\nportable. This allowed the threat actor to subvert normal forensics data collection to analyze web based activity\r\nconducted during the time of compromise. Additionally, this portable browser facilitated the threat actor’s ability\r\nto use MegaSync to exfiltrate files from the environment.\r\nAttacking ESXI Hosts\r\nAlthough not new for DarkSide matters, ESXI systems were targeted heavily in this incident. This is particularly\r\ndestructive because the threat actor is able to bring down a very high number of systems with minimal effort.\r\nUnfortunately, due to ongoing remediation efforts, we were unable to recover the Linux binary responsible for\r\nencrypting ESXI systems.\r\nRecommendations\r\nAs we are seeing from recent reports of DarkSide activity, in addition to our findings from this recent incident,\r\nDarkSide and its affiliates are evolving to include new techniques focused on  being more effective during their\r\noperations. Here are some recommendations for proactively detecting and mitigating DarkSide activity in your\r\nenvironment:\r\n1. Ensure that EDR and other behavioral detection mechanisms are enabled and being actively reviewed in\r\nthe environment. \r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 20 of 23\n\n1. Implement detections for suspicious and malicious behaviors including rundll32, regsvr32, or other\r\nnative Windows processes making connections to external IP addresses.\r\n2. Review all \u0026 baseline Powershell executions for anomalies. \r\n3. Review 7045 events for new Service Creations\r\n2. Consider implementing Application Whitelisting on critical hosts (eg Domain Controllers, Web Servers,\r\nCrown Jewels, etc.)\r\n3. Increase Windows event logging to ensure that critical events are captured, and alerted on if possible.\r\nSysmon is a great choice for this type of logging.\r\n4. Actively perform threat hunting in your environment and incorporate threat intelligence into your hunting\r\nactivities.\r\n5. Consider explicitly denying macros on Microsoft Office documents, if possible.\r\n1. If macros cannot be disabled for legitimate business processes, consider adding additional\r\nmitigations to limit impact if a compromise occurs. \r\nConclusion\r\nWhat started with a malicious email carrying a ZLoader attachment resulted in a months-long operation to\r\nperform reconnaissance, lateral movement, data exfiltration, and deployment of DarkSide ransomware. This\r\nincident revealed some new and interesting tactics and techniques utilized to deliver DarkSide to the client’s\r\nenvironment.\r\nDarkSide ransomware is known to be one of the most notorious Ransomware-as-a-Service groups currently\r\noperating today. As such, they provide their ransomware services to affiliates that infiltrate, conduct post\r\nexploitation operations, and ultimately deploy DarkSide’s ransomware for a cut of the profit.\r\nDarkSide is a great example of an effective ransomware that brings devastation to private organizations and\r\ncritical infrastructure alike. Although they may publicly portray a “Robinhood” persona, they continue to\r\nvictimize organizations and hold data hostage. However, DarkSide also brings to light the aging infrastructure of\r\nour critical systems and how security has struggled to keep up in our currently connected world. As ransomware\r\ncontinues to grow as a concern on the national stage, we know now, more than ever, that cybersecurity has to be at\r\nthe beginning of every technology conversation.\r\nAcknowledgements\r\nWe would like to acknowledge Vikas Singh (@vikas891) for his collaboration on the PowerShell RAT and for his\r\nwillingness to establish a dynamic intel relationship with us. \r\nIndicators of Compromise (IOCs)\r\nIndicator Type Description\r\n0C6B41D25214F04ABF9770A7BDF\r\nCEE5D\r\nmd5 AMSI Bypass Utility\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 21 of 23\n\nIndicator Type Description\r\n805AB904BFD0A55413B10105FF9\r\nD97ACF54653F5\r\nsha1 AMSI Bypass Utility\r\nBAC99F7A488AC0499EA1636F4D1\r\n6DD3DFCA2C1C4EBFF06C3374D19\r\n4CE16B8233\r\nsha256 AMSI Bypass Utility\r\nnonaterscont1986@yahoo[.]com email Certificate of Cobalt Strike Stager\r\nastara20[.]com domain Cobalt Strike\r\nhxxps://astara20[.]com/jquery-3.6.1\r\n.slim.min.js\r\nurl Cobalt Strike\r\n28e9581ab34297b6e5f817f93281f\r\nfac\r\nmd5 Cobalt Strike\r\n40802ad6a0b1d4eb0f0d73f62136b\r\n209a3b58592\r\nsha1 Cobalt Strike\r\ne496c41793b4eef1990398acd18de\r\nb25dd7e8f63148e3b432ff726d3dc\r\n5e1057\r\nsha256 Cobalt Strike\r\n195.123.214.44 ip-dst Cobalt Strike\r\nf4250b961bd1c8694a949429f739d\r\n9f424283612\r\nsha1 CrackMapExec\r\n3a5ae4f28f21990a7d50f68b6c1205\r\n63495fb23feec6244c9a9b7c82a6eb\r\n557b\r\nsha256 DarkSide\r\nbaroquetees[.]com domain DarkSide\r\n176.103.62.217 ip-dst DarkSide\r\n198.54.117.244 ip-dst DarkSide\r\nbestsecure2020[.]com domain PowerShell RAT\r\nhxxps://bestsecure2020[.]com/gate url PowerShell RAT\r\n45.147.230.200 ip-dst PowerShell RAT\r\n162.255.119.236 ip-dst PowerShell RAT\r\nhxxps://oddhealth[.]com/gate url PowerShell RAT\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 22 of 23\n\nIndicator Type Description\r\noddhealth[.]com domain PowerShell RAT and Zloader\r\nobservatorioddnnya.misiones.gob[.]ar domain Zloader\r\nwaydreamacmenlimo[.]tk domain Zloader\r\npousadadosolbuzios.com[.]br domain Zloader\r\nmcvinod[.]com domain Zloader\r\nweedgifter[.]com domain Zloader\r\nmezoakademi[.]com domain Zloader\r\n649480397ac295adc069434feadc\r\n1c5a6a591e70f12f58b4727bce12\r\n87d25641\r\nsha256 Zloader DLL\r\nb7d0505d871f41d0f0cff029e4336\r\n220aa0b77c5\r\nsha1 Zloader DLL\r\n8ed02c32f1db794bc51cdc0f08125\r\n7c9\r\nmd5 Zloader DLL\r\n90446D1647598022CB0A94E57B\r\n2EA076BF26FF8EDFA769888BD1\r\n09268A35A6F9\r\nsha256 Zloader Malicious Excel Document\r\n5DCBF5FA356424E60EEF2569F9\r\nB1E5512ECADC7E\r\nsha1 Zloader Malicious Excel Document\r\nCF19968A8D611A9A301A6A9AA\r\n9CCBDEF\r\nmd5 Zloader Malicious Excel Document\r\nTable 2: Indicators of Compromise\r\nSource: https://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nhttps://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.guidepointsecurity.com/from-zloader-to-darkside-a-ransomware-story/"
	],
	"report_names": [
		"from-zloader-to-darkside-a-ransomware-story"
	],
	"threat_actors": [],
	"ts_created_at": 1775434357,
	"ts_updated_at": 1775791225,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5dde5f2d8d7a01e538ab048b0418aa72e83b1b9b.pdf",
		"text": "https://archive.orkl.eu/5dde5f2d8d7a01e538ab048b0418aa72e83b1b9b.txt",
		"img": "https://archive.orkl.eu/5dde5f2d8d7a01e538ab048b0418aa72e83b1b9b.jpg"
	}
}