In this Sherlock, you confront a serious threat at Forela: a significant number of UNIX servers have been infected by a suspected ransomware. Forela has decided not to negotiate with the attackers, putting the onus on the you to recover the encrypted files. This task demands players to utilize their understanding of ransomware operations, UNIX server structures, and digital forensics to restore the affected files. It’s a high-pressure race against time, testing the your resilience, ingenuity, and technical prowess.
Warning
This is a warning that this Sherlock includes software that is going to interact with your computer and files. This software has been intentionally included for educational purposes and is NOT intended to be executed or used otherwise. Always handle such files in isolated, controlled, and secure environments.
Once the Sherlock zip has been unzipped, you will find a DANGER.txt file. Please read this to proceed.
A ransomware binary encrypted business files across Forela’s UNIX servers. The encryption is a plain repeating-key XOR, and the key sits in the binary’s read-only data beside the list of target extensions and the ransom note carrying the attacker’s contact address. Reading the key statically was enough to write a short decryptor and restore the applicants database, the trading backup and the complaints file without running the sample. The recovered data then answered the follow-on questions: an applicant record, an IT asset entry, trading activity for the insider-trading inquiry and a sales-forecast log for an account-sharing check.
strings and objdump, never execute itFormat note: The MD5 answers are the hash of the decrypted file, so a decryptor that corrupts even one byte gives a wrong hash.
Dump the strings and the .rodata section of bescrypt3.2. One 18-character string sits among the format strings and the extension list, and the encryption routine indexes it by position modulo its length, which makes it a repeating-key XOR. The answer mask (17 asterisks and a trailing p) matches that length.
strings -a bescrypt3.2 | lessobjdump -s -j .rodata bescrypt3.2The ransom note is a string constant compiled into the binary. The same strings output from Q1 contains the note text, and the contact address is in it.
strings -a bescrypt3.2 | grep -i '@'The extension whitelist is stored in .rodata beside the key. Compare the nine candidates against it: eight appear and one does not. The mask (.**t) already narrows the answer to a three-letter extension ending in t.
objdump -s -j .rodata bescrypt3.2From Q1 we have the key. The decryptor XORs each byte of an encrypted file with the key byte at offset % 18 and writes plaintext to a separate work/dec directory, so the evidence stays untouched. The applicants file decrypts to a SQL dump, and a correct decryption reads as ordinary INSERT statements. Hash that output.
python3 -I dec.pymd5sum work/dec/*.sqlTip: Decrypt into a separate directory. The evidence is read-only and the sample never needs to execute.
Same decryptor, different output. The trading backup decrypts to a JSON export (trading-firebase_bkup.json), so confirm it parses before trusting the hash.
md5sum work/dec/*.jsonThe complaints file decrypts to a CSV. Hash the output the same way.
md5sum work/dec/*.csvSearch the decrypted applicants SQL dump for the email address. It matches a single INSERT row (row 830), and the first and last name columns on that row hold the registered name.
grep -n '[email protected]' work/dec/*.sqlThe IT asset inventory decrypts to it_assets.xml. Find the asset assigned to Hart Manifould (asset 501) and read its MAC address and serial number fields. The mask is XX-XX-XX-XX-XX-XX, XXXXXXX, so keep the dashes and the comma and space between the two values.
grep -n -B3 -A10 'Manifould' work/dec/it_assets.xmlLoad the decrypted trading-firebase_bkup.json and sort the records by profit_percentage. One record (id 1559) is the clear maximum, and its owner’s email is in the same record. The percentage has to be copied as the raw text from the file, so pull it with grep rather than through a JSON parser.
grep -o '142303\.[0-9]*' work/dec/trading-firebase_bkup.jsonGotcha: Loading the file with
jqor Python turns the value into a float and rounds it to142303.19960539296. Rounded forms (fewer decimals, a trailing%) were also rejected. The platform wants the full decimal string exactly as stored.
The sales forecast is a decrypted .xlsx workbook. Open sheet1 and find the row for Karylin O’Hederscoll (row 88). The IP address column on that row is the answer.
python3 -I -c "import openpyxl,sys; ws=openpyxl.load_workbook(sys.argv[1]).worksheets[0]; print([c.value for c in ws[88]])" work/dec/sales_forecast.xlsx| Phase | Action |
|---|---|
| Impact | Ransomware encrypts business files on UNIX servers with a repeating-key XOR |
| Impact | Ransom note directs the victim to an attacker-controlled ProtonMail address |
| Recovery | Key lifted from .rodata, files decrypted offline and verified by MD5 |
| Collection | Recovered HR, asset, trading and sales data shows what was exposed |
| Type | Value |
|---|---|
| Malware | bescrypt3.2 |
| Encryption key | bhUlIshutrea98liOp |
| Attacker email | bes24[@]protonmail[.]com |
| Technique | ID | Description |
|---|---|---|
| Data Encrypted for Impact | T1486 | Files with a whitelisted extension XOR-encrypted and a ransom note left |
| Data from Local System | T1005 | Business data on the servers is the target of the encryption and exposure |
A hardcoded symmetric key makes the ransomware reversible. The key was a plain string in .rodata, so recovery needed one strings run and a short script. Keep the sample and do static analysis before anyone considers paying.
Back up, and keep backups out of reach of the same servers. The infected hosts held HR records, trading history and complaints. Offline or immutable backups would have made the decryption work optional.
Sensitive records should not sit in flat exports on general-purpose servers. Applicant PII, asset inventories with MAC addresses and trading data with email addresses were all readable once decrypted. Treat any of them reaching an attacker as a data exposure incident, not only an availability one.
Handle ransomware samples like live ammunition. Extract the archive without running anything, decrypt into a separate working directory and verify with hashes.
The ransomware used a static XOR key stored in its own binary, so the encrypted business data was fully recoverable offline. The sharper lesson is exposure: once decrypted, the files show how much personal, financial and trading data was sitting on those servers.