derp.ca - we like the internet.
Tranium: a wiper that every vendor calls ransomware
This is a plain-language briefing. Read the full technical analysis →
Tranium overwrites the MBR (master boot record) on three physical drives, corrupts 30+ system files, and then encrypts your data with AES. In that order. The encryption happens after the machine is already destroyed. The source file is named wiper.go. There are no wallet addresses, no contact email, no Tor payment page. Every AV vendor that detects it -- Kaspersky, Microsoft, huorong -- calls it ransomware. It is not ransomware.
We reversed the full binary. It's a single Go file, 1,037 lines, compiled from a Downloads folder on a machine named "Admin." 29 obfuscated functions, all mapped. The author named it after Tranium, an American YouTuber with 1.3 million subscribers who tests viruses on camera. The wallpaper it sets on the victim's desktop is a selfie of the YouTuber. The greeting in the code reads "Hello Tranium." We cover the complete function-by-function analysis in our research post.
Kaspersky detects it as VHO:Trojan-Ransom.Win32.Agent.gen. Microsoft calls it Ransom:Win32/Genasom. These are generic signatures. No vendor identifies it as a wiper or assigns a family name. 9 of 76 vendors detect it at all.
The encryption is decorative
This is the detail that matters most. Tranium destroys the MBR and corrupts the boot chain, the registry hives, and the kernel before it starts encrypting files. By the time the encryption goroutines spin up, the machine can no longer boot.
The encryption itself is real. AES-CBC with a random key from the OS, stored via Windows DPAPI (Data Protection API). The binary even links decryption routines. In theory, the key could be recovered if the user profile were intact. In practice, the five registry hives that DPAPI depends on -- SAM, SYSTEM, SOFTWARE, SECURITY, DEFAULT -- are among the files it corrupts. The encryption key is locked inside a vault that has already been destroyed.
This is what makes the ransomware classification wrong. Ransomware needs a recovery path, even if the operator never intends to honour it. Tranium has none. The destruction is ordered so that recovery is impossible before the encryption even starts.
10 persistence mechanisms for a binary that destroys the machine
This is an unusual amount of persistence for something that wipes the system. Tranium installs itself 10 different ways. Registry Run/RunOnce keys in four locations. A startup folder copy. Three scheduled tasks that recreate each other if you delete one. A Windows service. A BootExecute entry that runs before Windows loads. And an IFEO debugger hijack on five accessibility tools.
The IFEO hijack is the interesting one. It replaces the debugger entry for Sticky Keys, the on-screen keyboard, Magnifier, Narrator, and Utility Manager. Anyone who presses Shift five times at the Windows lock screen, or clicks the accessibility button, gets Tranium instead of the expected tool.
The scheduled task setup uses a nesting technique. Three tasks with different names. The outer one creates the middle one, the middle creates the inner one, and the inner one runs the payload every minute with SYSTEM privileges. Delete one and the others bring it back. For a wiper, this level of redundancy is unusual. Most wipers run once and don't care about surviving a reboot. This one wants to make sure it stays around.
The lockdown leaves nothing to work with
Before the destruction begins, Tranium disables every tool a user might reach for: Task Manager, regedit, cmd, Control Panel, Run dialog, search, folder options, shutdown, log off, and right-click menus. 16+ policies, all set via the registry.
It also disables Windows Defender (four separate policy values), turns off UAC entirely, and removes the ability to lock the workstation or change the password. The fodhelper UAC (User Account Control) bypass elevates privileges silently through a technique that's been public since 2017 but still works on current Windows.
After the lockdown, it hides the taskbar. Then it downloads a wallpaper and an audio file from the internet, sets the wallpaper to the YouTuber's selfie, and plays 2.4 minutes of audio through the speakers. The ransom dialog is a custom window that displays the downloaded image. There are no text rendering functions in the binary. The "ransom note" is just a picture.
The final step: forced blue screen
After everything else runs -- encryption, MBR overwrite, system file corruption, lockdown -- Tranium triggers a BSOD (Blue Screen of Death) via NtRaiseHardError. The machine crashes. It will not come back up.
The boot chain (bootmgr, winload.exe, kernel, HAL) is already corrupted. The registry hives are corrupted. The filesystem drivers (ntfs.sys, fastfat.sys) are corrupted. Even if you pulled the disk and mounted it elsewhere, the user data is AES-encrypted. The key was stored via DPAPI, whose backing files no longer exist.
What this tells us
Tranium is a single build from a single author, compiled from a Downloads folder. No related samples exist on any platform we searched. The infrastructure is a mix of one custom domain (autism.lat behind Cloudflare) and three generic file hosting services used as backups. There is no C2 server -- just URLs that serve the wallpaper and audio.
The misclassification pattern is worth noting. Every vendor that detects this binary flags it as ransomware because it encrypts files. None of them account for the execution order, the MBR overwrite, the system file destruction, or the absence of any payment infrastructure. The distinction matters for incident response. If you're responding to "ransomware," you're thinking about negotiation, key recovery, backup restoration. None of those apply here. The machine is gone.
We published a YARA rule (Tranium_Wiper) on GitHub (opens in new tab). For the full technical analysis, see Tranium wiper: static analysis of a Go binary.