GoodLock Ransomware Decryption & Data Recovery

GoodLock is a Windows ransomware family that Chinese security vendors track but that carries very little public technical documentation. Only two points on its timeline are verifiable: Antiy Labs captured samples in September 2025 and published its extension and ransom-note signatures in the AVL SDK engine update notice of 13 September 2025 under the detection name Trojan/MSIL.Goodlock[Ransom]; 360 then listed GoodLock as a newly observed traditional ransomware family in its June 2026 monthly ransomware report.

That "traditional" label carries information. 360 splits newly seen families into double-extortion operations and traditional ones, and places GoodLock in the latter group - encryption for ransom, without an accompanying leak site. A separate check agrees: GoodLock does not appear in the group directories maintained by mainstream ransomware trackers. Unlike LockBit or Qilin, which name victims publicly, GoodLock's leverage rests almost entirely on data being unavailable.

The detection name Trojan/MSIL.Goodlock indicates a .NET (MSIL) binary. Encryptors of that kind are cheap to build and quick to iterate. For scale: in the same monthly report the top three families by infection share were Weaxor (32.47%), Sorry (17.75%) and Wmansvcs (14.29%), with Windows 10, Windows Server 2008 and Windows 7 the most-hit systems. GoodLock is nowhere near that volume.

A note on its current activity level. We checked 360's two following monthly reports - July 2026 (published 13 August 2026) and August 2026 (published 8 September 2026) - and GoodLock appears in neither, not among the newly added families and not in the infection-share tables. Read that carefully: 360 names only new families and those clearing a reporting threshold, so absence is not proof the family has stopped. It does mean no new publicly visible record has accumulated since June 2026. This page therefore marks the lifecycle as emerging rather than established: a single month on a tracker is too thin to support a claim of sustained circulation.

To be candid: public information on GoodLock is limited. Its initial access route, ciphers, whether it deletes shadow copies, whether any Linux or ESXi encryptor exists, and the contact and payment channels inside the note are all unconfirmed, and this page does not fill those gaps with guesswork.

Extension. .goodLock is appended to the full original filename, with the mixed casing (capital L) preserved - config.ini becomes config.ini.goodLock. The suffix is fixed rather than randomised, so searching by it is a reliable first-pass check.

Ransom note. ___RECOVER__FILES__.goodLock.txt is dropped on the desktop. As printed in the Antiy notice the underscore runs are three, then two, then two. Do not treat the underscore count as a hard test: advisories and pages that republish the name routinely swallow or merge runs of underscores, and we read inconsistent spellings across sources while checking this. Match on the three-part pattern RECOVER / FILES / .goodLock.txt and then go by the filename actually on disk. The name remains the most dependable attribution signal; no other family in public reporting uses it.

Targeted file types - an important difference. Antiy describes the analysed sample as traversing system directories and encrypting files with the ini, exe and lnk extensions. That departs sharply from the usual pattern of hitting documents, databases and archives first. Where the site matches that description, the symptom set is "documents appear intact, but programs will not launch, every shortcut is broken and services fail to start" rather than the more familiar wall of renamed data files.

How to attribute, and what to watch for.

• Lead with the note filename and corroborate with the extension; both present together is effectively conclusive.
• Antiy's description comes from a specific sample and is not a complete encryption manifest for every variant. Inventory what was actually encrypted on site rather than assuming.
• Do not attribute on contact details - no mailbox domain, Tox ID or onion portal has been publicly recorded for this family.
• Because the binary is .NET, managed-code processes and .NET runtime loading artefacts are usually visible on the host and can support memory forensics.

No public report describes how GoodLock gains initial access or moves laterally, and we will not guess. The Antiy notice offers only generic hardening advice - strong passwords, prompt patching, closing high-risk ports such as 3389/445/139/135, caution with suspicious mail attachments and links, restricting PowerShell, and offline backups. That is a baseline for ransomware in general and cannot be read backwards as a confirmed kill chain for this family.

What can inform triage is the wider domestic picture from the same period. 360's June 2026 report shows the month's leading families spreading through vulnerabilities in software common at smaller companies, component authentication flaws and fileless techniques, plus remote desktop logins; servers and desktop PCs were hit in roughly equal measure, with legacy builds such as Windows Server 2008 and Windows 7 heavily represented. For Chinese organisations these remain the priority self-checks:

• Internet-exposed remote desktop and administration entry points, especially accounts with weak passwords or no multi-factor authentication.
• Long-unpatched legacy Windows servers and end-of-support middleware.
• Mail attachments and download sources disguised as common software or cracking tools.
• Backup storage directly reachable from the LAN, and backup systems sharing credentials with production.

For any individual GoodLock incident, the entry point has to come from on-site forensics - logs, account activity and dropped files - not from assumptions borrowed elsewhere.

No complete public reverse-engineering of the GoodLock encryptor exists, so the following separates what is evidenced from what is not.

Evidenced (from Antiy's description of the captured sample):

• It traverses operating-system directories before encrypting.
• It encrypts files with the ini, exe and lnk extensions and appends .goodLock.
• It drops ___RECOVER__FILES__.goodLock.txt on the desktop.
• No effective decryption tool existed as of the notice.

Not evidenced: the specific symmetric and asymmetric cipher combination, key generation and wrapping, whether intermittent or block-based encryption is used, whether shadow copies are deleted and logs cleared, whether database and backup processes are terminated, how network shares and mapped drives are handled, and whether any Linux, ESXi or NAS encryptor exists.

That distinction shapes the recovery plan, and the target list matters most. If only ini, exe and lnk files were in fact encrypted on site, the business data itself may be intact and the work shifts toward restoring system and application availability rather than rescuing data. If the actual scope is wider - variants can and do broaden their target types - then the standard approach applies: measure which regions of large files were overwritten and determine whether databases and virtual disks still offer structural repair space. That measurement requires the real encrypted files; it cannot be inferred from the family name.