> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Fake Decryption Tools Masked $11M Markup in Ransomware Recovery Scheme - URL: https://f4n6.co.uk/security-feed/fake-decryption-tools-masked-11m-markup-in-ransomware-recovery-scheme/ - Published: 2026-10-08T10:04:16.000Z - Updated: 2026-10-08T10:04:16.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary Zohar Pinhasi, 50, owner of the US and Israeli firm MonsterCloud and also known as "Zack Silver" and "Zack Green", appeared in a New York court on wire fraud and wire fraud conspiracy charges. The indictment alleges he marketed a ransomware recovery service that claimed to decrypt victim data without paying attackers, while in fact paying ransomware groups for decryption keys and billing clients a large markup. In one cited instance he paid a ransomware affiliate roughly $8,200 and charged the client roughly $150,000; across the scheme he allegedly paid over $8 million in ransoms and charged clients over $19 million. No CVE, exploitation state or technical indicator is present in this item, so the risk to EMEA financial services is third-party and procurement risk, not a software vulnerability: firms that outsource ransomware recovery to an external negotiator or "decryption" vendor may be paying a concealed ransom and misreporting it. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 28: ICT third-party risk, general principles | A recovery vendor (MonsterCloud) was contracted to restore client data after ransomware, and the indictment alleges the vendor paid the attackers without the client's knowledge. | Firms using external ransomware recovery or negotiation vendors must be able to evidence what that vendor actually does on their behalf, including whether a ransom is paid. Contractual and oversight controls over the vendor are engaged. | | DORA Art. 30: key contractual provisions with ICT third-party providers | The alleged conduct turned on the vendor's own claims about its recovery method, which the client could not verify. | Contracts with recovery/negotiation providers should specify the recovery method, prohibit undisclosed ransom payments, and grant audit and termination rights. | | NIS2 Art. 21(2)(d): supply chain security measures | The same vendor relationship is the vector by which the client's incident response was subverted. | Entities in scope must treat ransomware recovery providers as part of the supply chain and assess the security of that relationship. | No DORA Art. 17, 18, 19, 24 or 29 obligation and no NIS2 Art. 23 or UK NIS 2018 duty is directly engaged by this item: the source describes a fraud prosecution, not an ICT incident at a reporting entity, and gives no incident classification, reporting timeline or testing fact to trigger those articles. ## 3\. Technical analysis & attack chain This is a fraud case, not a malware campaign. The source provides no malware family, no exploited vulnerability, no CVE and no technical indicator. What follows is the alleged operational sequence as described in the indictment, and it is single-sourced to SecurityWeek's report of the charges. 1. A victim organisation suffers a ransomware infection and its data is encrypted. 2. The victim engages MonsterCloud, which presents itself as able to recover the data without paying the attackers. 3. Pinhasi allegedly tells the victim not to pay the attackers, and claims MonsterCloud uses proprietary tools and advanced decryption techniques to restore the data. 4. Instead, Pinhasi allegedly contacts the ransomware group that hit the client and pays a ransom to obtain the decryption key. 5. He then uses that key to restore the victim's data and charges the victim a fee far above the ransom he paid. In the one instance detailed, an approximately $8,200 payment to a ransomware affiliate was billed to the client at approximately $150,000. 6. Across the scheme as charged, he allegedly paid over $8 million in ransoms and charged clients over $19 million, a difference of roughly $11 million. The mechanics that matter to a defender are the concealment and the misrepresentation, not any tooling. The victim is told no ransom was paid when one allegedly was, which means the victim's own incident record, its regulatory notifications and its sanctions and anti-money-laundering exposure may all rest on a false premise. The source does not name the ransomware groups involved, does not describe how the ransom payments were made or routed, and does not state whether any victim was itself a financial services firm. Those gaps are not filled here. Attribution: no actor is named in this item and no MITRE ATT&CK profile applies. The only named individual is the defendant, and the charges are allegations that have not been proven. ## 4\. Mitigation & containment This item implicates process controls around incident response and vendor management, not technical containment. There is no patch and no indicator to block. P1 (within 24h) - If you have an active ransomware incident and an external recovery or negotiation vendor is engaged, establish in writing whether a ransom has been or will be paid, to whom, and in what amount. Do not accept the vendor's assurance that no payment occurred without documentary evidence. - Check whether any current or recent incident was handled by MonsterCloud or by an entity trading as "Zack Silver" or "Zack Green". If so, treat the incident record as unreliable and re-verify what was actually paid and to whom. P2 (within 72h) - Review contracts with ransomware negotiation and recovery providers against DORA Art. 30 expectations: the recovery method, an explicit prohibition on undisclosed ransom payments, audit rights, and termination rights. - Where a ransom was paid through a vendor, review the payment for sanctions exposure and confirm your incident notifications to regulators and, where relevant, law enforcement reflect what actually happened. P3 (within 7 days) - Add a verification step to your incident response plan: any claim of "decryption without payment" from a third party must be corroborated before it is relied on in a regulatory notification. - Assess concentration risk where a single recovery vendor handles multiple incidents across your estate, consistent with DORA Art. 29. ## 5\. Indicators of compromise No indicators of compromise available in the source material. The source names no hashes, domains, IP addresses, file paths, registry keys or malware artefacts. The only named entities are the defendant, his aliases and his company, which are not machine-pivotable indicators. Behavioural indicators | behaviour | where to observe | confidence | | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------ | | Recovery vendor claims decryption without payment, then restores data after a delay consistent with ransom negotiation | Vendor communications, incident timeline, payment records | Single-sourced; verify before acting | | Client billed far above the cost the vendor actually incurred to obtain a key | Vendor invoices, procurement and finance records | Single-sourced; verify before acting | | Ransom payment made by a third party on the victim's behalf without the victim's knowledge | Payment records, blockchain tracing where applicable, vendor disclosures | Single-sourced; verify before acting | ## 6\. Detection Insufficient indicators to author detection rules. The source contains no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file names or paths, registry keys, ransom-note text or hard-coded values. The only artefacts are the names of the defendant, his aliases and his company, which are not artefacts of a threat and would produce rules that detect reporting about the case rather than malicious activity. ## 7\. Sources - SecurityWeek, "Fake Decryption Tools Masked $11M Markup in Ransomware Recovery Scheme", https://www.securityweek.com/fake-decryption-tools-masked-11m-markup-in-ransomware-recovery-scheme/, 2026-10-08. This is the only source for this item. All facts in this advisory are single-sourced to that report of the indictment, and the underlying charges are allegations. ## 8\. Adverse Trace position We assess this as a third-party and procurement risk item for EMEA financial services, not a technical threat. There is no CVE, no exploitation state and no indicator to act on, and we have not assigned a CVSS score because none applies. The exposure for our clients is that a ransomware recovery vendor can pay an attacker on your behalf without your knowledge, which corrupts your incident record, your regulatory notifications and your sanctions position. We will monitor for the outcome of the prosecution and for any named ransomware groups or victim sectors, and we will issue a follow-up if the case identifies specific vendors, payment channels or affected institutions. Clients with an active incident and an external recovery vendor should complete the P1 verification step above before filing any notification. --- [Read the original source →](https://www.securityweek.com/fake-decryption-tools-masked-11m-markup-in-ransomware-recovery-scheme/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*