{ "id": "b634e5f1-d711-4c74-8c7a-e9031c1de266", "created_at": "2026-04-06T01:30:15.478638Z", "updated_at": "2026-04-10T03:29:45.227338Z", "deleted_at": null, "sha1_hash": "e15db924fa4d4c433190aa6c1562a35c94ddfded", "title": "WannaMine v4: Analysis \u0026 Remediation | CrowdStrike", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2984789, "plain_text": "WannaMine v4: Analysis \u0026 Remediation | CrowdStrike\r\nBy Collin Montenegro and Mark Robinson\r\nArchived: 2026-04-06 00:50:48 UTC\r\nAlthough the world of mineware is not new to the security industry, it continues to grow as adversaries develop\r\nnew capabilities to compromise systems and turn them into bots used for mining cryptocurrency. In this blog, we\r\nhope to provide some deeper insight into the world of mineware. We will discuss in-depth one of the most\r\nnotorious mineware malware variants out there, “WannaMine.” Our deep dive will analyze the latest WannaMine\r\nvariant currently being used in the wild, dubbed \"WannaMine v4.0,” and outline how you can successfully\r\nidentify and remediate a WannaMine v4.0 infected host.\r\nCryptojacking and WannaMine\r\nIn essence, cryptojacking is the unauthorized use of a computing device to mine cryptocurrency. It occurs when\r\nadversaries compromise an organization’s systems and use their resources to mine cryptocurrency, freeing them\r\nfrom having to purchase hardware and electricity (more detailed information can be found in previous blogs on\r\ncryptomining and cryptojacking). Many times, this malicious mining occurs without the victim ever realizing it\r\ndue to a lack of security monitoring. As adversaries and cybercriminals searched for better ways to compromise\r\nhosts en masse, the creation of a malware dubbed “WannaMine” was born. WannaMine is a mineware malware\r\nvariant created for the sole purpose of installing and running Monero software on a victim’s system and using its\r\nprocessing power to mine Monero for the adversary. WannaMine plays on the naming convention used for the\r\nnotorious ransomware mentioned at the beginning of the article, WannaCry. This is likely because WannaMine\r\nleverages WannaCry's exploitation code, \"EternalBlue,\" to compromise hosts and propagate the Monero mining\r\nsoftware.\r\nWannaMine v4.0 Analysis and Remediation Overview\r\nLike its predecessors, WannaMine v4.0 leverages the EternalBlue exploit to spread and compromise vulnerable\r\nhosts. Its design is similar to WannaMine v3.0 in that it stores the EternalBlue exploit binaries in a directory\r\nlocated in C:\\Windows; however, the directory in version 4.0 has been renamed \"NetworkDistribution.” Instead of\r\nleveraging a single hard-coded service name like WannaMine v3.0, version 4.0 will randomly generate a .dll and\r\nservice name based on a list of hard-coded strings. It does this in order to maintain persistence on the host. We will\r\nstart with a quick high-level overview of the remediation steps that are needed, and then follow with a more\r\ndetailed step-by-step walk-through. The remediation of WannaMine v4.0 can be broken into the following three\r\nsteps:\r\n1. Killing the malicious processes (newly spawned or injected)\r\n2. Locating and removing the persistence mechanism (e.g., service)\r\n3. Removing artifacts (e.g., NetworkDistribution).\r\nThe following offers details on each step:\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 1 of 19\n\nWannaMine v4.0 Step-by-Step Remediation\r\nNote: there are 2 scenarios. Pre-infection (CrowdStrike Falcon®® is already installed and preventions are on)\r\nand post-infection detections where Falcon has been installed on the client’s endpoints after infection, therefore\r\nblocking it. In some of the examples shown below we have turned on DETECTIONS ONLY and PREVENTIONS\r\noff for illustrative purposes.\r\nSTEP 1. Killing the Malicious svchost.exe and dllhostex.exe Processes\r\nAs you can see in Figure 1 and 2. , Falcon will immediately block the launch of WannaMine’s main XMRig\r\nmining module (dllhostex.exe) and then quarantine the binary. Since the process has been killed and the binary\r\nremoved, we must find the svchost.exe process that is being used to run the malicious service and kill it. Using\r\nFalcon’s process explorer, you can see that the parent process of dllhostex.exe is svchost.exe.\r\nFigure 1. Process execution tree indicating svchost.exe as the parent process of dllhostex.exe\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 2 of 19\n\nFigure 2. Further detail of specific process information within the UIBy looking over the process details within\r\nFalcon, we can quickly grab the process ID associated with the svchost.exe that is running the malicious\r\nWannaMine DLL.\r\nFigure 3-4. Process execution tree provides process ID information\r\nFrom there, we can query that specific svchost.exe process, via the process ID obtained from the Falcon UI, in\r\norder to gather the service group name being used for the malicious service, in this case the netsvcs service group.\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 3 of 19\n\nFigure 5. PowerShell query to output svchost service group name. Note: This must be run within the \"EDIT \u0026\r\nRUN SCRIPTS\" tab\r\nNote: Depending on whether the SVCHOST is grouped (Microsoft refactored the way SVCHOST groups services\r\nin Windows 10 1703; read about that here) or if it is a single process, the removal process will vary. Windows 10,\r\nby default, will spawn an individual SVCHOST process per module but Windows 7 will group. Killing the grouped\r\nPID is not an option here as we want to minimize downtime for the clients we work with.Review Appendix A.3 for\r\nfurther insight into this grouping. To be more specific, we can actually query the SVCHOST process using\r\n“tasklist” to output the service name associated with it, which happens to be the exact name of the malicious\r\nWannaMine DLL.\r\nFigure 6. Tasklist output to display associated service name. Note: This must be run within the \"EDIT \u0026 RUN\r\nSCRIPTS\" tab.\r\nAs an extra step, you can also query the registry key that SVCHOST based on the service group name of\r\n“netsvcs” found in the image above. From the output below, we can see the “MicrosoftNetBIOSManager” DLL\r\nmodule that was added to the netsvcs service group. This has the same name we found previously, using the\r\ncommands above.\r\nFigure 7. Registry query output showing newly added malicious dll module name\r\nBased on that information we can pivot and check the registry key where Windows services are stored to see if we\r\nfind an associated service named “MicrosoftNetBIOSManager.” As expected, we see that there is such an entry.\r\nLooking at the values stored within the Parameters key we find the exact path to the malicious .dll:\r\nFigure 8. Registry query command to output path location to .dll on disk\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 4 of 19\n\nFigure 9. Output of registry query command showing path location to the malicious .dllTo confirm that this is the\r\nmalicious DLL we are looking for, we can calculate the hash for the binary\r\nFigure 10. Built-in RTR command to gather filehash information.\r\nFigure 11. Output of the filehash command for the malicious .dll\r\nOnce we have the hash of the DLL, we notice that this has not been seen in VirusTotal, which is abnormal for a\r\nlegitimate Windows dll stored in the System32 or SysWow64 directories. In our lab environment, we infected a\r\nWindows 10 host at a specific date and time. Once infected, we inspected the creation timestamp of the malicious\r\nDLL. The time stamp provided was invalid, stating the DLL was created months prior to the initial infection. This\r\nindicated timestomping techniques had been used.\r\nFigure 12-13. Shows a creation date that pre-dated the in-lab installation\r\nA clearer indication is seen on a Windows 7 host where the timestomping goes back to 2009. (See A.2\r\nTimestomping Example.)\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 5 of 19\n\nFigure 14. Another image showing timestomping being used on a Windows 7 host\r\nReviewing the compiler timestamp for the binary, you can see that it was created recently — in 2019 and not\r\n2009.\r\n Figure 15.\r\nReviewing compiler timestamp information that proves timestomping is in fact being used\r\nAnother method to highlight the malicious dll being loaded by SVCHOST comes from outlier analysis (Figure\r\n16.). We see the hard-coded path for MicrosoftNetBIOSManager (Figure 17.) which is odd and adds context to the\r\nabove indicating this isn’t native to the OS.\r\nFigure 16. Registry query used to show further outlier information indicating the difference between the known\r\nlegitimate and malicious .dll. Note: This must be run within the \"EDIT \u0026 RUN SCRIPTS\" tab.\r\nAn example of the many ServiceDLL fields and what they look like before filtering again on the hard-coded path\r\nC:\\Windows\\System32\\ as opposed to %systemroot%.\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 6 of 19\n\nFigure 17. Output of the registry command indicating the differences\r\nNow that we have confirmed the SVCHOST process is indeed the one associated with the malicious WannaMine\r\nservice, let’s kill the process. Gracefully stopping the service will end the process.\r\n Figure 18. PowerShell\r\ncommand to stop the malicious service. Note: This must be run within the \"EDIT \u0026 RUN SCRIPTS\" tab.\r\nSTEP 2. Removing the Persistence\r\nWhile discovering and killing the svchost.exe process being used to launch the WannaMine service, we found and\r\nconfirmed the service name being used for persistence. Now we remove the service so WannaMine v4.0 no longer\r\nhas persistence in place.\r\nFigure 19. Powershell command to remove the service after it has been stopped. Note: This must be run within the\r\n\"EDIT \u0026 RUN SCRIPTS\" tab.\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 7 of 19\n\nFigure 20. Output provided after running the service removal command\r\nJust like that, we have removed the malicious service and relinquished WannaMine v4.0’s persistence!\r\nSTEP 3. Removing Remaining Artifacts\r\nNow that we have killed the SVCHOST process and removed the persistence, it’s time to clean up and remove the\r\nremaining artifacts. Based on our research, WannaMine v4.0 has a few specific artifacts that it places on the host.\r\nThe first one is the NetworkDistribution folder located in C:\\Windows. This folder contains all of the Equation\r\nGroup binaries (e.g., EternalBlue, Double Pulsar, etc.) and needs to be removed.\r\nFigure 21. Depicts the folder named “NetworkDistribution” and some of its contents\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 8 of 19\n\nFigure 22. Command used to remove the\r\nentire directory\r\nThe next artifact to remove is the malicious DLL that we discovered in step one. This is located in\r\nC:\\Windows\\System32.\r\nFigure 23. Built-in RTR command used to remove the malicious .dll\r\nNext, we have the dllhostex.exe that is the binary that WannaMine v4.0 uses to run the XMRig miner module. As\r\nseen Figure 1, Falcon quarantines this binary; however, if it was not quarantined you can find it in\r\nC:\\Windows\\System32.\r\nFigure 24. Built-in RTR command used to remove the XMRig miner module binary\r\nLastly, a registry entry that contains the descriptive text for the service.\r\nFigure 25. PowerShell command to remove the remaining registry artifact. Note: This must be run within the\r\n\"EDIT \u0026 RUN SCRIPTS\" tab.\r\nCompletion\r\nCongratulations! If you followed the above steps, you have successfully discovered and remediated the pesky\r\nWannaMine v4.0 malware.\r\nPowerShell Enumeration Script\r\nIn an effort to automate the remediation processing, we can leverage the RTR RUNSCRIPT feature of the Falcon\r\nagent to easily create and save re-runnable scripts to help identify and triage systems ready for remediation. Using\r\na “query first then kill” methodology, you can confirm a host is infected prior to running any remediation kill\r\nscripts. This helps our analysts quickly remediate systems at scale.\r\nRemediation RTR Runscript Code\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 9 of 19\n\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 10 of 19\n\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 11 of 19\n\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 12 of 19\n\nFigure 26.\r\nImage of the full PowerShell runscript\r\nRTR Runscript Output Example\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 13 of 19\n\nFigure 27. Output provided by the PowerShell runscript listing the artifacts found on the host\r\nFigure 28. Output provided by the PowerShell runscript listing the removal commands that you can use to\r\ncompletely remediate WannaMine v4.0\r\nRecommendations\r\nGain advance visibility across your endpoints with an endpoint detection and response (EDR) solution such\r\nas the CrowdStrike® Falcon platform. Turn on next-gen antivirus (NGAV) preventative measures to stop\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 14 of 19\n\nmalware.\r\nKeep systems up to date: Patch for MS17-010 to stop EternalBlue exploitation.\r\nSegregate the network where possible to limit lateral movement.\r\nMonitor / filter / block at the network level for known coinminer sites.\r\nDetect network scanning. Contain unapproved hosts as fast as you can.\r\nCrowdStrike Solutions and Services\r\nCrowdStrike provides a wide range of solutions and services to help you identify and protect your environment\r\nfrom the latest threats. The following is information on some of these solutions and services. CrowdStrike\r\nprovides the technology and expertise you need to combat today’s advanced threats, including WannaMine v4.0.\r\nFalcon Sandbox\r\nCrowdStrike Falcon® Sandbox™ performs deep analysis of evasive and unknown threats, enriches the results\r\nwith threat intelligence, and delivers actionable indicators of compromise (IOCs), enabling your security team to\r\nbetter understand sophisticated malware attacks and strengthen their defenses. Learn more about Falcon Sandbox.\r\nTry it free by visiting this website.\r\nFalcon Complete\r\nCrowdStrike Falcon Complete™ saves time and resources, and reduces cost by bringing customers to the highest\r\nlevel of endpoint security by combining CrowdStrike’s best protection technologies with the people and processes\r\nnecessary to provide a total hands-off, turnkey approach to endpoint protection. The CrowdStrike Falcon®\r\nComplete Team reduces the time needed to remediate endpoints by providing the skills and expertise required to\r\ntake proper action. The Team does the remediation for you, eliminating the arduous task of reimaging the\r\nendpoints and reducing the risk of a breach. The Falcon Complete Team has been following the numerous\r\niterations of the WannaMine malware and are well-versed in the removal of the latest variant, WannaMine v4.\r\nThis removal is done by taking a surgical approach and removing the many artifacts that WannaMine scatters on\r\nthe host, all without having to reimage the system. For further details regarding CrowdStrike’s Falcon Complete,\r\nvisit the Falcon Complete webpage.\r\nCROWDSTRIKE FALCON® INTELLIGENCE\r\nCrowdStrike CROWDSTRIKE FALCON® INTELLIGENCE™ automates the threat analysis process and\r\ndelivers actionable intelligence and custom IOCs specifically tailored for the threats encountered on your\r\nendpoints. With this level of automation, you can stop picking and choosing which threats to analyze and start\r\nanalyzing all threats. In addition, with CrowdStrike Falcon® Intelligence Premium, you have the ability to\r\nescalate malware to a CrowdStrike expert for further research or a second opinion. Learn more about CrowdStrike\r\nFalcon® Intelligence threat intelligence by visiting the webpage.\r\nAPPENDICES\r\nA.1 LATERAL MOVEMENT\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 15 of 19\n\nPlease Note: In Figure 29, Falcon is configured to DETECT ONLY. Prevention was disabled to outline the lateral\r\nmovement. If Falcon was in prevention mode, it would have prevented the post exploitation activity. On patient\r\nzero, the injected process, SearchIndexer.exe begins scanning the local subnet for EternalBlue vulnerable hosts.\r\nFigure 29. Process execution information within the Falcon UI indicating network lateral movement\r\nNewly infected victim (Figure 30) has been found and exploited by EternalBlue. Notice LSASS process dropping\r\nout a new persistence SVCHOST service and newly generated dll.\r\nFigure 30. Process execution information within the Falcon UI showing signs of a newly infected victim that was\r\nexploited via Eternal Blue\r\nA.2 TIMESTOMPING EXAMPLE\r\nAgain, timestomping on the dll has occurred — even more notably than previously on our patient zero — to\r\nfurther evade detection, setting it back into 2009.\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 16 of 19\n\nFigure 31. Runscript output indicating timestomping being used\r\nFigure 32. Native RTR output indicating timestomping being used\r\n Figure\r\n33. Image showing compiler timestamp for the binary\r\nA.3 WINDOWS 7 SVCHOST GROUPING EXAMPLE\r\nWith a Windows 7 host, the SVCHOST grouping is also important: You should not kill off the PID as this would\r\ndisrupt the OS and could cause instability with the host.\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 17 of 19\n\nFigure 34.\r\nImage showing numerous services grouped with this specific svchost process\r\nBy stopping the service gracefully, we can see it no longer shows under PID 996.\r\n Figure 35.\r\nImage showing the malicious service has been removed from the process without killing other legitimate system\r\nservices\r\nAdditional Resources\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 18 of 19\n\nFind out how CrowdStrike can help your organization answer its most important security questions: Visit\r\nthe CrowdStrike Services webpage.\r\nLearn how any size organization can achieve optimal security with Falcon Complete by visiting the\r\nproduct webpage.\r\nLearn more about CrowdStrike Falcon® Intelligence threat intelligence by visiting the webpage.\r\nLearn about CrowdStrike’s comprehensive next-gen endpoint protection platform by visiting the Falcon\r\nproducts webpage.\r\nTest CrowdStrike next-gen AV for yourself: Start your free trial of Falcon Prevent™.\r\nSource: https://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nhttps://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/\r\nPage 19 of 19", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.crowdstrike.com/blog/weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare/" ], "report_names": [ "weeding-out-wannamine-v4-0-analyzing-and-remediating-this-mineware-nightmare" ], "threat_actors": [ { "id": "b740943a-da51-4133-855b-df29822531ea", "created_at": "2022-10-25T15:50:23.604126Z", "updated_at": "2026-04-10T02:00:05.259593Z", "deleted_at": null, "main_name": "Equation", "aliases": [ "Equation" ], "source_name": "MITRE:Equation", "tools": null, "source_id": "MITRE", "reports": null }, { "id": "08623296-52be-4977-8622-50efda44e9cc", "created_at": "2023-01-06T13:46:38.549387Z", "updated_at": "2026-04-10T02:00:03.020003Z", "deleted_at": null, "main_name": "Equation Group", "aliases": [ "Tilded Team", "EQGRP", "G0020" ], "source_name": "MISPGALAXY:Equation Group", "tools": [ "TripleFantasy", "GrayFish", "EquationLaser", "EquationDrug", "DoubleFantasy" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "2d9fbbd7-e4c3-40e5-b751-27af27c8610b", "created_at": "2024-05-01T02:03:08.144214Z", "updated_at": "2026-04-10T02:00:03.674763Z", "deleted_at": null, "main_name": "PLATINUM COLONY", "aliases": [ "Equation Group " ], "source_name": "Secureworks:PLATINUM COLONY", "tools": [ "DoubleFantasy", "EquationDrug", "EquationLaser", "Fanny", "GrayFish", "TripleFantasy" ], "source_id": "Secureworks", "reports": null }, { "id": "e0fed6e6-a593-4041-80ef-694261825937", "created_at": "2022-10-25T16:07:23.593572Z", "updated_at": "2026-04-10T02:00:04.680752Z", "deleted_at": null, "main_name": "Equation Group", "aliases": [ "APT-C-40", "G0020", "Platinum Colony", "Tilded Team" ], "source_name": "ETDA:Equation Group", "tools": [ "Bvp47", "DEMENTIAWHEEL", "DOUBLEFANTASY", "DanderSpritz", "DarkPulsar", "DoubleFantasy", "DoubleFeature", "DoublePulsar", "Duqu", "EQUATIONDRUG", "EQUATIONLASER", "EQUESTRE", "Flamer", "GRAYFISH", "GROK", "OddJob", "Plexor", "Prax", "Regin", "Skywiper", "TRIPLEFANTASY", "Tilded", "UNITEDRAKE", "WarriorPride", "sKyWIper" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775439015, "ts_updated_at": 1775791785, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/e15db924fa4d4c433190aa6c1562a35c94ddfded.pdf", "text": "https://archive.orkl.eu/e15db924fa4d4c433190aa6c1562a35c94ddfded.txt", "img": "https://archive.orkl.eu/e15db924fa4d4c433190aa6c1562a35c94ddfded.jpg" } }