What ransomware negotiation actually looks like

Somebody has sent you a link to a chat window, and the first instinct is to work out what to type.

The order is wrong. Before a word is sent there is a question that decides whether there is anything to discuss at all, and it is not about money. This page is what a negotiation consists of, step by step, so that you can tell what is being decided — whether the channel is being run on your behalf or you are looking at one for the first time.

It is a different subject from whether to pay. That decision, and the five findings it rests on — four of them establishable inside forty-eight hours — are set out separately.

Before anything is said: who they are, and what that makes the payment

There is a question about the counterparty's identity that sits apart from the ransom. The instrument that frames it is American, and it should be read as American.

The U.S. Department of the Treasury's Office of Foreign Assets Control (OFAC) published an Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments dated 21 September 2021, which by its own footnote 2 updates and supersedes an advisory of 1 October 2020. The advisory explains the prohibitions in the International Emergency Economic Powers Act (IEEPA) and the Trading with the Enemy Act, and footnote 1 tells the reader to "see the legally binding provisions cited for relevant legal authorities."

The passage that names firms like ours, in terms:

"Companies that facilitate ransomware payments to cyber actors on behalf of victims, including financial institutions, cyber insurance firms, and companies involved in digital forensics and incident response, not only encourage future ransomware payment demands but also may risk violating OFAC regulations."

The prohibition it explains:

"Under the authority of the International Emergency Economic Powers Act (IEEPA) or the Trading with the Enemy Act (TWEA), U.S. persons are generally prohibited from engaging in transactions, directly or indirectly, with individuals or entities ('persons') on OFAC's Specially Designated Nationals and Blocked Persons List (SDN List), other blocked persons, and those covered by comprehensive country or region embargoes (e.g., Cuba, the Crimea region of Ukraine, Iran, North Korea, and Syria)."

And the sentence about reach, which is the one that bears on a payment chain with no obvious American leg in it:

"Additionally, any transaction that causes a violation under IEEPA, including a transaction by a non-U.S. person that causes a U.S. person to violate any IEEPA-based sanctions prohibitions, is also prohibited. U.S. persons, wherever located, are also generally prohibited from facilitating actions of non-U.S. persons that could not be directly performed by U.S. persons due to U.S. sanctions regulations."

Settlement is not one act. Acquiring the currency, holding it, moving it and confirming it are separate steps, and each one can involve a party other than you — an exchange, a custodian, a bank. Which parties are in your chain is a fact about your chain, and it is knowable before the transfer rather than after it. The quoted sentence describes transactions and the persons who perform them. Reading it against your own chain is what the screening at the start is for.

OFAC states that its civil penalties rest on strict liability:

"OFAC may impose civil penalties for sanctions violations based on strict liability, meaning that a person subject to U.S. jurisdiction may be held civilly liable even if such person did not know or have reason to know that it was engaging in a transaction that was prohibited under sanctions laws and regulations administered by OFAC."

That is why identification is not a formality performed after the commercial conversation. Under a strict-liability standard, "we asked and they said they were not sanctioned" is not a position.

What OFAC says about companies that engage with ransomware victims — cyber insurance, digital forensics and incident response, and financial services that may process a ransom payment — and the modal is theirs:

"In particular, the sanctions compliance programs of these companies should account for the risk that a ransomware payment may involve an SDN or blocked person, or a comprehensively embargoed jurisdiction."

Two further things from the same document are worth holding before anyone starts drafting messages.

Licensing runs through OFAC, with a presumption of denial. OFAC states that "license applications involving ransomware payments demanded as a result of malicious cyber-enabled activities will continue to be reviewed by OFAC on a case-by-case basis with a presumption of denial."

Where a payment may have a sanctions nexus, OFAC treats a self-initiated report as a mitigating factor.

"In the case of ransomware payments that may have a sanctions nexus, OFAC will consider a company's self-initiated and complete report of a ransomware attack to law enforcement or other relevant U.S. government agencies, such as CISA or the U.S. Department of the Treasury's Office of Cybersecurity and Critical Infrastructure Protection (OCCIP), made as soon as possible after discovery of an attack, to be a voluntary self-disclosure and a significant mitigating factor in determining an appropriate enforcement response."

So the first work in a negotiation is identification, and the output of it is a record. Which group. Which known aliases it has operated under. Which wallet address the demand names. Each of those screened against the OFAC SDN List and against UN and EU listings, before payment is discussed, and written down with the date and the result. The screening is not the last box on a checklist; it is the thing that determines whether the rest of the sequence happens.

Who is actually on the other side

The identification question is harder than reading the name off the ransom note, and the reason is structural.

CISA, the FBI, MS-ISAC and their international partner agencies describe the model in Understanding Ransomware Threat Actors: LockBit (advisory AA23-165A, 14 June 2023):

"A RaaS cybercrime group maintains the functionality of a particular ransomware variant, sells access to that ransomware variant to individuals or groups of operators (often referred to as 'affiliates'), and supports affiliates' deployment of their ransomware in exchange for upfront payment, subscription fees, a cut of profits, or a combination of upfront payment, subscription fees, and a cut of profits."

Read that as an org chart and three roles fall out of it, and one party need not hold all three: whoever builds and maintains the encryptor and the leak infrastructure; whoever bought or rented access and ran the intrusion into your network; and whoever is typing in the chat window. Which of them you are dealing with is a question, not an assumption. The same advisory records that after LockBit's builder leaked in September 2022, "non-LockBit affiliates" were able to deploy LockBit 3.0 — so the branding on a ransom note is evidence about which toolkit was used, and a toolkit can change hands.

Three consequences, and they run through everything below.

What can be agreed depends on who is agreeing. Under the model CISA describes, the variant is maintained by one party and deployed by another. Whether the decryptor behaves correctly on your files is a property of the tool, and the party in the chat may not be the party that built it. Ask which of them you are dealing with before you accept a promise about the tool's behaviour.

Deletion is a commitment about parties you cannot enumerate. Under a model where access to the tooling and the infrastructure is sold, a list of who else holds a copy of what left your network is not something you can obtain or check. A promise about copies is a promise about parties outside the conversation.

What you screen is not the chat window. You screen the group, its known aliases and the wallet — because the sanctions question is about where value lands, and value does not land in a chat window.

Proof of decryption, before anything else moves

After the screening, nothing further in the commercial sequence is worth doing until there is evidence that a working decryptor exists. That evidence has a specific shape.

Demand decryption of files you choose. A file the counterparty nominates demonstrates something about that file. A file you nominate, pulled from a system you nominate, demonstrates something about your estate.

Choose more than one, and choose them apart. Different hosts, different file sizes, different formats — because encryption behaviour can differ by host and by file size, and a decrypted 20 KB text file establishes nothing about a 400 GB database volume.

Choose files whose contents you can independently validate. A document a person can open and read. A record you can check against a value you already hold. A file whose hash you can compare against a backup catalogue entry. "It decrypted" is a claim about the process; "it opened and the contents are right" is a finding.

Send only what you are willing to hand over. The file you nominate goes to the counterparty. Choose accordingly, and do not solve the problem by nominating something worthless — a file with no meaningful content is a file whose correct decryption you cannot check.

What a refusal establishes. A counterparty who will decrypt only files of their own choosing is declining to demonstrate the thing you asked about. A counterparty who will decrypt nothing has answered the question of whether there is a working decryptor available to buy, and the answer removes the reason for the rest of the conversation.

And what a successful proof does not settle. It is evidence about capability at that moment, on those files. It says nothing about how long the tool takes across an estate, what it does to files it fails on, or whether it handles every system class you need back. Those are separate questions, and they belong in the conversation before settlement rather than after it.

What is actually on the table

Price is one item. It is not the only one, and the others determine whether the number means anything.

The proof. Covered above, and it is the item that gives every other item its value.

The timeline. Leak-site countdowns are set by the counterparty, which means they can be moved by the counterparty. Extension is one of the things a channel can ask for. What an extension would be for is finishing the restore test and the exfiltration investigation, rather than deciding without them.

The deletion claim. A deletion promise concerns data held on infrastructure you have no access to, by parties who cannot be enumerated. Verifying it would mean inspecting storage you have no access to. Nothing in the transaction creates that access, which leaves a deletion promise as a statement — and a statement is what a payment against it buys.

The leak-site listing. Removing a listing removes a listing. It is a change to a page on a site the core group runs. It is not a change to the copies.

The proof of the exfiltration itself. A file tree, a sample, a directory listing — evidence that what the counterparty claims to hold is what they hold. A claim of exfiltration is an assertion by a party with an interest in it, in both directions. Your own logs are evidence you control and can date. Pull them before the retention window moves.

The mechanics of the payment. The amount, the currency, the wallet address. These are not administrative details at the end — the address is one of the things that gets screened, and it has to be on the table before the screening can be completed.

What an operator can credibly commit to narrows to a short list once you have read the structure: handing over a key or a decryptor, taking a listing down, and moving a deadline they set. Commitments about the future conduct of the wider population — that nobody comes back, that no copy surfaces — are commitments about parties the counterparty does not control.

Encryption and exfiltration are two events

CISA, MS-ISAC, the NSA and the FBI define the pattern in the #StopRansomware Guide (September 2023):

"Over time, malicious actors have adjusted their ransomware tactics to be more destructive and impactful and have also exfiltrated victim data and pressured victims to pay by threatening to release the stolen data. The application of both tactics is known as 'double extortion.' In some cases, malicious actors may exfiltrate data and threaten to release it as their sole form of extortion without employing ransomware."

Treat them as two events, because they have two different remedies and two different endings.

Encryption is a question about access to your own systems. It ends when the data is back — from a restore, from a public decryptor, or from a purchased one — and the ending is verifiable, because you can open the files.

Exfiltration is a question about copies held somewhere else. A decryptor does nothing to it. Neither does a payment, beyond producing the statement described above. It ends when it ends, which is why it is investigated from your evidence rather than negotiated.

They are separately described in the reporting too. Annexure I to the CERT-In Directions of 28 April 2022 lists twenty types of cyber security incident; item (v) is "Malicious code attacks such as spreading of virus/worm/Trojan/Bots/ Spyware/Ransomware/Cryptominers", and items (xi) Data Breach and (xii) Data Leak describe the other half. Work the list and tick each item that describes the incident in front of you.

The clock does not wait for the channel

Direction (ii) of the same Directions provides:

"Any service provider, intermediary, data centre, body corporate and Government organisation shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents."

Six hours from noticing, or from being brought to notice. That clock runs while the channel is open. Give the filing to somebody who is not in the chat — what goes in it is here — and let the two run in parallel.

Where the decision sits

The pay / do-not-pay decision belongs to the organisation that was attacked. It is not made by a negotiator, it is not made by a responder, and it is not made by the counterparty's countdown.

Our published position, in full, from the ransomware response FAQ:

Should we pay the ransom?

"We strongly advise against paying ransoms as a default position. Payment does not guarantee data recovery, may fund further criminal activity, and can expose your organization to legal complications. We first assess all alternative recovery paths — backup restoration, free decryptors, forensic recovery — before any discussion of ransom payment as a last resort."

And the question underneath it, which is the one that decides whether a channel is needed at all:

Can you recover our encrypted data without paying the ransom?

"In many cases, yes. Recovery depends on the ransomware variant, backup integrity, and available decryption tools. We assess all viable recovery paths including backup restoration, publicly available decryptors for known ransomware families, and forensic data recovery techniques. We provide an honest assessment of recovery probability before you make any decisions."

The short version

• Identify and screen before anything commercial. The group, its known aliases, and the wallet address in the demand — against the OFAC SDN List and UN and EU listings — and record what was checked and when.
• Read the OFAC advisory of 21 September 2021. It is a US Treasury instrument, it names digital forensics and incident response firms in terms, and OFAC states that its civil penalties for sanctions violations rest on strict liability, meaning a person subject to US jurisdiction may be held civilly liable without knowledge.
• Assume roles, not one actor. A ransomware-as-a-service group, an affiliate and the party in the chat can be three different hands, and that governs what can be agreed and by whom.
• Demand proof of decryption on files you choose, from several hosts, at several sizes, whose contents you can validate.
• Negotiate the timeline, not only the price. Time buys the restore test and the exfiltration finding.
• A deletion promise is a statement. Verifying it would need access that does not exist.
• File at hour six regardless. Direction (ii) runs whatever the chat is doing. Give it to somebody who is not in the chat.
• The decision is yours, and our published default is against paying.

If you want us to run it: what we do, and what we check first

We run ransomware negotiations as a full service, including payment facilitation. Sanctions screening is the first step of that service and the condition of every step after it, so the two are described together throughout.

1. We screen before we talk about money. The group, its known aliases, and any wallet address named in the demand are screened against the OFAC SDN List, UN and EU listings, and the check is recorded — what was screened, against what, when, and what came back. This happens before payment is discussed, and the record is yours.

2. We identify the strain, and the screening follows the identification. Our published scope is to "Identify the specific ransomware variant, its known behaviors, and available decryption options." Where identification changes who we think is on the other end, the screening is re-run against the new answer and the new check is recorded alongside the first.

3. We open and run the channel. Contact, message discipline, timeline management, deadline extension requests, and price movement — conducted under the screening position established at step 1, and stopped if the screening changes what it says.

4. We demand and verify proof of decryption. Files you choose, from hosts you choose, validated by opening them — demanded through the channel opened under the step 1 screening position, and stopped if that position changes. This runs alongside our published decryption assessment — "Evaluate whether free decryptors exist, assess backup integrity, and determine the fastest path to data recovery" — because a free decryptor or a working backup ends the commercial conversation before a payment is on the table.

5. If you decide to pay, we handle settlement. Crypto acquisition, transfer, and confirmation — against the wallet address screened at step 1 and re-screened at the point of transfer, with both checks recorded. The pay / do-not-pay decision is yours; we do not make it, and our published default is the FAQ quoted above.

6. We verify decryption after settlement as well as before it. The proof establishes that a decryptor exists; the post-settlement verification establishes whether it works across your estate, on which systems, and where it does not — and its result joins the screening checks recorded at steps 1 and 5. Where recovery is possible it runs on our published scope — "Recover data from backups, decryption tools, or forensic recovery methods to restore business operations" — and, for the exfiltration half, "Continuous scanning of ransomware leak sites, forums, and marketplaces for your organization's data."

7. The screening record is written down. What was screened, against what, when, and what came back — recorded at step 1, re-recorded at step 5, and kept as the contemporaneous record of the check rather than a reconstruction of it.

The screening at step 1 is the condition of the six steps after it: where it says the payment cannot be made, the channel stops there and the recovery work continues on the other paths. Security Brigade has been CERT-In empanelled since 2008. If you are in this now, we answer 24/7 — +91 22 4164 2220.