GPcode Ransomware: The Trojan That Introduced Recovery Denial

GPcode ransomware, also known as PGPCoder, was a family of file-encrypting Trojans first observed in December 2004. It was the first widely distributed malware to encrypt the contents of victims’ files using strong asymmetric encryption. That means encryption in which the key used to lock a file cannot unlock it.

Kaspersky Lab broke the keys used by variants through mid-2006 by exploiting implementation errors in the author’s code. The RSA-1024 key introduced in the Gpcode.ak variant in June 2008 was never broken.

Victims who recovered their files did so using undelete utilities, since those versions wrote encrypted copies and deleted the originals.

The Gpcode.ax variant from November 2010 eliminated that recovery path by overwriting the file's contents in place. That design goal is one ransomware operators continue to pursue in 2026.

Security leaders seeking current defensive guidance can review Adaptive Security’s complete ransomware guide for cybersecurity teams.

GPcode Ransomware Quick Facts

The table below summarizes documentation on GPcode ransomware, from its first appearance in December 2004 to its final variant in March 2011.

What Is GPcode Ransomware?

GPcode ransomware is a family of Windows file-encrypting Trojans that operated from December 2004 to March 2011. It encrypted documents on infected computers and demanded payment to return them. Later variants used RSA-1024, an asymmetric cipher that no antivirus vendor was ever able to break.

The family separated infection from damage, because removing the Trojan did nothing to restore the files it had already encrypted. The name covers three generations of the original family, plus later malware that shares only the label. The industry also never settled on whether the original was a virus or a Trojan.

The GPcode Ransomware Variations

Four malware generations have carried the GPcode name, and only the first three share code and authorship. Identifying which one encrypted a given set of files determines whether recovery is possible at all.

The fourth entry sits apart from the other three. SonicWall’s Capture Labs team analyzed a sample in January 2023 that appended .ENCODED and carried the GPcode name. The team described it as part of a family active since 2005, though no published analysis establishes shared code or authorship with the 2004 strain.

How GPcode Is Classified and Why the Label Keeps Changing

GPcode ransomware is correctly classified as a Trojan, though Kaspersky Lab originally cataloged it as a virus. Its early detection name, Virus.Win32.Gpcode, was later replaced by Trojan-Ransom.Win32.Gpcode, reflecting that the malware never self-replicated and relied on being delivered to each victim.

That reclassification, compounded by each vendor applying its own taxonomy, is the source of most contradictory descriptions still in circulation.

The behavior maps to a single technique in the MITRE ATT&CK framework, a public catalog of adversary tactics. GPcode ransomware implemented T1486, Data Encrypted for Impact, which involves encrypting data on target systems to disrupt availability. MITRE does not list GPcode among the software entries under that technique, so the mapping describes behavior rather than a catalog entry.

The GPcode Ransomware Timeline: From a Byte Cipher to Unbreakable RSA

The GPcode ransomware timeline spans six years and moves in one direction. Every time Kaspersky Lab broke a key, the next variant shipped with a longer one.

GPcode was distributed as a mass campaign. The record therefore holds first-appearance, vendor-detection, and public-disclosure dates. A single-organization incident would instead produce breach, detection, disclosure, and actor-claim dates.

No threat actor has ever publicly claimed responsibility for the GPcode cyberattacks. The decisive period in the family’s history is eight days in June 2008.

How Did GPcode Ransomware Work?

GPcode ransomware separated delivery, encryption, and extortion into stages that each changed independently across its seven active years. The constant across all three was that removing the malware never restored the files.

Initial Access: Social Engineering, Then Drive-By Downloads

The June 2006 GPcode ransomware campaign is the best-recorded delivery method in the family’s history. Kaspersky Lab researchers Denis Nazarov and Olga Emelyanova found that the anketa.doc attachment was a dropper, meaning a file designed to install other malware. That dropper retrieved a downloader, which fetched GPcode itself.

Delivery became less visible over the following years. Vitaly Kamluk noted in Kaspersky Lab’s June 5, 2008 disclosure of Gpcode.ak that it was still not clear how the malware spread. That was an unusual admission from the vendor tracking it most closely.

By March 2011, Nicolas Brulez confirmed infection through drive-by download, meaning code that executes when a user visits a compromised website. GPcode ransomware had shifted from a lure that required persuasion to a delivery that required only a page load.

Execution and Encryption: What a Hybrid Scheme Is and Why It Changed the Economics

A hybrid encryption scheme leaves the ransomware operator holding exactly one secret and the victim holding none, which is why GPcode ransomware became unrecoverable in June 2008.

Symmetric encryption uses a single key to both lock and unlock data. Ransomware that relies on it alone must carry that key within the malware, where an analyst can extract it and publish a decryptor.

Asymmetric encryption splits that across a public key that locks and a private key that unlocks. The private key never leaves the operator.

Nicolas Brulez set out how the two were combined in the March 2011 variant. The malware generated a 256-bit AES key on the victim’s machine and used the operator’s public RSA-1024 key to encrypt it. The encrypted key was then dropped onto the desktop inside the ransom note itself.

The victim was left holding the key to their own files in a form only the operator could open. That turned decryption from a technical problem into a purchasing decision.

The malware also worked against being analyzed. Nicolas Brulez found that the March 2011 sample was packed with UPX, a common executable compressor. It was also wrapped in a custom protector written to slow down reverse engineering.

Its target file extensions were stored in an encrypted configuration file, allowing the operator to change them without recompiling.

Extortion: The Ransom Note and the Payment Rails

GPcode ransomware delivered its demand via a plaintext file left in the affected directories. The November 2010 variant added a text window on screen and replaced the desktop wallpaper, so the demand reached even users who had never opened those folders.

The notes were written in imperfect English. The Gpcode.ak ransom note instructed victims that “To recovery your files you need to buy our decryptor.”

Ransom notes are also where GPcode ransomware operators overstated what the malware did. Alexander Gostev set out the clearest case in July 2007. The note left by Virus.Win32.Gpcode.ai claimed RSA-4096 encryption, threatened to publish stolen data by July 15, and was signed “Glamorous team.” Kaspersky Lab found no sign of RSA-4096 in the sample, and no data publication ever followed.

Payment rails imposed the operation’s genuine constraint. The 2006 and 2007 variants required victims to email the operator to arrange purchase. By November 2010 the operation had moved to Ukash vouchers, bought with cash and redeemed by code.

Both rails involved an intermediary who could reverse a transaction, retain records, or refuse it, and each required someone to collect the money. Cryptocurrency removed those limitations at once, which is the largest single reason ransomware economics changed after 2013.

Who Was Behind GPcode Ransomware?

No individual or group was ever publicly identified, charged, or prosecuted for GPcode ransomware. The family operated for roughly seven years across four generations of encryption, producing no arrests, no indictments, and no court records in any jurisdiction.

One report came close. On October 1, 2008, John Leyden reported in The Register that Kaspersky Lab had traced a probable suspect in Russia by working back through an IP address. No action had been taken against them.

That account attributes the identification to the security vendor, and no resolution was ever published.

The available indicators point in one direction without establishing identity. Alexander Gostev noted in July 2007 that the ransom note’s poor English and its email addresses, which connected to previously observed Russian malware, indicated Russian origins. The earliest victims recorded in December 2004 were Russian businesses.

Every payment rail generated a record and required an intermediary, offering investigators a chokepoint that cryptocurrency later removed. None of it produced a prosecution.

The comparison with 2026 shows how much the economics changed and how little attribution improved. Chainalysis tracked $820 million in on-chain ransomware payments during 2025, meaning payments traceable on public blockchain ledgers. That figure was down approximately 8% from $892 million in 2024.

Data leak site postings showed a 50% year-over-year rise in the number of claimed victims over the same period, the most active year on record. The share of victims who paid potentially reached an all-time low of 28%.

Who Was Affected by GPcode Ransomware and What Data Was Compromised?

No organization affected by GPcode ransomware has ever been publicly named. No company disclosed an incident, no regulator logged one, and no breach notification tied to the family exists anywhere.

That also means there are no published figures for downtime, financial damage, regulatory consequences, or supply chain effects. No primary source supports any of those data points.

Records do establish the victim profile. Denis Nazarov and Olga Emelyanova found that the December 2004 samples encrypted files belonging to Russian banks, advertising agencies, and real-estate firms. That indicates deliberate selection of targets whose data carried commercial value.

By March 2011, the infection spread via drive-by download and was selected for whoever visited a compromised page. GPcode ransomware extorted victims solely through encryption, and no approved source reports exfiltration by any variant. That places it before the double extortion model, which pairs encryption with the threat of publication.

The right-hand column carries the useful finding. GPcode ransomware operators consistently described stronger cryptography and greater leverage than the samples demonstrated. Capability claims in a ransom note should therefore be treated as assertions that require independent verification.

Is There a Free GPcode Ransomware Decryptor?

No free decryptor exists for any variant of the original GPcode ransomware family. The No More Ransom Project, the law enforcement and industry initiative indexing hundreds of decryption utilities, does not list a tool for GPcode, Gpcode, or PGPCoder. Neither does Kaspersky Lab’s No Ransom portal.

One official recovery route exists and covers a single variant. Kaspersky Lab maintains a support page for Virus.Win32.Gpcode.ak directing victims to PhotoRec, a free file-recovery utility by Christophe Grenier, paired with its own StopGpcode helper. That route recovers the originals rather than decrypting the copies.

Nothing can recover files encrypted by Gpcode.ax or Gpcode.bn, because those variants overwrite file contents in place and remove the data file that recovery software depends on finding. Restoration from a backup is the only option, and anyone looking at encrypted files should first identify the specific family using the variants table above.

Could GPcode Ransomware Be Decrypted?

No RSA key used by GPcode ransomware was ever factored. Factoring means splitting a large number back into the prime numbers that produced it, and it is the operation that would break RSA.

Kaspersky Lab’s successes against keys up to 660 bits stemmed from errors in the author's implementation of RSA. The company drew that distinction on June 5, 2008, contrasting Gpcode.ak’s correct implementation with the earlier flawed ones.

Kaspersky Lab nonetheless attempted the mathematics. On June 9, 2008, it launched Stop Gpcode, an initiative whose stated objective was “to factor (‘crack’) the RSA-1024 key used in Virus.Win32.Gpcode.ak.”

The company published the two public keys involved, each using the standard public exponent 65537. It estimated the resources required at “around 15 million modern computers, running for about a year.”

Cryptographers rejected the premise immediately. Bruce Schneier wrote on June 12, 2008, that “We’ve never factored a 1024-bit number—at least, not outside any secret government agency—and it’s likely to require a lot more than 15 million computer years of work.”

Eran Tromer estimated that special-purpose hardware could break such a key within a year at a cost of “several million US$.” That is a state-scale budget.

Tromer also raised a warning that went unanswered. He noted that “we have not seen proof that the virus’s author indeed knows the corresponding private keys” and that the published numbers “may actually be copies of someone else’s public keys,” potentially a certificate authority’s root signing key.

Had that been so, an effort meant to help ransomware victims would instead have attacked the infrastructure behind trusted internet certificates. No verification followed, and Kaspersky Lab published no wind-down announcement, post-mortem, or final report for Stop Gpcode.

GPcode Ransomware Recovery: What Actually Saved Victims’ Files

GPcode ransomware recovery worked through undelete utilities, and that distinction is the most consequential fact about the family.

Victims of the June 2008 Gpcode.ak variant who got their files back owed it to the fact that the originals were still physically present on the disk. No one ever broke RSA-1024.

The reason was an error in how the malware handled files. Vitaly Kamluk described it on June 13, 2008: “Gpcode writes the encrypted data from the original file data to this new file, and then deletes the original file.”

Deleting a file removes its directory entry while leaving its contents on disk until another write reuses that space. The unencrypted original therefore stayed recoverable for as long as the disk went largely untouched.

Recovery came at a cost, because PhotoRec returns data without structure. Kaspersky Lab noted that the tool “has difficulty in restoring exact file names and paths,” which is why it built StopGpcode alongside it. Victims were left with reconstructed files stripped of the names and folder hierarchies that made them findable.

Kaspersky Lab’s advice was nonetheless unambiguous: “If you’ve fallen victim to GpCode, don’t pay the author of the virus to restore your data.”

The company’s incident response guidance then reversed within two years, and the reversal is instructive. In June 2008 Kaspersky Lab told victims “DO NOT RESTART or POWER DOWN the potentially infected machine.” Shutdown routines write to disk and risked overwriting the deleted originals recovery depended on.

By November 2010, the guidance became “Don’t hesitate and turn off your PC, pull out the power cable if this is fastest!” The newer variant destroyed data continuously while running. Ransomware incident response guidance therefore cannot be inherited from a previous incident without checking what the current sample does to files.

How GPcode Ransomware Introduced Recovery Targeting

The November 2010 Gpcode.ax variant is the earliest recorded case of a ransomware author modifying malware specifically to defeat a published recovery method.

Kaspersky Lab recorded the change and its own role in prompting it: “Unlike the previous variants, it doesn’t delete files after encryption. Instead it overwrites data in the files, which makes it impossible to use data-recovery software such as PhotoRec, which we suggested during the last attack.”

The encryption itself did not improve, since Gpcode.ax used the same RSA-1024 as Gpcode.ak. The change concerned only what the malware did with the original file, yet that single decision closed the last recovery path victims had.

Recovery denial, meaning the deliberate targeting of a victim’s ability to restore data, is now a defining characteristic of ransomware operations.

Mandiant reported in M-Trends 2026 that “Ransomware groups are no longer just encrypting data; they are actively destroying the ability to recover.” The firm observed a systemic shift in 2025 in which operators “actively targeted backup infrastructure, identity services, and virtualization management planes.”

Sixteen years separate one Trojan’s change in how it disposed of a file from coordinated cyberattacks on enterprise backup platforms, and the objective is identical.

Is GPcode Ransomware Still a Threat in 2026?

The original GPcode ransomware family has been inactive since 2011. Its last major variant, Trojan-Ransom.Win32.Gpcode.bn, appeared in March 2011, and no later sample has been publicly attributed to the operator behind the 2004 to 2011 campaigns.

The name is still in circulation. SonicWall’s Capture Labs threat research team published an analysis on January 13, 2023, of a sample it identified as GPcode. That sample appended .ENCODED to the files it encrypted, and the team reported it was still being seen in the wild.

That analysis produced an unusual finding. When SonicWall’s researchers emailed the contact address in the ransom note, the email bounced. The result was an operation still encrypting files while offering victims no working way to reach anyone.

SonicWall separately noted that GPcode malware authors have no track record of providing decryption keys after payment, so paying in such a case buys nothing.

How GPcode Served as the Base for Future Ransomware

GPcode ransomware already possessed the cryptography that later families are credited with introducing. Kaspersky Lab had conceded in June 2008 that it could not decrypt files protected by that scheme.

Two operational limits capped it instead. A single keypair covering every victim of a variant created one point of failure. Every payment rail also involved an intermediary who kept records.

CryptoLocker removed both without improving the mathematics. US-CERT recorded in November 2013 that it deposited “the asymmetric private encryption key out of the victim’s reach” on infrastructure the operators controlled. It also accepted MoneyPak and Bitcoin.

Ransomware has never escalated primarily in mathematics. It escalates in operations, meaning key distribution, payment mechanics, and now the victim’s recovery path. Operations are the only layer defenders can meaningfully contest.

What Cybersecurity Teams Can Learn From GPcode Ransomware

GPcode ransomware is instructive because its cryptography was solved and its operations were not. Four lessons carry forward from the 2004 to 2011 record into current practice.

Lesson 1: The Entry Point Has Not Changed in 22 Years

The most effective GPcode ransomware campaign on record arrived as a fake job application. Infection depended entirely on a person deciding to open a document that appeared to be an employment form. The same dependency drives intrusions in 2026.

The Verizon 2026 Data Breach Investigations Report found the human element present in 62% of breaches. Mandiant’s M-Trends 2026 recorded voice phishing as the second most common initial infection vector at 11%, ahead of email phishing at 6% and behind only exploits at 32%.

CrowdStrike reported in August 2026 that “Vishing intrusions in the first half of 2026 increased 2x compared to the second half of 2025.”

The delivery medium shifted from a document attachment to a synthetic voice, while the underlying method remained constant. Security teams should therefore treat human-risk controls, including security awareness training and phishing simulation, as a permanent line item.

Lesson 2: Treat the Recovery Path as a Primary Target

The Gpcode.ax lesson applies directly at enterprise scale. The #StopRansomware Guide, issued jointly by CISA, MS-ISAC, the NSA, and the FBI, states that “many ransomware variants attempt to find and subsequently delete or encrypt accessible backups.”

Three controls follow directly. The first is to maintain offline, air-gapped, and immutable backups, meaning copies that cannot be altered or deleted once written.

The second is to test restores on a schedule and treat a failed restore as a control failure. Recovery times should be validated against the stated RTO and RPO.

The third is to classify backup consoles, identity providers, and hypervisor management interfaces as tier zero, the same protection level as domain controllers. A cyberattacker reaching those systems removes the recovery option before encryption begins.

Lesson 3: The Heroic Fix Is Rarely the Fix

An international cryptanalysis initiative absorbed the attention in June 2008, and a file-undelete utility published four days later restored the data. Incident response playbooks should exhaust high-probability recovery paths, meaning backups, volume shadow copies, file undelete, and vendor utilities, before any effort goes to extraordinary options.

Time spent on the wrong track has a measurable cost. CrowdStrike measured the average eCrime breakout time falling to 29 minutes in its 2026 Global Threat Report, a 65% acceleration from 2024, with the fastest intrusion taking 27 seconds. Response windows that short do not accommodate exploratory approaches.

Lesson 4: A Clean Scan Is Not Containment

Kaspersky Lab added a Gpcode.ak signature on June 4, 2008, and still could not say the next day how the malware spread. A detection therefore establishes only that a file was recognized.

Detection has since become harder. CrowdStrike reported that “82% of detections were malware-free” in its 2026 Global Threat Report. The firm described adversaries operating through legitimate credentials and trusted pathways rather than deploying files that an engine can match.

Two capabilities compensate. Behavioral and identity telemetry detects the actions an adversary takes. That is the only signal available when no malicious file exists, and the only way to shorten dwell time.

A reporting culture in which the employee who clicked says so within minutes converts a silent compromise into a timed response.

GPcode ransomware is a closed case that left an open problem. What determined how much data victims recovered was never the strength of the encryption but whether the original file was still on the disk.

In November 2010, an operator removed that possibility with a change requiring no cryptographic advance. The same objective now drives cyberattacks on backup platforms, identity providers, and hypervisor management interfaces.

Encryption capability was settled decades ago, and restoration capability is what an organization still controls. That is the durable lesson of GPcode ransomware.

Frequently Asked Questions About GPcode Ransomware

Can Files Encrypted by GPcode Ransomware Be Decrypted?

Recovery depends on which GPcode ransomware variant encrypted the files. Variants released between December 2004 and June 2006 were decryptable, because Kaspersky Lab recovered the keys by exploiting errors in the author’s implementation of RSA.

Files encrypted by Gpcode.ak in June 2008 can often be recovered using file-undelete utilities. Files encrypted by Gpcode.ax or Gpcode.bn between November 2010 and March 2011 cannot be recovered by any method, because those variants overwrote the original data in place.

What Encryption Does GPcode Ransomware Use?

GPcode ransomware used four successive schemes. The original from December 2004 used a custom single-byte substitution cipher. The 2006 variants used RSA at key lengths of 56, 67, 260, 330, and 660 bits, all of which Kaspersky Lab defeated.

From June 2008 the family used a hybrid design pairing RSA-1024 with RC4 in Gpcode.ak and with AES-256 in Gpcode.ax. A symmetric key generated on the victim’s machine was itself encrypted with the operator’s RSA public key.

Was the GPcode Ransomware 1024-Bit Key Ever Cracked?

No, the RSA-1024 key used by GPcode ransomware from June 2008 onward was never factored, and no files encrypted with it have ever been decrypted.

Kaspersky Lab launched an international initiative called Stop Gpcode on June 9, 2008, to precisely that end. It produced no result, no post-mortem, and no final report. Claims that the GPcode key was cracked conflate it with the shorter keys Kaspersky Lab broke before June 2008, which were due to implementation errors.

How Much Did GPcode Ransomware Demand?

GPcode ransomware demands ranged from approximately $20 to $300 per victim and varied by variant and year, which is why conflicting figures circulate. Kaspersky Lab set the lowest accepted payment at approximately $20 (500 rubles) and a typical 2006 demand at approximately $70 (2,000 rubles).

The July 2007 variant demanded $300, Gpcode.ax demanded $120 in November 2010, and Gpcode.bn raised that to $125 in March 2011.

Was GPcode the First Ransomware?

No, the AIDS Trojan, also known as PC Cyborg, predates GPcode ransomware by 15 years and is generally regarded as the first ransomware. It was distributed on approximately 20,000 floppy disks in December 1989 by Dr. Joseph Popp, a World Health Organization consultant.

Jim Bates found in Virus Bulletin in January 1990 that it encrypted only file names and extensions. He noted that “The program does not alter the contents of any of the user's files, just their names.”

GPcode ransomware’s distinction is that it was the first widely distributed family to encrypt the contents of victims’ files using strong asymmetric cryptography.