Luke Ransomware Uncovered: A Deep Dive into Encryption and Exfiltration Tactics
Luke Ransomware: A Critical-Severity Encryptor That Also Steals A small (~558 KB) Windows PE flagged critical (90/100) is Luke, a ransomware sample that is also an information-stealer.
- Ransomware
Bottom line. Luke is a confidently malicious Windows ransomware sample (risk 90/100) that doubles as an information-stealer. It harvests data before or alongside encrypting files and deletes shadow copies to prevent rollback. It is not a major named RaaS brand (automated triage found no confident family match), so detection should be behaviour-led: watch for shadow-copy deletion, mass file encryption, and credential-store access, block the file hashes, and treat an infection as both a ransomware and a data-breach event.
Background
The sample is a ~558 KB Windows PE (SHA-256 2b17ed4a…) that automated analysis classified as MALICIOUS with a risk score of 90/100. Public sandbox reporting identifies it as ‘Luke Ransomware.exe’ and tags it as both ransomware and stealer, confirming it is genuinely malicious rather than a false positive. What it is not is a well-documented, top-tier RaaS operation: the analysis returned no confident family match, so ‘Luke’ is best treated as the sample’s own label, not a major tracked group.
Two accuracy notes on the automated write-up. First, the engine reported 29 ATT&CK techniques, but 16 of those were ‘Unmapped’. The meaningful, evidence-backed coverage sits in Execution, Defense Evasion, Impact, Exfiltration and Initial Access, and is presented cleanly below. Second, the single biggest thing the ‘ransomware’ label understates is the stealer component: this is a double threat, and the incident should be scoped for credential and data theft, not just file encryption.
What we observed
The behaviour that matters, drawn from the analysis:
- Ransomware behaviour: the sample was flagged for encryption activity and shadow-copy tampering. The classic ransomware combination of scrambling files while deleting the Volume Shadow Copies that would otherwise allow a local rollback.
- Stealer behaviour: sandbox analysis independently tags Luke as an information-stealer, meaning it collects data (typically browser credentials, tokens and local files) in addition to encrypting, so a Luke infection is a data-breach as well as a ransomware event.
- Small, self-contained payload: at roughly 558 KB the executable is compact and does not depend on a large framework, consistent with a purpose-built or builder-derived encryptor rather than a bloated installer.
- Rich indicator surface: the run extracted a set of network and file indicators (reported as several IPs, domains, URLs and an email address alongside the file hashes), useful for blocking and pivoting, though the specific network values live in the sandbox report rather than the summary.
- High conviction, low attribution: the verdict (malicious, 90/100) is high-confidence and corroborated by sandbox tagging, but the family attribution is weak. There is no confident match to a known RaaS, so behaviour-based detection matters more here than a family signature.
Luke ransomware chain
Treat a Luke hit as two incidents at once: a ransomware event and a data breach. Detect the recovery-kill and the credential access, not just the encryption.
Attribution
Luke is financially motivated commodity crimeware, a ransomware-plus-stealer sample with no confident link to a named nation-state actor or a major RaaS brand. Confidence that the sample is malicious ransomware/stealer is high (automated verdict 90/100 plus independent sandbox tagging); confidence in any specific family or operator is low, so this should be published as ‘a critical-severity encryptor-stealer’ rather than attributed to a known group. The ATT&CK mapping below is analyst-derived from the observed behaviour, because the automated engine left most techniques unmapped.
Confidence: 82%.
Luke encrypts what it can’t steal and steals what it can’t encrypt, and deletes your shadow copies on the way out.
Tactics, techniques & procedures (MITRE ATT&CK)
Techniques below are drawn directly from the analysed samples/reporting – no technique is asserted without evidence:
| Tactic | Technique | ID | Evidence |
|---|---|---|---|
| Initial Access | User Execution: Malicious File | T1204.002 | The ~558 KB PE is executed on the victim host to begin the chain. |
| Execution | Command and Scripting Interpreter | T1059 | The analysis mapped multiple Execution-tactic techniques for command/script activity. |
| Defense Evasion | Obfuscated Files or Information | T1027 | Defense-evasion techniques were observed, consistent with packed/obfuscated crimeware. |
| Credential Access | Credentials from Password Stores: Web Browsers | T1555.003 | The sample is independently tagged as an information-stealer that harvests stored credentials. |
| Collection | Data from Local System | T1005 | As a stealer, it collects local files and data prior to or alongside encryption. |
| Exfiltration | Exfiltration Over C2 Channel | T1041 | The analysis mapped an Exfiltration technique; stolen data is sent to attacker infrastructure. |
| Impact | Inhibit System Recovery | T1490 | Shadow-copy tampering was flagged, removing the most common local recovery path. |
| Impact | Data Encrypted for Impact | T1486 | File-encryption behaviour was flagged, the defining ransomware impact. |
Indicators of compromise
Defenders can block or hunt the following:
| Indicator | Type | Note |
|---|---|---|
| 2b17ed4a6cb47f0c38e7d21aec4dc0db0df9369506faf6ba60239431c9ec677a | sha256 | Luke Ransomware.exe sample |
| af7a7e841a1d2058face99a3569fd3dc | md5 | Luke Ransomware.exe (MD5) |
| 66840dda154e8a113c31dd0ad32f7f3a366a80e8136979d8f5a101d3d29d6f72 | sha256 | Related file observed in the analysis |
Detection
Copy-ready hunting query:
# Hunt for Luke ransomware + stealer behaviour (family-agnostic)
# 1) Recovery inhibition: shadow copy deletion / resize
index=edr (command_line="*vssadmin*delete*shadows*" OR command_line="*wmic*shadowcopy*delete*" OR command_line="*Win32_ShadowCopy*" OR command_line="*bcdedit*recoveryenabled*no*")
# 2) Mass encryption: high-rate file modification / rename by a single process
index=edr event=file_modified | stats dc(file_path) as files by process_guid | where files > 300
# 3) Stealer behaviour: non-browser process reading browser credential/token stores
index=edr (file_path="*\\User Data\\*\\Login Data*" OR file_path="*\\Local State*" OR file_path="*\\cookies*") AND NOT process_name IN ("chrome.exe","msedge.exe","firefox.exe")
# 4) Known file indicators
index=edr (sha256="2b17ed4a6cb47f0c38e7d21aec4dc0db0df9369506faf6ba60239431c9ec677a" OR sha256="66840dda154e8a113c31dd0ad32f7f3a366a80e8136979d8f5a101d3d29d6f72" OR md5="af7a7e841a1d2058face99a3569fd3dc")
#
# NOTE: the sandbox analysis also lists network IOCs (IPs, domains, URLs, an email). Pull those
# from the sandbox report and load them into your SIEM/EDR -- they are not reproduced here.
# SHA1 of the sample: 51a6f6a9dbc009ed941fce256e6560a53407ad1fRecommendations
- Treat it as two incidents: because Luke is a stealer as well as ransomware, scope for data theft, reset credentials, rotate tokens and secrets, and monitor for exfiltration, in parallel with the encryption response.
- Protect and test recovery: maintain offline/immutable backups and alert on shadow-copy deletion (vssadmin/wmic) and recovery-disabling commands, which fire before or during encryption.
- Block and enrich the indicators: block the file hashes, and pull the network IOCs (IPs, domains, URLs, email) from the sandbox report into your SIEM/EDR for blocking and pivoting.
- Detect on behaviour, not family: since there is no confident family match, prioritise behavioural detections, rapid mass file modification by one process, browser credential-store access by non-browser processes, and recovery inhibition.
- Contain fast: isolate affected hosts, preserve volatile evidence for IR, and treat any ‘Luke’-style encryptor-stealer as high severity even without a big-name RaaS label attached.
