C3RB3R / .L0CK3D on NAS: TUNGTEK case #1377 and preserving recovery options

Case #1377: what the supplied record establishes

A NAS can report healthy disks and an available RAID while storing unreadable files. Storage availability and file contents are separate layers. An account with write access can alter data on a functioning array, including through a compromised endpoint.

The TEKLink218 materials supplied by TUNGTEK place case intake on 28 October. The roughly 5 TB figure is an estimate in that record, not a completed inventory of ciphertext. It does not establish that every file was encrypted, stolen or equally recoverable.

TUNGTEK also reports five ransomware-recovery intakes during October 2026. This is an internal operational count, not five C3RB3R cases or a representative Vietnam statistic.

What does a 588-byte difference mean?

TUNGTEK’s supplied static-analysis description concerns one document sample: 91,641 bytes, entropy approximately 7.9964/8, and no usual DOCX/ZIP signature at the beginning. Interpreting its final eight bytes yielded a candidate original size of 91,053 bytes, a difference of 588 bytes. Ransomware.VN publishes the sanitized description, not the original file, document name or private sample hash.

This is an observation about one sample. High entropy is consistent with transformed or random-looking data; it does not identify an algorithm, a key or the encryption scope of an entire NAS. A stronger format hypothesis requires representative samples across sizes, formats and times, ideally paired with pre-incident copies.

The community account below describes the same difference in another sample. That suggests a format question to investigate, not proof of a shared payload, key or operator. Removing 588 bytes does not turn ciphertext back into a DOCX. Work on copies and validate any output in the relevant application.

C3RB3R, Cerber and the limits of a name

SentinelOne and Huntress describe Confluence CVE-2023-22518 exploitation in the context of 2023 campaigns. Studied Windows samples use .L0CK3D and read-me3.txt; SentinelOne describes encryption of accessible SMB shares. This is historical reference material, not confirmation of a Confluence entry route in #1377.

Encrypted NAS files therefore do not, by themselves, prove execution inside the NAS operating system. Investigators must distinguish direct execution on the storage device from writes by an endpoint or server with share access. Correlate NAS, SMB, endpoint, authentication and network records before selecting either explanation.

Likewise, a Cerber/C3RB3R name in an older report or utility does not establish decryptor compatibility. The supported variant, file format, key requirements and publisher’s stated limits matter.

The public DS918+ account is a separate case

A first-person r/synology account, checked on 29 October, describes a DS918+ running DSM 7.2.1-69057 Update 5 with an internet-reachable web interface and some .L0CK3D files. The author suspects CVE-2024-10441 from surviving logs and explicitly says Synology has not confirmed the attribution.

The disks were moved to Proxmox after the incident for examination; Proxmox is not described as the entry route. The author reports neither a completed recovery nor full forensic images of every disk. Failed authentication followed by root-level cleanup is an investigative lead within that account, not a verified reconstruction of every stage.

One community account and one separate TUNGTEK intake do not establish a widespread Synology campaign. They also do not establish a shared model, exploit, payload, key or attacker.

Read the three Synology advisories separately

SA-24:20, published 5 November 2024 and updated 28 March 2025, covers CVE-2024-10441 alongside other issues. That CVE is critical RCE in the system plugin daemon; the DSM 7.2.1 fix is 7.2.1-69057-6. Being below a fix level establishes a patching concern, not the exploit used in a particular incident.

SA-26:13, dated 18 September 2026, addresses a different DSM vulnerability set with differing prerequisites. It should not be reduced to one RCE or treated as proof of a C3RB3R entry route.

SA-26:14, dated 22 October, addresses PHP2Shell CVE-2026-109618/109619 in relevant packages. The 28 October statement distinguishes dependent packages from DSM’s internal PHP; Synology Drive is unaffected. Its DSM 6.2 patch is scheduled for 29 October, not confirmed released by that statement.

These are advisory-specific minimums, not the latest supported release for every model. Check the actual model, DSM branch, packages and support status. Preserve evidence before making changes to an affected source device; patch during a planned clean-recovery phase. None of these sources establishes the entry route of #1377.

Hunting leads need provenance and context

Build a timeline using applicable DSM/authentication/web logs, SMB, VPN, SSH, firewall, reverse proxy, endpoint and backup records. Record time zones, clock differences, the last known readable version and the first observed ransom note. A failed login does not rule out application exploitation; an unfamiliar process name does not independently prove ransomware.

This article publishes no exploit payload, victim token, personalized Tor address or private sample hash. Preserve integrity hashes in the internal evidence record without placing them in a public article.

Restore, extract and decrypt describe different work

Review of No More Ransom did not establish a public decryptor compatible with #1377’s sample. Its CERBER V1 listing does not confirm .L0CK3D support. This is a verification limit at editing time, not proof that no tool exists anywhere.

Recovering an intact file or restoring a backup does not demonstrate that encryption was broken. Encryption, deletion, overwriting and theft require separate assessments. Readable restored files do not resolve the consequences of prior theft; exfiltration remains unresolved in #1377.

Five steps to preserve recovery options

1. Coordinate containment. Stop further writes or encryption through the network, SMB, endpoints and relevant accounts; control synchronization jobs. The response lead should weigh ongoing encryption, volatile evidence, logs and business impact before deciding whether to power down. There is no universal power-off instruction.
2. Preserve the source. Avoid formatting, resets, RAID rebuilds, filesystem repair and trial tools on the only copy. Record disk order, serials, array configuration, device condition and actions already taken. Plan imaging/copying around media health and preserve an activity log.
3. Keep evidence with provenance. Retain original notes, metadata, encrypted samples and pre-incident counterparts where available. Calculate SHA-256 for collected copies and record origin, custodian, time, tools and destination. A hash checks integrity; it does not establish authorship or legitimacy.
4. Locate clean recovery points. Inventory backups, snapshots, cloud versions, replicas and copies on other systems. Retain pre-incident points and prevent jobs from overwriting good copies. Identify which copies share administrative control with the suspected compromised source.
5. Analyze copies and validate results. Select representative samples, record results by data type and open recovered data in the business application. Use a clean target and address credentials, patches and monitoring before reconnecting services.

NIST SP 800-86 provides foundational incident-response forensics guidance. The actual procedure depends on media condition, architecture, staff and organizational requirements. Reporting can proceed alongside recovery; see the PA05 and digital-evidence guide.

3-2-1-1-0: plan for compromised administration

The 3-2-1-1-0 rule calls for at least three copies, two media types, one offsite copy, one offline/immutable copy and recoverability verification. A practical NAS question is whether a compromised administrator could delete every recovery point.

RAID tolerates certain disk failures within its configuration limits; it does not retain pre-encryption file history. Two-way sync can propagate deletion and encrypted versions. Local snapshots can provide fast rollback under suitable conditions, but share a physical failure domain and may be vulnerable to elevated permissions without protection.

Synology’s immutable-backup guidance discusses protected copies and independent destinations. Immutable-snapshot capability depends on supported hardware, filesystem, versions and configuration. Neither a product label nor a single setting establishes protection from every failure.

Choose schedules from the acceptable data-loss window (RPO) and target service-restoration time (RTO). A four-hour RPO needs sufficiently frequent, usable recovery points. A 24-hour RTO must be exercised against actual file counts, bandwidth and applications. They are design targets, not a guarantee for every 5 TB NAS.

Operational checklist after evidence preservation

• Inventory model, firmware/DSM, PHP packages, administrators, VPN, SSH and internet exposure. Patch the correct branch under an approved recovery plan.
• Reduce exposed management interfaces; apply segmentation, MFA where supported and least privilege. A VPN also needs maintenance, monitoring and account controls.
• Separate backup administration from production, protect recovery keys and alert on failed jobs, capacity, bulk changes and unsuccessful restores.
• Test files regularly and exercise service restoration after major changes. SQL, VMs and ERP need application-consistent protection and corresponding acceptance checks.
• Assign an owner to unresolved questions: entry route, impact, backup status and evidence of outbound data transfer.

Practical questions

Will renaming .L0CK3D to .docx restore a file?

Renaming does not reverse encrypted contents. Preserve the original and inspect structure on copies before deciding whether it is usable.

Why are files unreadable when RAID is healthy?

RAID provides disk-failure tolerance within its configuration. It does not prevent an account or process with write access from changing file contents.

Can removing the last 588 bytes recover a document?

There is no basis for that conclusion. A sample-level difference suggests metadata; truncation does not restore encrypted bytes and may destroy useful evidence.

Was #1377 caused by a Synology vulnerability?

That is unconfirmed. The manufacturer/model and entry route remain unresolved; the DS918+ account and vendor advisories have separate evidentiary scopes.

Does a snapshot replace an independent backup?

Assess deletion privileges, immutability, hardware and restoration. An ordinary same-device snapshot does not cover all risks addressed by an independent copy.

What can be assessed without a compatible decryptor?

Clean backups, earlier versions, intact files and forensic extraction may provide options. Each needs actual validation; no recovery percentage has been confirmed for #1377.

Ransomware.VN by TUNGTEK

Ransomware.VN presents information within the limits of the available evidence. TUNGTEK’s encrypted-data intake channel is CuuDuLieuMaHoa.com · 0963509115. RFC begins with assessment; it is not a promise of decryption or complete recovery.