Ransomware negotiation is one of the least understood aspects of incident response — partly because practitioners rarely discuss specifics publicly, and partly because the popular image of it (a tense cyber standoff with a hooded hacker) bears little resemblance to what actually happens.
In practice, ransomware negotiation is methodical, conducted largely via web-based chat portals, and governed by recognisable commercial logic on both sides. Understanding the process — and the leverage points within it — is essential context for any organisation that may face this situation.
The Decision to Engage
The decision to open negotiations does not imply a decision to pay. Engaging with a threat actor buys time, provides intelligence, and keeps options open. Not engaging closes options and, in some cases, accelerates data publication timelines.
Organisations sometimes avoid initiating contact because they believe it signals willingness to pay. In practice, the opposite framing is more effective — early contact allows you to control the pace of the conversation while your forensic investigation and recovery assessment proceeds in parallel. Silence does not improve your position.
The decision to engage should involve legal counsel from the outset. Solicitor-client privilege may apply to communications in the context of anticipated litigation, and structuring engagement correctly from the start preserves that protection.
The Portal and First Contact
Most ransomware groups operate Tor-based negotiation portals — dedicated .onion websites accessible via a unique victim ID provided in the ransom note. The portal typically contains a chat interface, a countdown timer showing when data publication or price escalation occurs, and a ransom demand in cryptocurrency (almost universally Bitcoin or Monero).
First contact from the victim side should be neutral and information-gathering: acknowledging receipt, requesting proof that decryption is possible, and — critically — not volunteering any financial information. The first message sets the tone for everything that follows.
Threat actors communicate in varying quality of English (most groups are not English-speaking), respond at varying speeds, and have different levels of negotiation sophistication depending on the group and affiliate involved. Reading the counter-party correctly is a skill that develops through volume of experience.
Proof of Life: The Decryption Test
Before any payment discussion proceeds meaningfully, you need evidence that decryption is viable. This is called proof of life — the threat actor decrypts a small number of sample files to demonstrate that the decryptor works and that they hold the key.
Proof of life serves multiple purposes:
- Confirms the decryptor is functional (not all are)
- Confirms the threat actor actually holds the key (rather than bluffing)
- Provides a sample of the decryptor for technical analysis of quality and reliability
- Establishes a working relationship and communication baseline
Requesting proof of life is standard and expected. Threat actors who refuse to provide it are a significant red flag — it may indicate the decryptor is non-functional, that the group has fragmented and lost access to keys, or that the operation is fraudulent.
The Counter-Offer
Ransomware demands are almost always opening positions, not final prices. Groups calibrate initial demands based on estimated victim revenue and what they believe the market will bear, but they expect negotiation. Reductions of 40–70% from initial demands are common where negotiation is conducted professionally.
The counter-offer strategy matters significantly:
- First counter-offer too high signals willingness to pay close to the demand — anchoring the negotiation unfavourably
- First counter-offer too low can antagonise and cause the group to disengage or accelerate timelines
- Pace matters — moving too quickly signals urgency and strong desire to pay; deliberate pacing within timer constraints maintains leverage
- Stated rationale matters — explaining why you cannot pay the full demand (cyber insurance sublimits, business revenue, inability to authorise large transfers quickly) is more effective than simply offering less
These are not arbitrary tactics. Threat actors conduct many negotiations simultaneously and are experienced in reading victim behaviour. A professional negotiator brings pattern recognition from previous engagements with the same group — knowing which arguments land, which claims are accepted, and what floor price a particular group typically accepts.
The Countdown Timer
Most portals display a countdown to data publication or price escalation. These timers create pressure that is partly real and partly theatrical. Groups do publish data when timers expire — but they also extend timers when active negotiations are in progress, because payment is preferable to publication (which generates law enforcement attention without generating revenue).
Timer extensions can typically be requested once negotiation is underway. They are usually granted if the victim is engaging in good faith and the conversation is progressing. Requesting extensions without demonstrating progress is less effective.
The timer also serves an intelligence function — its deadline gives you a forcing function for internal decision-making that can actually be useful in organisations where decision authority is slow to converge.
Sanctions Screening
Before any payment is made — and ideally before negotiations progress beyond initial contact — sanctions screening must occur. OFSI maintains a list of sanctioned individuals and entities that includes named ransomware groups and their affiliates. Paying a sanctioned party is a criminal offence regardless of whether you knew they were sanctioned.
Attribution of ransomware to specific sanctioned groups is not always clear-cut, particularly where groups have rebranded or where affiliates operate across multiple RaaS platforms. Professional negotiators maintain current threat actor intelligence and can conduct or commission attribution analysis to assess sanctions risk before payment proceeds.
This is not optional. The OFSI enforcement posture has hardened, and being a victim does not automatically provide legal cover for sanctions breaches.
When Not to Pay — and When to Walk Away
There are circumstances where payment is not appropriate regardless of recovery considerations:
- The threat actor is sanctioned and attribution is clear
- The decryptor is known to be non-functional or to cause data corruption
- Reliable backups exist and recovery without payment is viable within acceptable timelines
- Payment would require authorisation from a regulator or government body that has not been obtained
Walking away from negotiations — formally or by ceasing communication — is sometimes the right outcome. It should be a deliberate decision made with full understanding of consequences (likely data publication) rather than an accidental outcome of poor communication management.
Post-Payment: What Happens Next
Upon payment confirmation, most groups provide a decryptor and decryption key via the portal. The decryptor is then analysed technically before being deployed — running an unknown executable from a criminal organisation across your production environment without analysis first is a significant additional risk.
Decryption is not instant. Large environments with millions of encrypted files can take days to decrypt, even with functional tooling. Planning for decryption time as part of your overall recovery timeline is important.
Post-payment, continue to monitor leak sites for your data. The commitment to delete exfiltrated data is unenforceable, and publication after payment — while relatively uncommon — does happen.
Binary Response conducts ransomware negotiations as part of our incident response practice. We bring active intelligence on threat actor behaviour, sanctions screening capability, and negotiation experience across all major groups. If you are in an active incident, contact us immediately at enquiries@binary-response.com.