{ "id": "9cccd97c-08f3-4018-8023-de771bcf78cf", "created_at": "2026-04-06T00:06:20.102185Z", "updated_at": "2026-04-10T03:24:29.983786Z", "deleted_at": null, "sha1_hash": "340609470f95295541632875ceb7635330e064da", "title": "Tracing fresh Ryuk campaigns itw", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1374181, "plain_text": "Tracing fresh Ryuk campaigns itw\r\nBy Gerardo Fernández\r\nArchived: 2026-04-05 22:35:05 UTC\r\nRyuk is one of the most dangerous Ransomware families. It is (allegedly) run by a specialized cybercrime actor\r\nthat during the last 2 years mainly focused on targeting enterprise environments. The amount of bitcoins\r\ndemanded in their ransom attacks varies depending on the target. Some of the wallets used by the group to collect\r\nthe ransom payments reached millions of dollars in a few weeks.\r\nProtecting against such attacks is one of the main priorities for any CISO or security team. This is a problem that\r\nshould be approached from different perspectives, being prevention (likely) the most relevant one.\r\nNow, what can be done in terms of prevention? Information is power, the first thing we need is understanding how\r\nthe new campaigns are operating. Is this distributed through phishing or exploiting any vulnerabilities? Do they\r\nuse brute force attacks? Maybe all together?\r\nIn addition to the TTPs described above, we want as many technical details as possible. This will result in very\r\nvaluable Indicators of Compromise we can use for protecting our infrastructure: deploying networking indicators\r\nto disrupt malware communication, making sure our Yara rules will detect all the components of the attack,\r\nlaunching regular scans in our infrastructure to detect any artefact used in the campaign.\r\nWe need to quickly deploy our fishing nets to catch everything related to fresh new campaigns! And then to keep\r\nmonitoring for a while to make sure we keep our systems updated as attackers evolve.\r\nIn this blogpost we will describe how we used VirusTotal to detect and monitor new Ryuk activity. However this\r\nis a very specific case where we want to show how our IDA plugin can save us a lot of time when dealing with\r\ncertain samples.\r\nIf you want to learn more about how you can keep your organization safe from ransomware and how to easily\r\nleverage VirusTotal to monitor ransomware activity, please join us for our next Anti-ransomware workshop -\r\nEnglish (Live November 4th, 1pm ET) and Spanish (Live October 28th, 17:00 CEST) versions available.\r\nStarting the investigation\r\nTwo weeks ago new files were uploaded to VirusTotal (1, 2). According to the crowdsourced YARA rule that\r\nidentified them, these files looked like Ryuk malware.\r\nhttps://blog.virustotal.com/2020/10/tracing-fresh-ryuk-campaigns-itw.html\r\nPage 1 of 6\n\nA closer look revealed that these samples have been probably dumped from memory: the disassembled code\r\nshowed plenty of memory mapped addresses, the import table was missing and the samples crashed when\r\nexecuted - they were definitively corrupted PE files.\r\nGiven these were fresh samples, we certainly wanted to know more about them, especially if they were part of a\r\nbigger campaign. In such cases, one of our best allies is looking for similar samples that could also be part of the\r\nattack. However, when working with memory dumps we need to be careful, given that probably some segments\r\nand memory mapped addresses will be execution specific. If we include any of such specifics in our search, we\r\nwon't be able to find other samples.\r\nIDA plugin to the rescue\r\nOne of the options would be to rebuild the samples we found, which is an extremely time consuming process.\r\nInstead, we can use the VirusTotal IDA plugin (see original blog post announcement) to help us search for the\r\noriginal sample. Using the \"search for similar code\" functionality we can create a query that will ignore all the\r\nmemory mapped addresses, being a perfect choice for our problem.\r\nTaking a look at the samples with IDA, we can see there are many functions that aren't properly identified by the\r\ndisassembler engine given the use of anti-disassembly techniques. Precisely for this reason, they are good choices\r\nfor searching for code similarity.\r\nhttps://blog.virustotal.com/2020/10/tracing-fresh-ryuk-campaigns-itw.html\r\nPage 2 of 6\n\nWe just need to select the code, right-button, and search for similar code. The resulting query will take care of\r\nignoring all the memory mapped addresses we wanted to get rid of.\r\nhttps://blog.virustotal.com/2020/10/tracing-fresh-ryuk-campaigns-itw.html\r\nPage 3 of 6\n\nThe resulting listing with all the files found shows very close first submission time. Also, some of them report\r\nbehaviour activity, meaning they executed in the sandboxes without crashing: maybe one of them could be our\r\noriginal sample.\r\nPicking one of our initial samples and another one with behavioural information, we can see that:\r\nThey don't show up as similar when doing a similarity search (as expected).\r\nThey have some long sequences of bytes in common.\r\nIs this our sample?\r\nAt this point we feel confident that the new sample found is the one we were looking for. Indeed, starting from\r\nthis sample and taking a look at the (undetected) function located at 0x35008A60, we select a large sequence of\r\ninstructions with the IDA plugin (as we did before) for a new search. This results in only 4 files that match the\r\nhttps://blog.virustotal.com/2020/10/tracing-fresh-ryuk-campaigns-itw.html\r\nPage 4 of 6\n\nquery generated: our two initial samples, another file that's also corrupted, and the previously chosen sample that\r\ndetonated in our sandboxes. Therefore, this is the second time that we get this file when looking for similar code.\r\nGoing deeper, we'll see that it shares the same PE entry point that our two initial corrupted files. Furthermore,\r\ntheir WinMain functions are the same. Initially it looks like a quite simple function, composed of only three\r\nblocks of code. But, after overcoming the anti-disassembly trick implemented to confuse IDA, we can compare\r\nboth function graphs to see the similarity. We conclude that we found the original sample.\r\nWhat now?\r\nAt the time of this research there isn't any Yara rule detecting the original sample and it has 28/71 positives. Inside\r\nthis file we can find encrypted strings that are extremely useful for pivoting to find additional samples. These\r\nstrings are included in the corrupted files as well, stored in the \".gfids\" segment at the end of the file. In other\r\nwords, they aren't located in the \".data\" segment as seen in the original sample. This new location reveals that\r\nhttps://blog.virustotal.com/2020/10/tracing-fresh-ryuk-campaigns-itw.html\r\nPage 5 of 6\n\nprobably these strings were initially encrypted and became decrypted after execution, thus they can be seen as\r\nfootprints of the original sample.\r\nUsing the VT-IDA plugin we can search for other files that contain these encrypted strings. As expected, the four\r\nfiles found before are listed now, but there are two other samples that were submitted three days prior to our\r\noriginal sample and can also be investigated.\r\nMoreover, all these new strings can be used to improve the original Yara rule that brought us here, or to create a\r\nnew one! Remember to keep it running as a LiveHunt to make sure you keep track of any new Indicators of\r\nCompromise and to detect anything new attackers use in their campaigns. You can find all the details about the\r\ncampaign described in this blogpost in the following VT-Graph.\r\nThis post was co-authored by Vicente Diaz.\r\nSource: https://blog.virustotal.com/2020/10/tracing-fresh-ryuk-campaigns-itw.html\r\nhttps://blog.virustotal.com/2020/10/tracing-fresh-ryuk-campaigns-itw.html\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://blog.virustotal.com/2020/10/tracing-fresh-ryuk-campaigns-itw.html" ], "report_names": [ "tracing-fresh-ryuk-campaigns-itw.html" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775433980, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/340609470f95295541632875ceb7635330e064da.pdf", "text": "https://archive.orkl.eu/340609470f95295541632875ceb7635330e064da.txt", "img": "https://archive.orkl.eu/340609470f95295541632875ceb7635330e064da.jpg" } }