FuxSocy-like ransomware: crypto analysis, NTFS artifacts and partial recovery

Executive summary

Indicators and recovered components

Encrypted filenames followed the general pattern:

.enc_<victim-or-campaign-id>

The ransom note followed:

<id>___READ_THIS___<id>.txt

Observed components included ENC_185FFEDA.EXE, SHD.EXE, temporary DLL/TMP files and WIN32ES.DLL.

Recovered DLL

Static analysis recovered configuration indicating network scanning, Wake-on-LAN, removable-drive handling, process termination, shadow-copy handling, free-space operations and a seven-day ransom deadline.

Embedded contact addresses included h3lper@exploit.im, h3lper@cock.li and h3lper@tutamail.com.

Encryption implementation

Ephemeral RSA-1024

Static reverse engineering of WIN32ES.DLL showed creation of a local RSA-1024 key pair using Windows CryptoAPI, approximately:

CryptAcquireContext(... CRYPT_VERIFYCONTEXT | CRYPT_SILENT ...)
CryptGenKey(... AT_KEYEXCHANGE, 1024-bit | CRYPT_EXPORTABLE)

The corresponding PRIVATEKEYBLOB would be 596 bytes. Sensitive private-key material is explicitly cleared after use. The context is consistent with an ephemeral key rather than a normal persistent key container.

Per-file RC4

Individual files use standard RC4 with a 16-byte random key. The DLL contains recognizable RC4 KSA and PRGA routines.

The random generator first attempts behavior matching:

BCryptGenRandom(NULL, buffer, length, BCRYPT_USE_SYSTEM_PREFERRED_RNG)

and falls back to CryptGenRandom. Reconstructing keys from timestamp, PID or GetTickCount therefore does not appear practical on a normal system.

Per-file metadata and encrypted-file layout

A plaintext metadata structure used internally begins with:

66 75 6B 00    ASCII: "fuk\0"

The structure contains a key-length byte 0x10, followed by the 16-byte RC4 key. A 117-byte metadata block appears to be protected by the local RSA-1024 key, producing a 128-byte RSA block.

[encrypted / partially encrypted file data]
[128-byte RSA-1024 protected per-file metadata]
[256-byte attacker-RSA protected data]

Observed file-size relationship

encrypted_size ≈ original_size + 416 + 2 × original_filename_length

This relationship was useful as an independent consistency check when matching stale NTFS directory entries to current encrypted files.

In-place and segmented encryption

The ransomware opens existing files for read/write access using OPEN_EXISTING. It does not simply create an encrypted copy and delete the original. Classic undelete therefore has limited value for small files because original clusters are overwritten.

Large files are handled with segmented encryption using approximately 64 MiB segments, with a maximum of roughly 10 large encrypted segments observed in the implementation.

Verified partial recovery

A roughly 1 GiB MPEG-TS television recording produced:

• 3 continuous valid MPEG-TS regions
• 386 MiB recovered
• 37.68% of the encrypted file
• largest intact region: approximately 320 MiB

This demonstrates that partial recovery without the key is possible for sufficiently large structured files.

Recovering original filenames from NTFS

Stale NTFS $I30 entries survived after ransomware renames. High-confidence mappings were established using:

• current encrypted-file MFT/File Reference
• sequence number
• stale $I30 filename
• old file size
• current encrypted size
• the observed ransomware size-overhead formula

More than one hundred mappings in the investigated business-data subset met the strongest conditions, including exact sequence agreement and a size-formula delta of zero.

Recovered original extensions included .xlsx, .pdf, .psd, .ai, .mp4, .png, .doc and .CR2.

Key-recovery paths that did not succeed

The following were extensively searched:

• pagefile.sys
• swapfile.sys
• hiberfil.sys
• $MFT
• $LogFile
• NTFS directory slack
• unallocated/raw disk space
• the entire raw victim NTFS volume

The approximately 2 TB volume was scanned for RSA key structures. Seven mathematically valid RSA-1024 PRIVATEKEYBLOBs representing three unique keys were found, but none decrypted the ransomware metadata.

A full raw scan for the plaintext fuk\0 metadata/key structure also produced no valid ransomware structure. Relevant hibernation-file extents were effectively zeroed in this case.

What another victim should preserve immediately

• full disk image or forensic clone
• $MFT
• $LogFile
• $UsnJrnl:$J
• pagefile.sys
• swapfile.sys
• hiberfil.sys
• Windows Prefetch
• AnyDesk/VNC/remote-access logs
• memory dump if safely obtainable
• ransom note
• encrypted samples of different sizes
• malware hashes

AI-assisted analysis disclosure

This investigation was conducted interactively with substantial assistance from OpenAI ChatGPT, model GPT-5.6 Sol.

AI-assisted work included static malware analysis, interpretation of disassembly, reconstruction of data structures, design of read-only PowerShell forensic scanners, analysis of NTFS artifacts, cryptographic reasoning and correlation of recovery results.

The malware was not intentionally executed as part of the reverse-engineering work described here.

AI-assisted technical analysis can contain mistakes. Researchers should independently validate offsets, structures, cryptographic assumptions and family attribution before relying on this page in another incident.

Information wanted from other researchers or victims

• exact ransomware family/version
• whether a working decryptor exists
• whether the ephemeral local RSA private key has been recovered elsewhere
• whether the implementation has a known cryptographic flaw
• whether others observed the same ~64 MiB segmented-encryption behavior
• whether the same DLL SHA-256 appears in other incidents

Live malware binaries are intentionally not hosted on this page. Hashes and behavioral details are provided for defensive correlation.

FAQ

Is there a universal decryptor for the investigated sample?

No working decryptor was identified during this case. Future research, a key leak or law-enforcement action could change that.

Can original filenames be recovered?

Sometimes. Stale NTFS $I30 entries can retain pre-rename filenames and can be correlated with current encrypted files.

Can large files contain recoverable plaintext?

Yes. Segmented encryption can leave large contiguous areas untouched, as verified by the MPEG-TS recovery result above.

Should the same disk be scanned forever for keys?

After memory-related sources, page/swap/hibernation files, NTFS metadata, unallocated space and the full raw volume have been thoroughly checked, repeated rescans with minor signature variations have diminishing value. Preserve the evidence for future decryptors instead.