Ransomware

IronChain ransomware destroys files even if you pay

By Yaali. October 12, 2026, 6 min read, Ransomware, Threat intel, Resilience.

IronChain throws away the keys it would need to decrypt. Why a ransom cannot recover files, how it spreads, what to look for and how to respond.

IronChain is a Windows ransomware family that shows victims a ransom screen and a payment portal, but cannot decrypt what it encrypts. ANY.RUN analysed a build from September 2026 and found that it never keeps the private key it would need, and that it scrambles each file in a way it does not record. Its verdict: wiper-like destructive malware with a ransomware presentation. RansomLook reached the same conclusion about an earlier build, IronChain 3.0, saying files stay unrecoverable even if the operator wanted to help.

That changes the response. A victim who pays gets nothing back, because no decryptor can exist for these files. What can be saved comes from backups, from the parts of large files the malware leaves alone, and from evidence collected before anyone reboots the machine. Any Windows estate is a possible target; neither report says how IronChain gets in, so treat it as something that can arrive through any foothold an attacker already has.

How the encryption breaks

Normal ransomware uses hybrid encryption. Each file gets its own random symmetric key (fast to use), and that key is then locked with the attacker's RSA public key. Only the matching private key, held by the operator, can unlock the file keys. Paying buys that private key, wrapped in a decryptor.

IronChain follows the same outline and then breaks it twice.

First, it generates a fresh 4096-bit RSA key pair on the victim's machine at startup. Each file gets a new 32-byte AES key, the file is encrypted with AES-GCM (an authenticated mode of AES), and the AES key is wrapped with the RSA public key using OAEP padding. The private half of the pair is never written to disk or sent anywhere. ANY.RUN found no code path that exports, stores or transmits it, and RansomLook found it lives only in process memory, gone when the process exits. With no private key, the file keys cannot be unwrapped.

Second, before encrypting, IronChain runs between two and seven passes of random byte shifting over the data. The function that does this returns the shift values, and the caller discards them. Even someone holding the RSA private key would decrypt the AES layer and get back shuffled bytes with no record of how to reverse them. Both analyses say the output does not contain enough information to restore files exactly.

Large files are encrypted only in part: the first 512,000 bytes, a random 51,200-byte block in the middle, and the last 512,000 bytes. Everything between those regions is left as it was. For a database file or a virtual machine disk of several gigabytes, most of the content is still there in plain text, which matters for recovery.

What else it does to the machine

IronChain is a Python program packed with PyInstaller into a 64-bit Windows executable. Beyond encrypting files, both reports describe the same destructive and disruptive behaviour:

• Raw writes to the physical disk through \\.\PhysicalDrive0, which can damage the boot structures. Both analysts warn that an infected machine may not boot normally again.
• Deleting Windows recovery options, and stopping services and security processes so they do not interfere.
• Spreading to network shares and removable drives, and probing the local network for more hosts.
• Blocking keyboard input and forcing a shutdown at the end of the run.
• Persistence through a Windows service named IronChainSecurity.

Both reports also found bugs that work against the ransomware's own goals, which is part of why they classify it as a wiper. RansomLook allows that the cause could be deliberate destruction dressed up as extortion, or plain incompetence.

No victim count, campaign or initial access method has been published. ANY.RUN's analysis was static, meaning the code was read rather than every path observed running, and it says plainly where it could not confirm runtime behaviour.

What to do if IronChain is running

1. Isolate. Unplug the network and remove any USB drives. Block SMB (TCP 445) between workstations at the switch or host firewall, because the malware copies itself over shares and keeps scanning for new hosts.
2. Do not reboot. The raw disk writes may have damaged the boot record. A routine restart can turn a recoverable disk into one that needs specialist work. Plan to boot from external media or work from a disk image instead.
3. Capture memory, then image the disk. If the process is still running, take a memory dump first. RansomLook notes the RSA private key exists only there. Recovering it would not undo the byte shifting, but memory can hold remnants of file content and keys that help responders. Then image the disk, including unallocated space, where policy allows.
4. Do not pay. There is no technical route from payment to working files. If someone claiming to be the operator offers a test decryption, it will fail.
5. Hunt across the network. Search other hosts and every removable drive that was plugged in during the incident for the indicators below.
6. Rebuild and recover. Rebuild affected machines from known-good media. Restore data from backups, then look at what the plain-text gaps in large files and file carving from the disk image can add.

Indicators reported in both analyses:

• C:\ProgramData\IRONCHAIN\time.dat (infection marker)
• IronChain.hta (the ransom screen)
• A Windows service named IronChainSecurity
• Encrypted files that begin with the marker CHAINED_6617-382+819=
• Raw handle opens on \\.\PhysicalDrive0 by a process that is not backup or disk software
• A ransom wallpaper bitmap; the file name differs between the two builds (IronChainBg.bmp in ANY.RUN's sample, IronChain_wallpaper.bmp in RansomLook's)

The two reports cover different builds with different hashes, so take the SHA-256 values from each report rather than relying on one. Single indicators can change with the next build; the combination of a new service, a write to the physical drive and recovery deletion from one process is a stronger signal.

When a decryptor cannot exist

Most ransomware decisions assume the attacker can decrypt and the question is whether to pay. IronChain shows that the assumption needs checking. Before any negotiation, ask an incident responder to look at the sample: whether the key is generated locally and discarded, and whether the encrypted files carry the data a decryptor would need. That can be answered in hours and saves money and time that should go into recovery.

It also means backup design carries the whole outcome. Our earlier post on backups that survive an intruder covers the setup; with IronChain, an offline or immutable copy is the only full recovery path there is.

Our security operations team hunts for the combination of behaviours above across endpoints, and our safeguarding and hardening work closes SMB paths between workstations and checks that backups sit out of an attacker's reach. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: ANY.RUN: IronChain analysis, RansomLook: IronChain 3.0 CTI brief, RansomLook: IronChain 3.0 full analysis, Risky Bulletin, October 12, 2026.