GhostLock: Ransomware Không Mã Hóa Nhưng Có Thể Làm Tê Liệt SMB Share trên các hệ thống Windows
Tổng quan
Ngày 11 tháng 5 năm 2026, Các chuyên gia an ninh mạng công bố GhostLock một proof-of-concept tool chứng minh rằng một domain user bình thường, không cần quyền admin, có thể khóa hàng trăm nghìn file trên SMB share của doanh nghiệp chỉ bằng một API call hợp lệ của Windows. Không có file nào bị mã hóa. Không có byte nào bị ghi xuống disk. Không có cảnh báo nào từ EDR, NDR, SIEM, hay honeypot.
Từ góc độ người dùng, hệ quả không khác gì một cuộc tấn công ransomware: file không mở được, ứng dụng ERP crash, workflow tê liệt. Thời gian khôi phục trung bình trong tabletop exercise không có runbook sẵn là 4 đến 8 giờ.
Đây không phải CVE. Không có patch. Đây là behavior đúng, có tài liệu đầy đủ, tồn tại từ Windows NT 3.1 đến nay.
Cơ chế kỹ thuật
Windows CreateFileW và tham số dwShareMode
Hàm CreateFileW() là API cơ bản nhất để mở file trên Windows. Tham số dwShareMode kiểm soát quyền truy cập đồng thời: nếu giá trị là FILE_SHARE_READ | FILE_SHARE_WRITE thì process khác vẫn mở được file song song. Nếu giá trị là 0x00000000, Windows cấp cho process đó một exclusive deny-share handle — không một process, user, hay network client nào khác có thể mở file đó với bất kỳ mục đích nào (đọc, ghi, xóa) cho đến khi handle được giải phóng.
HANDLE hFile = CreateFileW(
L"\\\\fileserver\\shares\\finance\\budget2026.xlsx",
GENERIC_READ,
0, // dwShareMode = 0 → exclusive lock
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL
);
Mọi process khác cố mở file này sẽ nhận ngay STATUS_SHARING_VIOLATION (0xC0000043).
GhostLock scale kỹ thuật này thành vũ khí
GhostLock tự động hóa toàn bộ quy trình: duyệt đệ quy (recursive enumeration) qua SMB share, mở từng file với dwShareMode = 0, giữ handle mở liên tục, và tái acquire handle nếu bị đóng. Với 32 parallel thread, tool có thể khóa hàng trăm nghìn file trong vài phút.
Capacity thực tế đo được từ nghiên cứu:
| Cấu hình | File có thể khóa |
|---|---|
| 1 SMB session | ~64.000 exclusive handle đồng thời |
| 10 SMB session song song | >500.000 handle → đủ làm tê liệt NAS enterprise quy mô lớn |
| Thời gian block rate trong 60 giây | 99,8% |
GhostLock v2 còn tiến xa hơn: thay vì lock từng file, nó dùng CreateFileW với flag FILE_FLAG_BACKUP_SEMANTICS và dwShareMode = 0 để acquire exclusive handle trên toàn bộ thư mục. Một API call duy nhất tạo ra namespace lock trên toàn bộ cây thư mục phía dưới qua SMB, hiệu quả hơn đáng kể so với lock từng file.
Điều kiện thực thi
- Không cần privilege leo thang: domain user với quyền read thông thường là đủ
- Không cần malware: không có executable độc hại nào, chỉ là API call hợp lệ
- Không có CVE: không có lỗ hổng nào bị khai thác, đây là behavior by design
- Tự hồi phục: khi SMB session bị terminate, GhostLock process bị kill, hoặc máy reboot, Windows tự động đóng tất cả handle và file được trả về bình thường
Tại sao toàn bộ defense stack đều bị mù
Đây là phần đáng lo ngại nhất của nghiên cứu. Dvash đánh giá GhostLock trên 7 loại security control doanh nghiệp phổ biến và kết quả là zero alert trên toàn bộ:
| Security Control | Kết quả | Lý do |
|---|---|---|
| Honeypot / Canary file | ❌ Zero alert | Canary trigger dựa trên write event — GhostLock không ghi gì cả |
| Write-rate anomaly detector | ❌ Zero alert | Metric được monitor (disk write) hoàn toàn vắng mặt |
| Behavioral AI ransomware engine | ❌ Zero alert | Read-open profile không khác backup pre-scan agent hay search indexer |
| Commercial EDR agent | ❌ Zero alert | System call sequence giống hệt Microsoft Word đang mở document |
| NDR / Deep packet inspection | ❌ Zero alert | SMB2 traffic chỉ có CREATE và CLOSE request, không thể phân biệt với truy cập file bình thường |
| SIEM correlation rule | ❌ Zero alert | Không có ruleset nào monitor per-session exclusive handle count |
| File integrity monitoring | ❌ Zero alert | Không có thay đổi nào trên disk |
Vấn đề cốt lõi được Dvash diễn đạt rõ ràng: "The only observable that reliably identifies this attack is the per-session open-file count with ShareAccess = 0 at the file server layer — a metric that lives inside storage platform management interfaces, not in Windows event logs, not in EDR telemetry, not in network flow data."
Nói cách khác, signal duy nhất để detect GhostLock nằm trong NAS management interface — thứ mà storage operations team dùng để capacity planning, không phải thứ security operations team đang ingest vào SIEM.
Thêm một yếu tố làm recovery phức tạp
Kể cả sau khi phát hiện ra vấn đề, việc khôi phục không đơn giản. Để terminate SMB session đang giữ lock, cần có storage administration expertise. Trong hầu hết enterprise lớn, storage operations team và security operations team hoạt động độc lập, không có joint runbook sẵn cho tình huống này.
Một điểm đáng chú ý nữa: nếu credential của attacker bị revoke trong Active Directory, SMB session đang active và toàn bộ lock vẫn tồn tại thêm 15 đến 60 phút trước khi session timeout, tùy vào cấu hình platform. Revoke AD account không phải là biện pháp khôi phục tức thì.
GhostLock trong bức tranh tấn công thực tế
Disruption attack, không phải destruction
Dvash định vị GhostLock rõ ràng là disruption-based chứ không phải destructive. Parallel với ransomware là operational downtime, không phải data loss. File không bị mã hóa, không bị xóa, không bị exfiltrate.
Tuy nhiên, từ góc độ business impact, sự phân biệt này ít quan trọng hơn nhiều người nghĩ. Nếu finance team không mở được file trong 6 tiếng, nếu ERP system crash vì không đọc được data từ shared storage, nếu production workflow bị đình trệ — thiệt hại về operational downtime là thực, bất kể file có bị mã hóa hay không.
Decoy tấn công: vũ khí thực sự nguy hiểm hơn
Kịch bản đáng lo ngại hơn cả disruption đơn thuần là dùng GhostLock như một decoy. Khi IT team và SOC đang bị overwhelmed bởi hàng trăm ticket "không mở được file", attacker có thể tiến hành data exfiltration, lateral movement, hoặc privilege escalation ở một phần khác của môi trường mà không bị chú ý.
Đây không phải kịch bản lý thuyết. Đây là một trong những technique smoke-screen kinh điển nhất trong playbook của advanced threat actor.
MITRE ATT&CK Mapping
| Tactic | Technique ID | Technique Name | Triển khai trong GhostLock |
|---|---|---|---|
| Impact | T1499.001 | Endpoint Denial of Service: OS Exhaustion Flood | Chiếm hết exclusive file handle trên SMB session, không cho process khác truy cập file |
| Impact | T1485 | Data Destruction (tương tự về impact) | Không destroy data nhưng render data inaccessible — business impact tương đương với partial encryption |
| Defense Evasion | T1562 | Impair Defenses | Tất cả security control dựa trên write/encrypt detection đều bị bypass hoàn toàn |
| Defense Evasion | T1036 | Masquerading | Behavior (CreateFileW, SMB2 CREATE) không phân biệt được với backup agent hay search indexer |
| Initial Access | T1078 | Valid Accounts | Chỉ cần standard domain user với read access — không cần credential đặc quyền |
| Discovery | T1083 | File and Directory Discovery | Recursive enumeration qua SMB share để lập danh sách file cần lock |
| Collection / Decoy | T1560 (adjacent) | Archive Collected Data | Trong kịch bản decoy, GhostLock tạo noise cho phép data theft song song |
Detection
Signal chính để detect GhostLock không nằm trong Windows Event Log hay EDR mà nằm ở NAS session telemetry. Đây là thay đổi tư duy quan trọng nhất với Detection Engineer.
1. Export NAS session telemetry vào SIEM
Mọi enterprise NAS lớn (NetApp, Dell EMC Isilon, Pure Storage, Windows Server File Services) đều expose per-session exclusive handle count qua management API — thứ storage ops team đã dùng cho capacity planning. Việc cần làm là forward data này vào SIEM như security telemetry.
Ngưỡng cảnh báo khuyến nghị:
| Handle count per session | Severity |
|---|---|
| > 500 exclusive handle | Medium |
| > 1.000 exclusive handle | High |
| > 5.000 exclusive handle | Critical |
Một ứng dụng single-user hợp lệ hiếm khi giữ quá vài chục exclusive handle đồng thời. 500 là ngưỡng an toàn để bắt đầu mà không bị false positive từ backup agent hay search indexer.
Splunk SPL (adapt từ whitepaper — cần điều chỉnh tên field theo NAS platform):
index=nas_telemetry sourcetype=nas_session_stats
| stats max(exclusive_handle_count) as max_excl by session_id, src_ip, username, _time
| where max_excl > 500
| eval severity=case(
max_excl > 5000, "CRITICAL",
max_excl > 1000, "HIGH",
max_excl > 500, "MEDIUM"
)
| table _time, src_ip, username, session_id, max_excl, severity
| sort -max_excl
2. NDR rule: Bulk SMB CREATE không có WRITE tương ứng
Signal thứ hai là ở network layer: một source IP tạo số lượng lớn SMB2 CREATE request trong khi SMB2 WRITE gần như bằng không.
NDR Rule: GhostLock SMB Pattern
Condition:
- Protocol: SMB2
- Count(CREATE_REQUEST) > threshold (e.g., 10.000)
- Count(WRITE_REQUEST) < 10
- Time window: 30 phút rolling
- Per source IP
Alert on: CREATE/WRITE ratio > 1000:1
Lưu ý: backup agent cũng có pattern tương tự ở đầu job (pre-scan). Cần whitelist backup server IP và correlate với backup schedule để giảm false positive.
3. Windows Event: SMB session và open file monitoring
index=wineventlog EventCode=5145
| search ShareName IN ("\\*\\*", "IPC$" không bao gồm)
AND AccessMask="0x120089"
| stats count as open_count, dc(ObjectName) as unique_files
by SubjectUserName, IpAddress, _time span=5m
| where open_count > 1000 AND unique_files > 500
| table _time, IpAddress, SubjectUserName, open_count, unique_files
EventID 5145 (Object Access: Network Share Object Checked) log khi file được access qua SMB. Volume cao bất thường từ một user/IP trong khoảng thời gian ngắn là signal đáng chú ý, dù không specific bằng NAS telemetry.
4. Quick check với PowerShell (incident response)
# Liệt kê tất cả file đang bị mở qua SMB, group theo user
Get-SmbOpenFile |
Group-Object ClientUserName |
Select-Object Name, Count |
Sort-Object Count -Descending
# Nếu phát hiện session đáng ngờ, đóng tất cả file của user đó
$suspiciousUser = "DOMAIN\suspect_user"
Get-SmbOpenFile | Where-Object {\(_.ClientUserName -eq \)suspiciousUser} | Close-SmbOpenFile -Force
5. Terminate SMB session (recovery action)
# Tìm session của user đáng ngờ
Get-SmbSession | Where-Object {$_.ClientUserName -like "*suspect*"}
# Terminate session (giải phóng toàn bộ file lock)
Get-SmbSession | Where-Object {$_.ClientUserName -like "*suspect*"} | Close-SmbSession -Force
Nhận định
GhostLock không phải là kỹ thuật đặc biệt mới về mặt Windows internals. CreateFileW với dwShareMode = 0 được document đầy đủ từ thời Windows NT 3.1. Điều Dvash làm là hệ thống hóa nó thành một proof-of-concept có khả năng scale lên enterprise level, đồng thời kiểm tra một cách nghiêm túc xem security stack hiện tại có detect được không.
Kết quả là zero alert trên toàn bộ 7 loại control. Đây không phải con số gây sốc với những ai làm detection engineering lâu năm — mà là sự xác nhận chính thức của một blind spot đã tồn tại từ lâu: security stack của hầu hết doanh nghiệp được build xung quanh giả định ransomware phải ghi/mã hóa data. Khi giả định đó không còn đúng, toàn bộ detection logic xây trên đó đều mù.
Điều khiến GhostLock nghiêm túc hơn nhiều so với một PoC học thuật là ngưỡng kỹ năng cực thấp: không cần exploit, không cần CVE, không cần privilege escalation. Bất kỳ domain user nào cũng là potential attacker. Threat model "insider threat" hay "attacker có initial access qua phishing" đều hoàn toàn đủ để trigger kỹ thuật này.
Về defensive gap lớn nhất: sự tách biệt giữa storage operations và security operations là điểm yếu kiến trúc thực sự. Telemetry cần thiết để detect GhostLock đang nằm trong tay storage ops team. Nếu hai team không có joint workflow, không có data flow từ NAS vào SIEM, và không có joint runbook cho incident response, thì việc có SIEM tốt nhất thế giới cũng không giúp ích gì trong tình huống này.
Đây là lời nhắc nhở rằng detection coverage không chỉ là vấn đề "có rule hay không" mà còn là "data source có được ingest vào không".
Khuyến nghị
Immediate (0-48h):
- Inventory tất cả SMB file server và NAS trong môi trường
- Kiểm tra xem NAS management API có expose per-session exclusive handle count không
- Chạy PowerShell
Get-SmbOpenFilevàGet-SmbSessionđể có baseline bình thường về open file count per session
Short-term (1-2 tuần):
- Thiết lập data pipeline từ NAS management API vào SIEM; nếu chưa có sẵn integration, liên hệ NAS vendor để xin hướng dẫn export telemetry
- Triển khai NDR rule cho bulk SMB CREATE không có WRITE tương ứng
- Xây dựng joint runbook giữa SecOps và StorageOps cho kịch bản NAS session termination
- Test runbook với tabletop exercise; mục tiêu là MTTR dưới 1 giờ thay vì 4-8 giờ
Long-term:
- Đưa storage telemetry vào threat model và detection coverage matrix
- Review lại access control trên SMB share: principle of least privilege cho read access có giảm blast radius không?
- Cân nhắc SMB session limit per user (nếu NAS platform hỗ trợ) để giảm số handle một account có thể giữ đồng thời
- Xem xét GhostLock PoC để test môi trường trong authorized red team exercise trước khi attacker thực sự làm
Tài nguyên
- GhostLock GitHub Repository — Tool và source code (dùng cho authorized testing only)
- GhostLock Whitepaper Site — Companion research site với detection guidance đầy đủ
- CreateFileW documentation — Microsoft Learn: tham số dwShareMode
- Get-SmbOpenFile — PowerShell cmdlet để list open SMB file
- Get-SmbSession — PowerShell cmdlet để manage SMB session
Nguồn tham khảo:
- New GhostLock tool abuses Windows API to block file access — BleepingComputer
- GhostLock Tool Leverages Windows API to Lock File Access Like Ransomware — CyberSecurityNews
- GhostLock: when ransomware impact requires no ransomware — Andrea Fortuna
- GhostLock Locks 500K Files Without Encryption, Bypasses All EDR — TheCybrDef
- GitHub - kimd155/GhostLock
