Đó là bối cảnh của Ticket #1355 mà TUNGTEK đang tiếp nhận để phân tích ổ đĩa, RAID, filesystem và khả năng trích xuất dữ liệu mã hóa.

Lưu ý về bằng chứng: ca đang được phân tích. Con số 74.000 USD là thông tin ghi nhận khi tiếp nhận. Chúng tôi chưa gán ransomware family và chưa công bố kết quả phục hồi khi chưa có đủ IOC, ransom note và mẫu dữ liệu để xác nhận.

Ổ cứng thật, áp lực thật

NAS thường chứa dữ liệu dùng chung, hồ sơ kế toán, dự án, hình ảnh, database, máy ảo và đôi khi cả backup. Khi tài khoản có quyền ghi bị chiếm hoặc ransomware tiếp cận trực tiếp các share, tác động có thể lan rất rộng.

Trong Ticket #1355, mẫu ổ được tiếp nhận là Synology HAT3300-4T, 4 TB, SATA.

74.000 USD không cho biết khả năng phục hồi

Tiền chuộc phản ánh mức mà kẻ tấn công tin nạn nhân có thể hoặc buộc phải trả, không phản ánh tình trạng kỹ thuật của dữ liệu. Trước mọi quyết định đàm phán, câu hỏi quan trọng hơn là: dữ liệu đã bị tác động như thế nào, phần nào còn nguyên, và có con đường kỹ thuật độc lập nào để phục hồi hay không?

Bốn lớp cần kiểm tra trước

1. Phạm vi mã hóa

File nào đổi extension, file nào còn nguyên, mã hóa toàn bộ hay theo từng vùng, và có dấu hiệu xóa hoặc ghi đè hay không.

2. Tầng lưu trữ

Trạng thái RAID, volume, partition, filesystem, metadata, journal, snapshot và các block cũ.

3. Mẫu file và bằng chứng

Header, footer, signature, entropy, pattern mã hóa, extension, ransom note và IOC.

4. Cơ hội phục hồi

Phần chưa bị mã hóa, filesystem forensic, file carving/reconstruction, backup, snapshot hoặc bản sao khác.

Preserve First – Analyze Second – Recover Third.

Bảo toàn hiện trạng phải đi trước mọi thao tác phục hồi.

Những việc đừng vội làm

• Format volume hoặc initialize lại ổ.

• Rebuild RAID không kiểm soát.

• Reset NAS hoặc cập nhật firmware khi chưa cần thiết.

• Copy dữ liệu mới vào volume bị ảnh hưởng.

• Cài lại hệ điều hành trên cùng vùng lưu trữ.

• Xóa file bị mã hóa hoặc chạy nhiều công cụ trực tiếp trên ổ nguồn.

Hai file cùng có trạng thái “bị ransomware mã hóa” vẫn có thể có cơ hội phục hồi rất khác nhau. Có biến thể chỉ mã hóa header hoặc một số block; có biến thể mã hóa theo khoảng; cũng có trường hợp toàn bộ file bị mã hóa bằng thuật toán mạnh với key riêng. Với MDF, LDF, VHDX, VMDK, PST, ZIP, database hay video, cấu trúc nội bộ của file quyết định nhiều đến chiến lược phục hồi.

NAS không phải Backup

RAID giúp duy trì tính sẵn sàng khi ổ đĩa hỏng theo cấu hình cho phép. Nhưng RAID không ngăn một tài khoản hợp lệ xóa, ghi đè hoặc mã hóa file. NAS luôn online và dùng chung hệ thống quyền vẫn nằm trong phạm vi ảnh hưởng của ransomware.

Mô hình an toàn hơn cần nhiều lớp sao lưu, có ít nhất một bản offline, air-gapped hoặc immutable, tài khoản tách biệt và lịch restore thử. “Backup Successful” chỉ là một trạng thái; khả năng khôi phục phải được kiểm chứng.

Nếu đang có sự cố

1. Cô lập thiết bị nghi nhiễm, tránh reset hoặc khởi tạo lại.

2. Giữ ransom note, ảnh màn hình, extension lạ và timeline thao tác.

3. Tạm dừng đồng bộ, khóa tài khoản nghi bị chiếm.

4. Tạo clone/image trước khi thử công cụ giải mã hoặc recovery.

5. Xếp ưu tiên dữ liệu theo nhu cầu kinh doanh.

Đọc bản kỹ thuật đầy đủ: Ransomware tấn công NAS, hacker đòi 74.000 USD – Ticket #1355.

Nếu cần đánh giá hiện trạng NAS, RAID, Server, Hyper-V/VMware, SQL hoặc File Server bị ransomware: TUNGTEK – 0963 509 115. RFC – Ransomware Fast Check bắt đầu trên mẫu dữ liệu; kết luận chỉ dựa trên bằng chứng thực tế.

• 9,97 GiB: Mẫu MDF được phân tích

• 215: Vùng biến đổi/mã hóa ghi nhận

• ~5%: Phạm vi byte-level bị ảnh hưởng

• ~95%: Dung lượng ngoài vùng mã hóa

Từ Mallox đến WEX: kinh nghiệm thực chiến trước đây giúp TUNGTEK rút ngắn giai đoạn đánh giá, giảm vòng thử sai và tập trung sớm vào Recovery + Validation dữ liệu nghiệp vụ.

Case Thực Tế #1326 – BRAVO .WEX: bàn giao thành công dữ liệu dùng được

Niềm vui không phải “file đã copy xong” — mà là dữ liệu đã quay lại công việc

Trong Ransomware Recovery, một file MDF có thể đọc được chưa đồng nghĩa database đã dùng được. Kết quả chỉ có ý nghĩa khi cấu trúc SQL Server đủ ổn định, dữ liệu nghiệp vụ truy xuất được, và cuối cùng chính ứng dụng BRAVO cùng người dùng xác nhận quy trình làm việc trở lại.

“Congratz & Thanks to @TUNGTEK – Tùng Nguyễn cùng cả team đã cứu được dữ liệu và active lại chương trình của BRAVO!”

Phản hồi của khách hàng trong quá trình bàn giao — thông tin định danh đã được ẩn.

Xác nhận chính thức trong hồ sơ nghiệm thu: phía BRAVO đã kiểm tra dữ liệu và ghi nhận “đạt yêu cầu sử dụng cho công việc”; phạm vi bàn giao gồm dữ liệu BRAVO và File Server, chất lượng được ghi nhận “đạt yêu cầu, sử dụng bình thường”.

Kinh nghiệm tích lũy là lý do hiệu suất Recovery ngày càng cao

“Chúng ta có một quá khứ kinh nghiệm với Mallox — và chính chiều sâu đó khiến WEX không còn là một bài toán hoàn toàn mới.”

Trong thực tế Ransomware Recovery cho SQL Server, hiệu quả không chỉ đến từ một công cụ hay một decryptor. Nó đến từ khả năng đọc nhanh hiện trạng, nhận diện pattern tác động, hiểu cấu trúc dữ liệu nghiệp vụ và biết đâu là phần cần ưu tiên để đưa hệ thống trở lại trạng thái có thể kiểm chứng.

Những ca thực chiến trước đây với Mallox / TargetCompany tạo cho TUNGTEK một nền kinh nghiệm có giá trị: cách nhìn file .mdf/.ldf, cách đánh giá các vùng hỏng rời rạc, sự phụ thuộc giữa page, metadata, allocation map và dữ liệu nghiệp vụ; đồng thời hiểu rất rõ rằng attach được database chưa phải là Recovery thành công.

Vì vậy khi gặp .WEX, Ticket #1326 không được nhìn như một ca “extension mới thì mọi thứ bắt đầu lại từ đầu”. Kinh nghiệm Mallox giúp rút ngắn giai đoạn định hướng, tăng chất lượng RFC và tập trung sớm vào con đường có giá trị nhất: trích xuất → tái cấu trúc → Validation thực tế bằng BRAVO.

“WEX không còn là vấn đề” trong ngữ cảnh của case này không có nghĩa mọi ca WEX đều dễ hoặc đều phục hồi được. Ý nghĩa chính xác là: TUNGTEK đã có nền tảng kinh nghiệm đủ sâu để WEX không còn là một bài toán xa lạ, từ đó xử lý có phương pháp, nhanh hơn và hiệu quả hơn so với việc bắt đầu từ con số 0.

Tư liệu thực tế ẩn danh Ticket 1326: phản hồi khách hàng, nghiệm thu và màn hình BRAVO

Từ kinh nghiệm thành hiệu suất

Nhận diện nhanh hơn: không dừng ở tên extension; ưu tiên pattern tác động lên SQL Server và dữ liệu thật.

RFC có trọng tâm hơn: đo vùng ảnh hưởng và đánh giá khả năng cứu theo cấu trúc Page / Extent thay vì chỉ nhìn trạng thái file.

Recovery ít vòng thử sai hơn: bảo toàn source, làm việc trên working copy và ưu tiên dữ liệu nghiệp vụ.

Validation đúng đích: kết quả cuối phải được kiểm chứng bằng BRAVO và người dùng thực tế.

Bóc tách hồ sơ kỹ thuật: một MDF lớn, nhiều vùng hỏng rời rạc

Ghi chú ẩn danh: trong bài viết công khai, các tên khách hàng, tên công ty, mã định danh và tên file có khả năng nhận diện đã được thay thế. Ký hiệu ABC là tên thay thế dùng riêng cho case study này; không phải tên doanh nghiệp thật.

Thông tin mẫu RFC

Loại dữ liệu: Microsoft SQL Server / BRAVO.

Mẫu phân tích: B8R2_ABC.mdf.wex.

Dung lượng tuyệt đối: 10.708.713.644 bytes ≈ 9,9733 GiB.

Vùng bị biến đổi/mã hóa: 215 vùng.

Ước tính byte-level: ~5% bị ảnh hưởng, ~95% nằm ngoài vùng mã hóa.

Mục tiêu Recovery

RFC đánh giá khả thi cao để triển khai hướng trích xuất dữ liệu trên working copy, không phụ thuộc hoàn toàn vào khóa của đối tượng tấn công.

Mục tiêu dịch vụ được đặt ở khoảng 95–98% dữ liệu có khả năng sử dụng, nhưng chỉ được công nhận sau Validation nghiệp vụ thực tế.

Quan trọng: mục tiêu Recovery không phải cam kết rằng 95–98% mọi record đều nguyên vẹn.

Một hình — đủ bối cảnh kỹ thuật của Ticket #1326

Hình dưới đây tổng hợp các điểm chính của case: BRAVO / SQL Server, mẫu B8R2_ABC.mdf.wex, 215 vùng ảnh hưởng, khoảng 95% dung lượng ngoài vùng mã hóa và kết quả được Validation thực tế trước khi bàn giao.

Infographic chi tiết Ticket 1326 BRAVO WEX

5% bị ảnh hưởng không có nghĩa “chỉ mất 5% dữ liệu” — và 95% còn lại cũng chưa chắc dùng được ngay

Với database, vị trí của vùng hỏng quan trọng không kém dung lượng. Một vùng mã hóa nhỏ nhưng rơi đúng vào metadata, allocation map, page chain, index hoặc các cấu trúc then chốt có thể làm SQL Server không attach được cả database. Ngược lại, nếu các vùng lỗi phân tán và phần lớn page dữ liệu còn hợp lệ, hướng trích xuất/tái cấu trúc có thể khả thi hơn nhiều so với việc chờ một decryptor.

Vì sao cấu trúc Page / Extent tạo ra cơ hội trích xuất?

Theo kiến trúc SQL Server, file dữ liệu .mdf/.ndf được chia thành các page 8 KiB; một extent gồm 8 page liên tiếp, tổng 64 KiB. Vì dữ liệu, index và metadata nằm trên nhiều page khác nhau, một mẫu ransomware tác động theo các vùng rời rạc có thể để lại lượng lớn page còn đọc được. Đây là cơ sở để đánh giá khả năng trích xuất thay vì chỉ nhìn trạng thái “SQL Server không attach được”. ^[5]

Nhưng cấu trúc còn lại phải được hiểu theo quan hệ. Một page dữ liệu nguyên vẹn có thể vẫn mất ngữ cảnh nếu page chain, allocation metadata, LOB page hoặc cấu trúc phụ thuộc khác đã bị phá hỏng. Vì vậy, “byte đọc được” không bằng “dữ liệu nghiệp vụ dùng được”.

Recovery không làm trực tiếp trên file gốc

Hồ sơ #1326 mô tả quy trình ở mức đủ để kiểm chứng nhưng không công khai các kỹ thuật độc quyền, pattern nội bộ hay công cụ proprietary của TUNGTEK.

Bảo toàn hiện trạng: Tạo working copy; tránh attach/repair/ghi đè trực tiếp lên nguồn ban đầu.

Lập bản đồ vùng ảnh hưởng: Đánh giá pattern biến đổi và các cấu trúc SQL Server còn có thể sử dụng.

Trích xuất có chọn lọc: Đọc các Page/Extent còn khả dụng, cô lập vùng lỗi và ưu tiên dữ liệu nghiệp vụ.

Reconstruction: Tái cấu trúc trên môi trường SQL Server sạch; xử lý quan hệ dữ liệu trong phạm vi có thể.

Validation: Kiểm tra bằng SQL Server, ứng dụng BRAVO và quy trình làm việc thật trước khi nghiệm thu.

Điểm mạnh nhất của Ticket #1326: Validation bằng chính BRAVO

Hồ sơ đặt điều kiện rõ: khách hàng kiểm tra trực tiếp dữ liệu phục hồi trên máy chủ TUNGTEK trước nghiệm thu. Đối với BRAVO, việc kiểm tra được thực hiện thông qua phối hợp cài đặt/cấp phép tạm thời và quy trình cần thiết theo sự ủy nhiệm của khách hàng.

Validation kỹ thuật

Database phải đủ điều kiện để truy xuất ổn định trên môi trường SQL Server sạch, không chỉ “nhìn thấy file”.

Validation nghiệp vụ

Người dùng/đại diện phần mềm BRAVO kiểm tra dữ liệu thật; kết quả mới là cơ sở bàn giao và nghiệm thu.

Đây cũng là lý do TUNGTEK luôn tách hai khái niệm: tỷ lệ cấu trúc/byte còn khả dụng và tỷ lệ dữ liệu nghiệp vụ thực sự dùng được.

Tóm tắt Ticket 1326 dạng social

Bộ hình được bố trí theo hai lớp: tư liệu thực tế để tạo độ tin cậy, và infographic để người đọc nắm nhanh kết quả kỹ thuật.

.WEX: dấu hiệu rất đáng chú ý của WeaXor/Mallox — nhưng không nên gán family chỉ từ extension

LevelBlue SpiderLabs công bố ngày 17/04/2025 rằng WeaXor là một phiên bản sửa đổi của Mallox và các mẫu họ thu thập gắn hậu tố .wex vào file bị mã hóa. SpiderLabs đồng thời ghi nhận C2, ransom note “RECOVERY INFO”, webchat Onion và một số hash mẫu. ^[1]

Với hệ sinh thái Mallox/TargetCompany, Unit 42 và SentinelOne đều ghi nhận trọng tâm tấn công vào Microsoft SQL Server / ODBC exposed ra Internet, bao gồm brute force mật khẩu yếu, PowerShell/WMI sau khi truy cập được, cố dừng dịch vụ SQL, xóa cơ chế khôi phục và trong một số chiến dịch có hành vi đánh cắp dữ liệu trước khi mã hóa. ^{[2] [3]}

Trend Micro cũng liệt kê .mdf, .sql, file backup và nhiều định dạng hạ tầng trong nhóm extension mà các mẫu TargetCompany/Mallox nhắm tới, đồng thời ghi nhận hành vi dừng nhiều service SQL Server. ^[4]

Phân loại cho Ticket #1326: tên file *.mdf.wex phù hợp mạnh với dấu hiệu WeaXor/Mallox đã được SpiderLabs mô tả, nhưng không nên tuyên bố attribution tuyệt đối chỉ từ extension. Muốn khẳng định family cần đối chiếu thêm ransom note, malware sample/hash, C2, log endpoint, process tree và artefact host.

IOC WeaXor được SpiderLabs công bố

Các chỉ báo dưới đây là IOC công khai được LevelBlue SpiderLabs quan sát trong chiến dịch WeaXor năm 2025. Không đồng nghĩa chúng xuất hiện trong Ticket #1326 nếu chưa được đối chiếu log/mẫu mã độc. Dùng cho Threat Hunting, SIEM/EDR và kiểm tra hồi cứu.

IOC / Artefact và ghi chú:

Extension: .wex — Được SpiderLabs gắn với WeaXor.

Ransom note: RECOVERY INFO — Chứa victim key ID, webchat và email theo mô tả công khai.

IPv4: 193.143.1[.]139 — C2 được quan sát trong mẫu WeaXor.

URL: 193.143.1[.]139/Ujdu8jjooue/biweax.php — Đã defang để tránh truy cập nhầm.

Onion: weaxorpemwzoxg5cdvvfd77p3qczkxqii37ww4foo2n4jcft3mytbpyd[.]onion — Webchat/infra được SpiderLabs ghi nhận.

SHA-256: 7d1de2f4ab7c35b53154dc490ad3e7ad19ff04cfaa10b1828beba1ffadbaf1ab — Mẫu WeaXor công khai.

SHA-256: d682d5afbbbd9689d5f30db8576b02962af3c733bd01b8f220ff344a9c00abfd — Mẫu WeaXor công khai.

SHA-256: 40b75aa3c781f89d55ebff1784ff7419083210e01379bea4f5ef7e05a8609c38 — Mẫu WeaXor công khai.

SHA-256: 7f2319f4e340b3877e34d5a06e09365f6356de5706e7a78e367934b8a58ed0e7 — Mẫu WeaXor công khai.

Artefact nên hunt thêm trên máy chủ SQL

Authentication: chuỗi đăng nhập thất bại bất thường vào SQL/remote service; tài khoản lạ hoặc đăng nhập ngoài giờ.

Process: PowerShell, WMIC/WMI, shell/batch phát sinh gần thời điểm sự cố.

Impact: dừng service SQL, xóa shadow copy hoặc thay đổi cấu hình recovery.

Network: outbound tới IOC công khai hoặc hạ tầng mới xuất hiện trước sự cố.

Forensic: ransom note, executable/script lạ trong TEMP, Desktop, thư mục dữ liệu.

Log integrity: dấu hiệu log Windows bị clear hoặc telemetry bị gián đoạn.

Điều cần làm ngay với SQL Server / ERP sau một ca .WEX

Giảm bề mặt tấn công

Không public SQL Server/1433 trực tiếp nếu không thật sự cần; ưu tiên VPN/ZTNA, allowlist IP và phân đoạn mạng.

Rà lại RDP, ODBC, VPN, web admin và các dịch vụ exposed khác — affiliate ransomware có thể thay đổi vector.

Tài khoản & quyền

Loại bỏ mật khẩu yếu, tài khoản dùng chung và quyền admin không cần thiết; áp dụng MFA ở lớp truy cập từ xa khi hỗ trợ.

Tách credential của hệ thống backup khỏi credential domain/SQL vận hành thường ngày.

Backup thực sự có thể phục hồi

Duy trì bản backup offline/immutable, tách khỏi production; định kỳ test restore cả SQL Server lẫn ứng dụng BRAVO.

Không coi NAS cùng domain/cùng credential với server là “bản backup chống ransomware” hoàn chỉnh.

Detection

Cảnh báo khi SQL service bị stop bất thường, có PowerShell/WMIC đáng ngờ, xóa shadow copy, hoặc tốc độ rename/write file tăng đột biến.

Đẩy log quan trọng sang nơi lưu trữ độc lập để phục vụ DFIR ngay cả khi máy chủ bị xóa log.

Đừng vội “repair” file gốc khi chưa biết ransomware đã làm gì

Một database bị gắn đuôi ransomware không phải lúc nào cũng đồng nghĩa 100% nội dung đã thành ciphertext, nhưng cũng không thể đánh giá bằng mắt thường hoặc chỉ dựa vào việc đổi lại extension. Giữ nguyên source, tạo working copy, lập RFC và đo mức ảnh hưởng trước khi quyết định hướng Recovery thường là lựa chọn an toàn hơn.

TUNGTEK không xem “attach được database” là đích cuối. Đích cuối là dữ liệu nghiệp vụ được kiểm tra, đối chiếu và sử dụng trở lại. Kinh nghiệm tích lũy từ Mallox chính là một trong những nền tảng giúp TUNGTEK bước vào WEX với hiệu suất Recovery cao hơn.

Threat Intelligence & tài liệu kỹ thuật

1. LevelBlue SpiderLabs — “Proton66 Part 2: Compromised WordPress Pages and Malware Campaigns”, 17/04/2025. Xác định WeaXor là biến thể sửa đổi của Mallox, gắn .wex, công bố C2, Onion và SHA-256. Mở nguồn.

2. Palo Alto Networks Unit 42 — “Threat Group Assessment: Mallox Ransomware”. Ghi nhận Mallox nhắm MS-SQL không an toàn, brute force, PowerShell, WMI, dừng SQL service, xóa shadow copies và double extortion. Mở nguồn.

3. SentinelOne — “Mallox Resurrected | Ransomware Attacks Exploiting MS-SQL Continue to Burden Enterprises”, cập nhật 27/04/2025. Mô tả RaaS, MS-SQL/ODBC exposure, brute force, PowerShell/WMIC và payload Mallox gần đây. Mở nguồn.

4. Trend Micro Threat Encyclopedia — TargetCompany/Mallox. Ghi nhận .mdf, .sql và nhiều file hạ tầng là mục tiêu; có hành vi dừng các service liên quan SQL Server. Mở nguồn.

5. Microsoft Learn — “Page and Extent Architecture Guide – SQL Server”. Page 8 KiB; một extent gồm 8 page liên tiếp, tổng 64 KiB. Mở nguồn.

Dữ liệu case study lấy từ hồ sơ nội bộ Ticket #1326 và tài liệu nghiệm thu. Thông tin định danh khách hàng, tài khoản, hạ tầng, đường dẫn và chi tiết kỹ thuật nhạy cảm đã được lược bỏ/ẩn hóa. Các tên công ty/tên file có khả năng nhận diện được thay bằng tên giả định như ABC để bảo vệ khách hàng.

Cần đánh giá nhanh một MDF/LDF bị ransomware?

TUNGTEK có thể thực hiện RFC trên mẫu dữ liệu để xác định mức ảnh hưởng, khả năng trích xuất và hướng Validation trước khi quyết định Recovery toàn bộ.

TRecovery by TUNGTEK · CuuDuLieuMaHoa.com
Hotline/Zalo: 0963 509 115

Chỉ tính phí khi có dữ liệu dùng được. Không mất phí kiểm tra nếu không làm.

Bài gốc: Ticket #1326 – BRAVO .WEX, TRecovery by TUNGTEK

Gần đây, có những khung giờ chúng tôi nhận nhiều yêu cầu Ransomware gần như đồng thời. Một tin nhắn báo NAS của khách hàng bị mã độc mã hóa. Một tin khác hỏi hệ thống đang dính ransomware .PIZ và liệu dữ liệu có thể lấy lại được hay không. Khi lịch xử lý đang kín, câu trả lời đôi khi chỉ có thể là: “Cho em một chút thời gian, em nhắn lại sớm.”

Điều cần nói ngay: việc TUNGTEK “quá tải Case Ransomware” không phải thành tích để khoe. Với chúng tôi, mỗi Case mới đồng nghĩa với một doanh nghiệp đang ngừng việc, một hệ thống có thể đang mất quyền truy cập dữ liệu, một đội IT chịu áp lực và một bài toán phục hồi mà thời gian thường được tính bằng giờ.

1. Một buổi trưa, nhiều Case cùng lúc

Những ảnh chụp màn hình đi kèm bài viết này khá đơn giản: hai cuộc trao đổi khác nhau, hai tình huống khác nhau, nhưng cùng một chủ đề. Một bên là NAS bị mã hóa. Một bên là ransomware có đuôi .PIZ. Cả hai đều hỏi câu rất quen thuộc: “Có hỗ trợ cứu dữ liệu lại được không?”

Câu hỏi chỉ mất vài giây để gửi đi, nhưng phía sau câu trả lời lại là cả một chuỗi công việc: xác minh tình trạng, phân loại mức độ khẩn cấp, kiểm tra môi trường, xác định tài sản nào quan trọng nhất, xem còn Backup hay Snapshot nào sống sót, đánh giá cấu trúc dữ liệu bị tác động, rồi mới quyết định hướng khôi phục / trích xuất dữ liệu mã hóa phù hợp.

Với dữ liệu doanh nghiệp, đặc biệt là SQL Server, ERP, file server, máy ảo, NAS hay SAN, chúng tôi không muốn trả lời theo kiểu “được” hoặc “không được” chỉ dựa vào phần mở rộng của file. Một đuôi file có thể gợi ý, nhưng không đủ để kết luận toàn bộ tình trạng. Hai máy cùng đuôi ransomware vẫn có thể có cấu trúc hư hại, lịch sử ghi đè, dung lượng, Backup và khả năng phục hồi rất khác nhau.

2. “Quá tải” không phải là tin vui

Trong ngành Recovery, nhiều Case không có nghĩa thị trường “tốt”. Ngược lại, nó thường phản ánh một điều: Backup và phòng thủ ở đâu đó đã không hoạt động đúng vào thời điểm cần nhất.

Chúng tôi hiểu cảm giác khi một doanh nghiệp phải gọi hỗ trợ Ransomware. Đây hiếm khi là một yêu cầu IT thông thường. Có thể kế toán đang dừng, ERP không mở được, phòng khám không truy cập hồ sơ, nhà máy không chạy phần mềm sản xuất, hoặc toàn bộ thư mục dùng chung trên NAS đã đổi tên trong vài chục phút.

Lúc đó, người quản trị không chỉ chịu áp lực kỹ thuật. Họ còn phải trả lời Ban Giám Đốc, các phòng ban, khách hàng và đôi khi là đối tác. Vì vậy chúng tôi càng không muốn biến Ransomware Recovery thành một thông điệp quảng cáo kiểu “cứ bị rồi mang qua”.

Recovery là tuyến cuối.
Backup và Defense mới phải là tuyến đầu.

3. Ransomware Recovery không phải một nút bấm

Khi số lượng yêu cầu tăng, điểm nghẽn không chỉ nằm ở “máy có đủ mạnh không”. Recovery là công việc tiêu tốn cả tài nguyên lưu trữ, thời gian I/O lẫn con người. Có Case cần hàng chục terabyte dung lượng tạm để tạo bản sao làm việc. Có Case phải ưu tiên một vài file database trước rồi mới đến phần còn lại. Có Case cần giữ nguyên chứng cứ để phục vụ điều tra.

🔎 Triage ban đầuXác định loại hệ thống, phạm vi bị ảnh hưởng, thời điểm sự cố, ransomware note, extension, backup/snapshot và dữ liệu nào là ưu tiên số 1.

🧪 RFC – Ransomware Fast CheckĐánh giá nhanh mẫu dữ liệu và khả năng tiếp cận. RFC giúp định hướng kỹ thuật, không phải lời hứa chắc chắn về kết quả cuối.

💾 Bảo toàn nguồnHạn chế ghi thêm lên ổ đĩa/NAS/VM bị ảnh hưởng. Khi cần, tạo bản sao làm việc thay vì thử nghiệm trực tiếp trên dữ liệu gốc.

✅ Xác minh dữ liệu dùng đượcFile “mở được” chưa chắc đã đủ. Database cần kiểm tra logic, ứng dụng cần test, và dữ liệu ưu tiên phải được xác nhận theo nhu cầu thực tế của khách hàng.

Chính vì vậy, khi nhiều Case cùng đến, chúng tôi phải triage theo mức độ ảnh hưởng thực tế: hệ thống nào đang dừng hoàn toàn, dữ liệu nào phục vụ vận hành chính, có Backup thay thế hay không, và khách hàng cần khôi phục phần nào trước.

4. Vì sao các Case thường dồn vào cùng lúc?

Ransomware không “đặt lịch” với đội IT. Nhiều cuộc tấn công được kích hoạt ngoài giờ, vào cuối tuần hoặc trong khung thời gian ít người giám sát. Đến khi người dùng bắt đầu làm việc, các triệu chứng mới lộ rõ và hàng loạt yêu cầu hỗ trợ xuất hiện.

Một điểm chúng tôi gặp khá thường xuyên là doanh nghiệp có Backup nhưng Backup vẫn nằm trong cùng miền rủi ro: cùng hệ thống quyền, cùng mạng, cùng tài khoản quản trị, cùng NAS, hoặc repository luôn online. Khi kẻ tấn công đã có quyền đủ cao, Backup có thể trở thành mục tiêu tiếp theo.

Vì thế, câu “có Backup” cần được đổi thành những câu cụ thể hơn: Backup có offline hoặc immutable không? Tài khoản Backup có tách khỏi tài khoản Domain/Admin thường ngày không? Bản sao gần nhất đã từng restore thử chưa? Nếu toàn bộ máy chủ chính mất, đội IT có biết phải dựng lại dịch vụ theo thứ tự nào không?

5. Nếu đang bị Ransomware và phải chờ tiếp nhận: làm gì trước?

Trong thời điểm đội Recovery đang xử lý nhiều Case, vài hành động ban đầu của khách hàng có thể giúp bảo toàn thêm cơ hội phục hồi. Mục tiêu là ngăn lan rộng và giảm ghi đè, không phải tự thử mọi công cụ tìm thấy trên Internet.

Nên làm

• Cách ly hệ thống bị ảnh hưởng khỏi mạng nếu vẫn còn nguy cơ lây lan hoặc mã hóa tiếp.

• Ngừng các tác vụ ghi không cần thiết lên NAS, volume, datastore hoặc ổ đĩa chứa dữ liệu bị ảnh hưởng.

• Giữ lại ransom note, tên file lạ, extension, log và thông tin thời điểm phát hiện.

• Ghi lại máy nào bị trước, máy nào bị sau và các tài khoản quản trị/remote access có liên quan.

• Xác định ngay dữ liệu ưu tiên: database nào, thư mục nào, VM nào, dung lượng khoảng bao nhiêu.

• Kiểm tra Backup theo hướng an toàn: có bản offline, immutable, snapshot hoặc offsite còn nguyên không.

• Nếu hệ thống ảo hóa/phức tạp, trao đổi trước khi tắt hàng loạt host hoặc xóa snapshot.

Không nên làm

• Không Format, Initialize hoặc tạo lại filesystem trên thiết bị nguồn chỉ để “thử cho nhận lại ổ”.

• Không cài lại Windows lên chính ổ đang chứa dữ liệu cần Recovery.

• Không xóa ransom note, log hay các artefact chỉ vì “trông nguy hiểm”.

• Không chạy hàng loạt decryptor/repair tool không rõ nguồn trực tiếp trên dữ liệu gốc.

• Không chép thêm nhiều dữ liệu mới vào volume đang cần trích xuất.

• Không dựa duy nhất vào phần mở rộng file để kết luận ransomware family hay khả năng phục hồi.

Nếu dữ liệu là SQL/ERP hoặc dịch vụ lõi, hãy nói rõ ngay từ đầu: file nào quan trọng nhất, ứng dụng nào cần chạy trước, dung lượng bao nhiêu và deadline vận hành là gì. Điều đó giúp đội xử lý ưu tiên đúng mục tiêu thay vì cố “cứu tất cả” theo thứ tự không cần thiết.

6. Backup 3-2-1-1-0: đừng chỉ có “một bản copy”

Một trong những lý do chúng tôi liên tục nhắc về Backup là vì Recovery từ thiết bị đã bị mã hóa luôn có yếu tố bất định. Bản Backup sạch, đã kiểm thử Restore, gần như luôn là con đường tốt hơn so với phải phục hồi dữ liệu sau sự cố.

Nguyên tắcÝ nghĩa thực tế3 bản dữ liệu1 bản production + ít nhất 2 bản sao.2 loại lưu trữKhông để mọi bản sao phụ thuộc vào cùng một hệ thống/phần cứng.1 bản offsiteMột bản ở vị trí/hạ tầng khác với site chính.1 bản offline/immutableKhông thể bị mã hóa/xóa dễ dàng bằng cùng tài khoản hoặc cùng đường tấn công.0 lỗi chưa biếtBackup phải được verify và định kỳ restore thử. “Job Success” chưa đủ.

Quan trọng hơn cả công thức là tư duy: Backup phải sống sót khi Production bị chiếm quyền. Nếu ransomware có thể dùng chính tài khoản Admin để xóa cả production lẫn backup, thì số lượng job “Success” trước đó không còn nhiều ý nghĩa.

7. Phòng thủ tối thiểu cho NAS, Server và dữ liệu doanh nghiệp

Không có cấu hình nào bảo đảm “không bao giờ bị”. Nhưng có rất nhiều biện pháp cơ bản giúp giảm đáng kể khả năng một sự cố trở thành thảm họa toàn hệ thống.

• Bật MFA cho các điểm truy cập từ xa và tài khoản quản trị quan trọng.

• Không mở RDP/SMB/NAS management trực tiếp ra Internet nếu không thật sự cần.

• Tách tài khoản Backup khỏi tài khoản quản trị vận hành hằng ngày.

• Áp dụng least privilege: người dùng chỉ có quyền đúng với công việc.

• Phân đoạn mạng giữa user, server, backup, hypervisor và thiết bị quản trị.

• Vá sớm các dịch vụ Internet-facing, VPN, firewall, NAS và hypervisor.

• Giám sát đăng nhập bất thường, tạo tài khoản mới, tắt AV/EDR, xóa snapshot và xóa backup.

• Duy trì inventory: biết mình có máy nào, dịch vụ nào, dữ liệu nào và ai chịu trách nhiệm.

• Diễn tập Restore định kỳ thay vì chờ đến khi ransomware mới mở tài liệu hướng dẫn.

Đặc biệt với doanh nghiệp vừa và nhỏ, không nhất thiết phải mua ngay một hệ thống phòng thủ cực kỳ phức tạp. Làm đúng những thứ cơ bản, quản trị quyền chặt, có Backup thật sự tách biệt và biết cách Restore đã tốt hơn rất nhiều so với một hệ thống có nhiều sản phẩm nhưng không ai kiểm tra chúng còn hoạt động hay không.

8. TUNGTEK cũng phải thay đổi cách tiếp nhận Case

Khi lượng yêu cầu tăng, phía Recovery cũng phải có kỷ luật vận hành tốt hơn. Chúng tôi đang chuẩn hóa việc tiếp nhận để giảm thời gian hỏi đi hỏi lại và giúp khách hàng cung cấp đúng thông tin ngay từ đầu.

Quy trình mà chúng tôi ưu tiên gồm: ghi nhận Case, yêu cầu mô tả phạm vi, xác định dữ liệu ưu tiên, thu thập mẫu an toàn cho RFC khi phù hợp, xác định thiết bị/hệ thống nguồn, tình trạng Backup và deadline vận hành. Với Case lớn, việc này quan trọng hơn rất nhiều so với việc nhắn một câu “gửi file qua xem thử”.

Chúng tôi cũng cố gắng minh bạch một điều: khi đang kín lịch, khách hàng có thể phải chờ một khoảng thời gian ngắn để được đánh giá đúng. Thà nói rõ “đang xử lý Case, sẽ phản hồi vào khung giờ cụ thể” còn hơn trả lời vội rồi đưa ra kỳ vọng không chính xác.

9. Vì sao chúng tôi làm No.Ransomware.VN?

Nếu chỉ tập trung vào Recovery, chúng tôi sẽ luôn đứng ở cuối chuỗi sự cố. Vì vậy No.Ransomware.VN được dùng như một nơi chia sẻ ngược lại những gì rút ra từ các Case: cảnh báo, Backup, phòng thủ, dấu hiệu cần chú ý và các bài học có thể áp dụng trước khi ransomware xảy ra.

Mục tiêu rất đơn giản: nếu một bài viết về Backup khiến một doanh nghiệp tạo thêm bản immutable; nếu một bài về MFA khiến một quản trị viên khóa lại remote access; nếu một checklist khiến ai đó thử Restore trước khi cần đến nó — thì giá trị đó lớn hơn việc chúng tôi nhận thêm một Case Recovery.

Đề nghị rất thực tế: dành một buổi để vào No.Ransomware.VN, rà lại Backup và các điểm phòng thủ của hệ thống. Đừng đợi đến lúc file đã đổi đuôi mới bắt đầu hỏi: “Backup của mình đang nằm ở đâu?”

10. Kết: Đừng biến Recovery thành chiến lược Backup

Chúng tôi vẫn sẽ tiếp tục làm Ransomware Recovery, vẫn phân tích những Case khó, vẫn tìm cách trích xuất dữ liệu mã hóa khi còn cơ hội. Nhưng nếu phải chọn một thông điệp cho bài viết này, nó không phải là “TUNGTEK đang rất nhiều Case”.

Thông điệp là: Ransomware đang tạo ra quá nhiều tình huống mà lẽ ra có thể giảm thiệt hại đáng kể nếu Backup và Defense được chuẩn bị trước.

Một bản Backup không kiểm tra Restore chưa phải là sự bảo đảm. Một NAS có snapshot nhưng snapshot dùng chung quyền quản trị vẫn chưa đủ. Một firewall có MFA nhưng tài khoản local cũ vẫn mở cũng chưa thể yên tâm. Và một dịch vụ Recovery, dù có kinh nghiệm đến đâu, cũng không nên là kế hoạch dự phòng duy nhất.

Backup trước. Phòng thủ trước.
Recovery chỉ nên xuất hiện khi mọi lớp trước đó đã không còn lựa chọn tốt hơn.

Tùng TEK — ghi chép từ thực tế tiếp nhận và xử lý Ransomware tại TUNGTEK.
Bài viết tập trung vào Backup, phòng thủ và quy trình Recovery; không dùng phần mở rộng file như căn cứ duy nhất để attribution ransomware family.

Sáng 17/09/2026, TUNGTEK điểm nhanh một số diễn biến ransomware đáng chú ý tại Việt Nam và quốc tế.

➖➖➖

🇻🇳 VIỆT NAM: TheGentlemen đưa Dang Invest Group lên leak-site

• Ngày 15/09, nhóm ransomware TheGentlemen tuyên bố tấn công Dang Invest Group và đe dọa công bố dữ liệu.

• Hiện thông tin chủ yếu xuất phát từ phía threat actor và các hệ thống theo dõi ransomware; chưa nên kết luận toàn bộ hệ thống doanh nghiệp đã bị mã hóa nếu chưa có xác nhận hoặc dữ liệu pháp chứng độc lập.

👉 Với các thông tin từ leak-site, TUNGTEK luôn khuyến nghị phân biệt rõ:

“Hacker tuyên bố tấn công” ≠ “Sự cố đã được xác nhận”.

➖➖➖

🔥 VMWARE vCENTER: RANSOMWARE ĐÃ KHAI THÁC CVE-2026-59310

• CISA cảnh báo lỗ hổng nghiêm trọng CVE-2026-59310 trên VMware vCenter đang được sử dụng trong các chiến dịch ransomware.

• Lỗ hổng liên quan vCenter Syslog Server, có khả năng dẫn tới thực thi mã từ xa. Đây là mục tiêu cực kỳ nhạy cảm vì vCenter thường nằm ngay ở tầng quản trị hạ tầng ảo hóa của doanh nghiệp.

⚠️ Nếu doanh nghiệp đang vận hành VMware, đây là hạng mục nên kiểm tra bản vá + hunting dấu hiệu xâm nhập ngay, không chỉ đơn thuần cập nhật rồi xem như hoàn tất.

➖➖➖

👿 QILIN ĐI QUA CISCO FIREWALL MANAGEMENT CENTER

• Cisco ghi nhận các hoạt động khai thác Cisco Secure FMC, trong đó cluster UAT-11988 có chiến thuật phù hợp với hoạt động của Qilin ransomware.

• Sau khi có quyền truy cập, attacker thực hiện reconnaissance, thu thập credential, thiết lập tunnel, lựa chọn endpoint mục tiêu, vô hiệu hóa công cụ bảo mật rồi triển khai ransomware.

👉 Điểm đáng chú ý:

Ransomware ngày nay không bắt đầu ở lúc file đổi đuôi.

Khi người dùng nhìn thấy file bị mã hóa, attacker có thể đã tồn tại trong hệ thống từ trước — lấy tài khoản, dò Active Directory, kiểm tra backup và chuẩn bị đường lui.

➖➖➖

🧿 GÓC NHÌN TỪ TUNGTEK

Với một sự cố ransomware, việc đầu tiên không nhất thiết là hỏi:

❌ “Có tool trích xuất chưa?”

❌ “Hacker đòi bao nhiêu tiền?”

❌ “Có nên mua Key không?”

Mà nên xác định:

• Hacker đã đi vào từ đâu?

• Bao nhiêu Server/NAS/VM bị tác động?

• Backup còn an toàn không?

• Dữ liệu đã bị xóa, ghi đè hay exfiltration chưa?

• File mã hóa còn đủ cấu trúc để Recovery không?

• Việc mua Key từ hacker còn thực sự có ý nghĩa hay không?

👿 TUNGTEK – Ransomware Recovery hỗ trợ RFC – Ransomware Fast Check để đánh giá nhanh hiện trạng dữ liệu trước khi doanh nghiệp quyết định bước xử lý tiếp theo.

RFC miễn phí — ưu tiên đánh giá kỹ thuật trước, quyết định sau.

✅ Không cọc, không thanh toán trước.

✅ Chỉ tính phí khi có dữ liệu dùng được.

✅ Tập trung vào trích xuất dữ liệu mã hóa, không hứa hẹn dựa trên cảm tính.

🌐 CuuDuLieuMaHoa.com

🛡️ No.Ransomware.VN

➖➖➖

📅 Thứ Năm, 17/09/2026

#TUNGTEK #Ransomware #RansomwareRecovery #CuuDuLieuMaHoa #NoRansomwareVN #CyberSecurity #ThreatIntelligence #Qilin #VMware #vCenter #CiscoFMC #IncidentResponse #DataRecovery

➖➖➖

• Chỉ trong thời gian ngắn, TUNGTEK tiếp nhận 2 trường hợp doanh nghiệp bị Ransomware PIZ, dữ liệu quan trọng bị mã hóa và hoạt động vận hành bị ảnh hưởng.

• Với Ransomware, đừng vội format, cài lại máy hay thao tác trực tiếp lên dữ liệu gốc. TUNGTEK ưu tiên kiểm tra hiện trạng, xác định chủng ransomware và đánh giá khả năng trích xuất dữ liệu mã hóa trước khi xử lý.

➖

🛡️ No.Ransomware.VN

• Tra cứu thông tin Ransomware và Decryptor chính thống nếu chủng mã đã có công cụ hỗ trợ.

• Hướng dẫn phòng chống và xây dựng Backup theo nguyên tắc 3-2-1-1-0: nhiều bản sao, nhiều loại thiết bị, có bản sao ngoài hệ thống, có bản Offline/Immutable và 0 lỗi sau khi kiểm tra phục hồi.

• Backup đúng cách vẫn là lớp phòng thủ quan trọng nhất khi Ransomware xảy ra.

➖

🌐 CuuDuLieuMaHoa.com | No.Ransomware.VN

• Không cọc – không thanh toán trước.

• Không có dữ liệu dùng được – không mất phí.

🆃🆄🅽🅶🆃🅴🅺 0963509115

📅 Thứ Tư, 16/09/2026

#TUNGTEK #NoRansomwareVN #CuuDuLieuMaHoa #RansomwareRecovery #Ransomware #PIZ #Decryptor #Backup32110 #CyberSecurity

➖➖➖

• Với sự cố máy chủ, đặc biệt khi liên quan ransomware, dữ liệu mã hóa hoặc hệ thống ngừng hoạt động, thời gian phản ứng ban đầu rất quan trọng. TUNGTEK ưu tiên bảo toàn hiện trạng, đánh giá nhanh mức độ ảnh hưởng và triển khai dịch vụ Ransomware Recovery / trích xuất dữ liệu mã hóa theo từng tình huống thực tế.

• Không Có Dữ Liệu Không Mất Phí – tập trung vào kết quả dữ liệu dùng được, không hứa hẹn quá khả năng kỹ thuật.

• Một số keyword lien quan: IMHOTEP14, Misa, Database, BAK, Hype-V, Server HP 380DL, RAID5

🆃🆄🅽🅶🆃🅴🅺

📞 0963 509 115

🌐 CuuDuLieuMaHoa.com • No.Ransomware.VN

📅 Thứ Hai, 14/09/2026

---

#TUNGTEK #RansomwareRecovery #CuuDuLieuMaHoa

#NoRansomwareVN #ServerRecovery #DataRecovery

#UngCuuSuCo #Ransomware

• Trong quá trình kiểm tra một trường hợp thực tế, TUNGTEK ghi nhận file có tên dạng .bak.rmallox.Peter và Windows nhận diện phần mở rộng cuối là .Peter. Đây là dấu hiệu rất đáng chú ý vì dữ liệu có thể đã trải qua nhiều lần tác động, đổi extension hoặc nhiều lớp mã hóa khác nhau.

• Với những trường hợp như vậy, khó khăn không chỉ nằm ở việc “file bị mã hóa”. Kỹ thuật viên TRecovery cần xác định thứ tự tác động lên dữ liệu: ransomware nào can thiệp trước, ransomware nào xuất hiện sau, dữ liệu gốc đã bị thay đổi bao nhiêu lần và phần nào của file còn giữ được cấu trúc có thể khai thác.

• Ví dụ, nếu một file đã bị ransomware thứ nhất mã hóa rồi tiếp tục bị ransomware thứ hai xử lý, việc phục hồi không thể đơn giản bằng cách loại bỏ extension. Ngay cả khi có công cụ phù hợp với một chủng, lớp dữ liệu phía dưới vẫn có thể đang ở trạng thái mã hóa hoặc hư hỏng do lần tấn công trước đó.

• Ngoài nội dung file, quá trình phân tích còn phải kiểm tra header, footer, entropy, kích thước file, pattern mã hóa, metadata, MFT/file system, shadow copy, backup, vùng dữ liệu đã xóa và các bản sao còn tồn tại trên thiết bị lưu trữ. Đây là lý do TUNGTEK luôn ưu tiên bảo toàn hiện trạng trước khi thử bất kỳ công cụ giải mã hay sửa file trực tiếp nào.

• Một điểm cần lưu ý: chỉ từ tên file .rmallox.Peter chưa đủ để kết luận tuyệt đối rằng hai ransomware độc lập đã lần lượt mã hóa cùng một file. Muốn xác nhận cần đối chiếu thêm ransom note, sample mã độc, log hệ thống, timestamp, IOC và cấu trúc dữ liệu bên trong file. Trong Ransomware Recovery, xác định đúng cơ chế tấn công quan trọng hơn việc đoán tên chủng từ extension.

• Nếu hệ thống vừa phát hiện ransomware, việc cần làm đầu tiên là ngắt kết nối mạng, dừng ghi dữ liệu mới và không tự ý format, rebuild RAID, restore đè hoặc chạy hàng loạt công cụ sửa chữa. Một thao tác sai có thể làm mất những vùng dữ liệu còn khả năng trích xuất. Đây là chú ý thực tế rất quan trọng quyết định đến tính toàn vẹn của dữ liệu.

👿 CuuDuLieuMaHoa.com by TUNGTEK tập trung kiểm tra hiện trạng, xác định mức độ mã hóa và đánh giá khả năng trích xuất dữ liệu dùng được trước khi triển khai phương án phục hồi.

Chỉ tính phí khi có dữ liệu dùng được.

Không cọc, không thanh toán trước.

☎️ 0963509115

📅 Thứ Bảy, 12/09/2026

#TUNGTEK #TEKPost #CuuDuLieuMaHoa #Ransomware #RansomwareRecovery #Mallox #Peter #CyberSecurity #DataRecovery #IncidentResponse

➖➖➖

• Trong bối cảnh lừa đảo và ransomware ngày càng tinh vi, TUNGTEK tin rằng trung thực và minh bạch phải là nền tảng của dịch vụ Ransomware Recovery.

• Chúng tôi tập trung đánh giá khách quan phương án ứng cứu, xác định đúng khả năng phục hồi, rủi ro và chi phí; từ đó lựa chọn hướng xử lý phù hợp để giảm tối đa thiệt hại tài chính cho nạn nhân và doanh nghiệp.

• Không hứa quá khả năng. Không khai thác sự hoang mang của nạn nhân. Chỉ đưa ra phương án dựa trên dữ liệu và hiện trạng thực tế.

🆃🆄🅽🅶🆃🅴🅺 0963509115

➖➖➖

📅 10.09.2026

#TUNGTEK #RansomwareRecovery #IncidentResponse #DataRecovery #CyberSecurity #KOLSummit #DTA #DTAHCM

Một thử thách mới tại TUNGTEK Data Recovery: Microsoft Surface Laptop Model 1769 vẫn có thể bật lên logo Windows nhưng không hoàn tất quá trình khởi động và không tiếp cận được dữ liệu.

Điểm khó của thiết bị này là SSD/NVMe onboard, không thể tháo rời đơn giản như SSD M.2 thông thường. Bên cạnh nguy cơ lỗi đọc sâu hoặc SSD suy giảm, dữ liệu còn có thể được bảo vệ bởi BitLocker / Device Encryption.

Với Ticket 1328, nguyên tắc xử lý được ưu tiên:

Xác định tình trạng ổ → Image/Clone trước → Phân tích trên bản sao → Trích xuất dữ liệu.

Không cố sửa Windows, không CHKDSK và hạn chế tối đa thao tác ghi lên thiết bị nguồn. Mục tiêu quan trọng nhất vẫn là bảo toàn hiện trạng và tối đa cơ hội lấy lại dữ liệu có giá trị.

🆃🆄🅽🅶🆃🅴🅺 0963509115

➖➖➖

| Ngày 06 tháng 09 năm 2026, Chủ Nhật.

#MicrosoftSurface #SurfaceLaptop #Surface1769 #TrichXuatDuLieu #CuuDuLieu #DataRecovery #SSDRecovery #NVMeRecovery #BitLockerRecovery #TUNGTEK #Ticket1328

Ảnh hưởng phải đi cùng trách nhiệm và niềm tin số

Ngày 07/09/2026, TUNGTEK vinh dự được mời tham dự Hội nghị KOL toàn quốc lần thứ II - KOL Summit 2026 tại Thiskyhall Sala, TP. Hồ Chí Minh. Chủ đề “KOL với hành trình kiến tạo niềm tin số” chạm đúng vào một vấn đề mà TUNGTEK theo đuổi hằng ngày: công nghệ càng mạnh, trách nhiệm kiểm chứng và bảo vệ niềm tin số càng lớn.

• Sự kiện: KOL Summit 2026

• Thời gian: 08:00 - 11:00, Thứ Hai 07/09/2026

• Địa điểm: Thiskyhall Sala - Cổng D6/10 Mai Chí Thọ, P. An Khánh, TP. Hồ Chí Minh

KOL Summit 2026 đặt trọng tâm vào vai trò của người có ảnh hưởng trong kỷ nguyên AI, khi nội dung có thể được tạo, chỉnh sửa và lan truyền với tốc độ chưa từng có. Hai chuyên đề buổi sáng tập trung trực tiếp vào các vấn đề đang tác động đến môi trường số: “AI, thông tin sai lệch và khủng hoảng niềm tin” và “Ảnh hưởng số và tương lai sáng tạo”.

Với TUNGTEK, đây không chỉ là câu chuyện truyền thông. Trong lĩnh vực IT, Cloud, An Toàn Thông Tin, Ransomware Recovery hay Cứu Dữ Liệu Mã Hóa, một thông tin sai có thể dẫn đến quyết định kỹ thuật sai, làm thay đổi hiện trạng hệ thống, phá hỏng chứng cứ hoặc làm giảm cơ hội phục hồi dữ liệu.

Vì vậy, niềm tin số không phải một khẩu hiệu. Nó phải được xây dựng từ cách thu thập dữ kiện, kiểm chứng nguồn, phân biệt giả thuyết với kết luận và chịu trách nhiệm với nội dung đã công bố.

1. Kiểm chứng trước khi chia sẻ

Các thông tin liên quan đến lỗ hổng bảo mật, ransomware, tấn công mạng hoặc sự cố dữ liệu cần được đối chiếu từ nhiều nguồn đáng tin cậy trước khi công bố. Một ảnh chụp màn hình, một bài đăng trên diễn đàn hay một tuyên bố từ nhóm ransomware không tự động trở thành sự thật.

2. Phân biệt rõ dữ kiện và nhận định

IOC là IOC. Dấu hiệu nghi vấn là dấu hiệu nghi vấn. Kết luận phải có đủ căn cứ. TUNGTEK cố gắng thể hiện rõ đâu là dữ kiện đã xác minh, đâu là phân tích kỹ thuật và đâu vẫn là giả thuyết cần tiếp tục điều tra.

3. Không dùng nỗi sợ để câu tương tác

Cybersecurity vốn đã đủ đáng sợ. TUNGTEK không muốn biến ransomware, mất dữ liệu hay các cuộc tấn công mạng thành tiêu đề giật gân chỉ để tăng lượt xem. Điều người gặp sự cố cần nhất vẫn là thông tin chính xác và hướng xử lý đúng.

4. Tôn trọng dữ liệu và quyền riêng tư của khách hàng

Case thực tế là nguồn kiến thức rất giá trị, nhưng dữ liệu khách hàng, thông tin hệ thống và các yếu tố có thể nhận diện tổ chức phải được bảo vệ. Khi chia sẻ case study, TUNGTEK ưu tiên ẩn danh và chỉ công bố những dữ kiện thực sự cần thiết cho mục đích kỹ thuật, cảnh báo hoặc nghiên cứu.

5. Sử dụng AI có trách nhiệm

AI giúp tìm kiếm, tổng hợp, phân tích và trình bày thông tin nhanh hơn rất nhiều, nhưng AI không thay thế trách nhiệm kiểm chứng của con người. Với nội dung quan trọng, đặc biệt liên quan đến an ninh mạng và dữ liệu, TUNGTEK theo đuổi nguyên tắc: AI hỗ trợ - Con người kiểm chứng - Dữ kiện quyết định.

6. Sai thì sửa

Trong môi trường công nghệ thay đổi từng giờ, không ai có thể đảm bảo mọi nhận định ban đầu luôn chính xác tuyệt đối. Khi xuất hiện dữ kiện mới, TUNGTEK sẵn sàng cập nhật, sửa thông tin và công khai thay đổi thay vì cố bảo vệ một kết luận đã sai.

“AI hỗ trợ - Con người kiểm chứng - Dữ kiện quyết định.”

Một hướng thảo luận đáng chú ý của KOL Summit 2026 là thúc đẩy chuẩn mực hoạt động, trách nhiệm nghề nghiệp, kiểm chứng thông tin, bảo vệ dữ liệu cá nhân và sử dụng AI có trách nhiệm trong cộng đồng người có ảnh hưởng và nhà sáng tạo nội dung.

Trong thời đại AI và deepfake, giá trị của một KOL không nên chỉ được đo bằng follower, lượt xem hay reach. Một thước đo ngày càng quan trọng hơn là: có bao nhiêu người tin rằng thông tin mình chia sẻ đã được kiểm chứng?

Đó cũng là điều TUNGTEK muốn tiếp tục xây dựng. Không cần trở thành người nói lớn nhất. Chỉ cần cố gắng trở thành một nguồn thông tin mà khi cần, mọi người có thể tin cậy.

Cảm ơn và chúc may mắn ☘️

🆃🆄🅽🅶🆃🅴🅺 𝟎𝟗𝟔𝟑𝟓𝟎𝟗𝟏𝟏𝟓 | 06.09.26

Nguồn tham khảo

• Website chính thức KOL Summit 2026: kolsummit.vn

• Cổng thông tin KOL: kol.gov.vn

#TUNGTEK #KOLSummit2026 #NiemTinSo #KOL #AI #CyberSecurity #AnToanThongTin #RansomwareRecovery #CuuDuLieuMaHoa #DigitalTrust #ResponsibleAI #FactChecking

🚨 Sự cố Ransomware .hadar31: Backup SQL bị mã hóa, dấu vết nghi MedusaLocker3/FarAttack

Ngày 05/09/2026, TUNGTEK tiếp nhận thông tin một sự cố ransomware trên máy chủ Windows, trong đó nhiều file backup SQL .bak dung lượng khoảng 5,5 GB/file bị đổi thành:

*.bak.hadar31

Kẻ tấn công để lại RANSOM_NOTE.html, yêu cầu liên hệ qua các địa chỉ recovery2@salamati.vip và recovery2@amniyat.xyz, đồng thời đòi khoảng 7.000 USD bằng Bitcoin để cung cấp công cụ khôi phục.

Qua đối chiếu ransom note, phương thức liên hệ, cấu trúc phần mở rộng và các dấu vết hiện có, TUNGTEK đánh giá .hadar31 có khả năng cao thuộc nhánh MedusaLocker3/FarAttack hoặc một biến thể rất gần, tuy nhiên tên .hadar31 hiện vẫn cần thêm mẫu kỹ thuật để xác nhận chính xác.

Điểm đáng chú ý là nhiều file backup có cùng thời điểm thay đổi khoảng 01:58 ngày 05/09/2026, cho thấy giai đoạn mã hóa có thể đã diễn ra tập trung trong một khoảng thời gian ngắn. Máy chủ cũng xuất hiện dấu vết liên quan Google Drive, mở thêm một hướng kiểm tra version history hoặc bản sao cloud trước thời điểm xảy ra sự cố.

🔎 RFC – Ransomware Fast Check của TUNGTEK

Với các Ticket ransomware, TUNGTEK ưu tiên RFC – Ransomware Fast Check trước khi can thiệp sâu:

Bảo toàn hiện trạng → tạo bản sao/image → đánh giá miễn phí khả năng Trích Xuất Dữ Liệu → chỉ xử lý trên bản sao → xác minh dữ liệu dùng được trước khi tính phí.

Không vội format, restore, rename file hoặc chạy công cụ không rõ nguồn gốc trực tiếp trên dữ liệu gốc. Với ransomware, một thao tác sai có thể làm mất luôn phần dữ liệu vẫn còn khả năng cứu.

🛡️ CuuDuLieuMaHoa.com by TUNGTEK

Ransomware Recovery – Cứu Dữ Liệu Mã Hóa – Trích Xuất Dữ Liệu

Ưu tiên các hệ thống Server, NAS, RAID, Hyper-V, VMware, SQL Backup và dữ liệu doanh nghiệp.

➖➖➖

🌐 CuuDuLieuMaHoa.com | 📞 0963 509 115 | Không Có Dữ Liệu Không Mất Phí.

#Ransomware #Hadar31 #MedusaLocker #FarAttack #RansomwareRecovery #CuuDuLieuMaHoa #TrichXuatDuLieu #SQLBackup #DataRecovery #IncidentResponse #CyberSecurity #TUNGTEK #CuuDuLieuMaHoaCom

Chiếc này là đèn pin quân dụng Mỹ MX-991/U, kiểu đầu bẻ góc 90°, từng rất phổ biến trong quân đội Mỹ thời chiến tranh Việt Nam.

Trên thân vẫn còn rõ dấu G.T. Price Products, Inc. – Los Angeles, California. Nhìn lớp sơn bạc màu, vết xước, chỗ rỉ và cái công tắc cũ kỹ là biết em nó đã “ăn hành” không ít năm rồi.

Điều vui nhất là ngày xưa Mỹ mang đồ sang Việt Nam, mấy chục năm sau người Việt mình giữ lại làm đồ cổ 😏. Không cần đánh bóng quá mới. Với đồ như thế này, càng có patina, càng có câu chuyện.

Một chiếc đèn từng sinh ra để soi đường trong bóng tối, giờ lại được soi đèn chụp hình… đăng Facebook. 😄 Đồ cũ không chỉ có tuổi — đôi khi nó còn có cả lịch sử.

➖➖➖

| 02.09.26

#MX991U #DoCoQuanDung #MilitaryFlashlight #Militaria #VietnamWarEra #DoCo #SuuTamDoCo #KyVatLichSu #VintageMilitary #tungtek

🚨 TUNGTEK tiếp nhận một Ticket Ransomware đặc biệt khó khăn liên quan đến Y Tế | #TEKLink195

➖➖➖

TUNGTEK đang tiếp nhận một Ticket phục hồi dữ liệu bị mã hóa tại cơ sở khám chữa bệnh có dòng tiền phụ thuộc lớn vào thanh toán BHYT.

Sự cố lần này không chỉ gây mất quyền truy cập dữ liệu mà còn kéo theo nhiều áp lực thực tế: gián đoạn hoạt động khám chữa bệnh, chậm đối soát và thanh toán BHYT, công nợ thuốc kéo dài, áp lực chi trả lương nhân viên và duy trì vận hành.

🔍 Quy trình TUNGTEK ưu tiên xử lý

1️⃣ Bảo toàn hiện trạng

Không format, cài lại hoặc thực hiện thao tác có nguy cơ ghi đè dữ liệu.

2️⃣ Phân tích ransomware

Xác định dấu hiệu mã hóa, phạm vi ảnh hưởng, cấu trúc dữ liệu và khả năng phục hồi.

3️⃣ Đánh giá nguồn dữ liệu quan trọng

Ưu tiên Database, hồ sơ bệnh nhân, dữ liệu BHYT, dược – công nợ và kế toán.

4️⃣ Trích xuất dữ liệu khả dụng

Không chỉ tập trung vào việc “giải mã”, mà tìm mọi khả năng trích xuất những dữ liệu còn sử dụng được từ hệ thống bị ảnh hưởng.

5️⃣ Kiểm tra & xác thực dữ liệu.

Dữ liệu phục hồi phải mở được, đọc được và có giá trị thực tế trước khi bàn giao.

6️⃣ Hỗ trợ đưa hệ thống trở lại vận hành 🛡️

Sau khi cứu dữ liệu, tiếp tục đánh giá nguyên nhân và khuyến nghị phương án giảm nguy cơ tái diễn.

Trong những Ticket như thế này, dữ liệu không đơn thuần là những file trên máy chủ. Đó còn là dòng tiền, hoạt động khám chữa bệnh và khả năng duy trì cả một cơ sở.

🔐 Ransomware Recovery by TUNGTEK | CuuDuLieuMaHoa.com

➖➖➖.

| 31.08.26

#TUNGTEK #RansomwareRecovery #CuuDuLieuMaHoa #DataRecovery #BHYT #HealthcareIT #CyberSecurity #Ransomware #PhucHoiDuLieu

Anh Trung vừa giới thiệu cho TRecovery của TUNGTEK , vừa Cứu Dữ Liệu thành công trên USB 32G cho chị Vân nhanh chóng và chính xác.

---

Dù là may mắn cứu được lần này hay có thể được gọi vui là "thiên tài" hay "khó nhất thế giới" thì thực tế hàng tháng bên TUNGTEK mình vẫn còn rất nhiều Ticket không thể cứu. Thất bại là sự thật, do đó Sao Lưu Dữ Liệu đúng cách mới là cứu cánh cho dữ liệu.

---

| TUNGTEK cảm ơn a Trung & sẵn sàng chiết khấu cao cho anh ấy vì sự tín nhiệm trong công việc.

| Thông qua đó, TRecovery của TUNGTEK mình rất mong được hợp tác với tất cả mọi người trong lĩnh vực:

📌 Trích xuất dữ liệu ổ cứng HDD, SSD, SAS, SAN, Server, NAS....cho mọi trường hợp mất dữ liệu.

📌 Trích xuất dữ liệu bị Ransomware mã hóa cho thị trường Việt Nam & Quốc Tế.

📌 Sao lưu dữ liệu cho cá nhân & doanh nghiệp tuân thủ 3-2-1-1 với dung lượng hàng ngàn Terabyte.

Xin cảm ơn & hãy gọi cho TUNGTEK tôi qua 0963509115.

___

#tungtek #trecovery #cuudulieutop #tbackup

#cuudulieu #khoiphucdulieu #backup

➖➖

Đây là tín hiệu cho thấy ransomware vẫn đang diễn biến rất nhanh và không hề “hạ nhiệt”. Chỉ một tài khoản bị lộ, một dịch vụ mở sai cấu hình hoặc một máy chủ chưa được vá cũng có thể trở thành điểm khởi đầu khiến toàn bộ hệ thống bị mã hóa, gián đoạn vận hành và đẩy doanh nghiệp vào tình thế khẩn cấp.

Với ransomware, phát hiện sớm và bảo toàn hiện trạng có thể quyết định rất lớn đến khả năng phục hồi dữ liệu. Khi phát hiện dấu hiệu bất thường, nên cô lập hệ thống, hạn chế ghi thêm dữ liệu và lưu lại đầy đủ ransom note, log, file mẫu để phục vụ phân tích.

➖➖➖

🇻🇳 CuuDuLieuMaHoa.com by TUNGTEK – 0963509115

---

#Lock #Lockbit #Ransomware #RansomwareRecovery #DataRecovery #CuuDuLieuMaHoa #TRecovery #TUNGTEK #LockBit #CyberSecurity #IncidentResponse #DataProtection #Backup #Malware #AnToanThongTin

Qilin tiếp tục cho thấy mức độ hoạt động rất cao trong hệ sinh thái ransomware toàn cầu.

Chỉ riêng ngày 21/08/2026, hệ thống theo dõi leak-site ghi nhận Qilin vừa đưa hàng loạt tổ chức lên danh sách nạn nhân được tuyên bố, trong đó có iPic, Cinépolis, Quaker State Mexico, Gindre India, The Pendas Law Firm, Blake Services và một đơn vị được ghi tên Professional. Đây hiện vẫn là các tuyên bố từ phía Qilin, chưa đồng nghĩa tất cả sự cố đã được nạn nhân hoặc cơ quan độc lập xác nhận.

Với TRecovery by TUNGTEK, Qilin không phải một cái tên xa lạ.

Trong Ticket #962, TRecovery đã trực tiếp xử lý dữ liệu sau sự cố Qilin Ransomware tại Việt Nam, từ phân tích Disk, tái dựng LUN, trích xuất các bản backup ERP/SQL, phục hồi cấu trúc Database và kiểm tra dữ liệu sử dụng được. Case cụ thể này đạt mức dữ liệu phục hồi rất cao sau quá trình kiểm tra và xác thực thực tế.

Điểm đáng chú ý là hướng xử lý không chỉ phụ thuộc vào decryptor. Trong nhiều trường hợp ransomware, nếu Disk/LUN gốc vẫn được bảo toàn, dữ liệu còn tồn tại ở tầng storage vẫn có thể tạo ra cơ hội phục hồi rất đáng giá.

Qilin xuất hiện trở lại với hàng loạt nạn nhân mới là một lời nhắc rõ ràng:

Ransomware ngày càng mạnh hơn — nhưng khả năng phục hồi vẫn còn nếu doanh nghiệp dừng hệ thống đúng lúc, bảo toàn dữ liệu gốc và lựa chọn phương án xử lý phù hợp ngay từ đầu.

➖➖➖

🛡️ CuuDuLieuMaHoa.com by TUNGTEK - 0963509115

✅ Không có dữ liệu dùng được – không mất phí.

✅ Không cọc – không thanh toán trước.

📌 Link.TUNGTEK.com/192

#Ticket962 #TUNGTEK #TRecovery #CuuDuLieuMaHoa #Qilin #QilinRansomware #RansomwareRecovery #DatabaseRecovery #SQLRecovery #ERPRecovery #DataRecovery #IncidentResponse

Một chiến dịch tuyển dụng affiliate mới của Eclipse Ransomware đang thu hút sự chú ý trong cộng đồng Threat Intelligence.

Theo nội dung được chia sẻ từ một bài đăng theo dõi hoạt động trên dark web, nhóm Eclipse đang quảng bá chương trình mang tên:

“ONE SHOT — ONE HEAD”

Điểm đặc biệt của chương trình này là Eclipse sẵn sàng để affiliate giữ lại toàn bộ khoản tiền chuộc thành công từ nạn nhân đầu tiên, trước khi chuyển sang cơ chế chia sẻ doanh thu thông thường.

🔴 Những điều khoản đáng chú ý

Theo nội dung được công bố trong ảnh:

• Phí tham gia: 300 USD

• Khoản phí được Eclipse mô tả như một cơ chế nhằm sàng lọc những người thực sự có khả năng triển khai tấn công.

• Khoản tiền chuộc thành công đầu tiên: affiliate được giữ 100%.

• Sau chiến dịch đầu tiên, affiliate trở thành thành viên chính thức và bắt đầu áp dụng cơ chế chia doanh thu tiêu chuẩn của Eclipse.

• Eclipse tuyên bố sẽ cung cấp tỷ lệ chia sẻ doanh thu cạnh tranh cho affiliate.

• Nhóm cho biết họ không thu thêm một số khoản phí liên quan đến “hạ tầng” hoặc “phát triển”.

• Chương trình được quảng bá là ưu đãi chỉ áp dụng một lần.

• Kênh liên hệ được đề cập gồm TOX và Session, kèm quy trình xác minh trước khi tham gia.

⚠️ Một thay đổi đáng chú ý trong mô hình Ransomware-as-a-Service

Mô hình Ransomware-as-a-Service – RaaS không mới.

Thông thường, nhóm phát triển ransomware cung cấp mã độc, hạ tầng điều khiển, cổng thanh toán, hệ thống leak site và công cụ quản lý nạn nhân. Affiliate chịu trách nhiệm xâm nhập hệ thống doanh nghiệp và triển khai ransomware.

Khi nạn nhân thanh toán, tiền chuộc sẽ được chia giữa operator và affiliate theo một tỷ lệ đã thỏa thuận.

Điểm đáng chú ý trong chiến dịch lần này của Eclipse là việc hy sinh toàn bộ doanh thu từ nạn nhân đầu tiên để thu hút affiliate mới.

Nếu thông tin được công bố phản ánh đúng hoạt động của nhóm, đây có thể được xem như một hình thức “customer acquisition” trong thị trường tội phạm mạng: giảm lợi ích ngắn hạn để nhanh chóng mở rộng mạng lưới đối tác tấn công.

💰 “100% tiền chuộc đầu tiên” – chiến thuật tuyển người đáng lo ngại

Thông điệp của Eclipse tập trung rất mạnh vào yếu tố lợi nhuận. Nhóm nhấn mạnh rằng:

“First successful ransom — 100% yours.”

Tức là affiliate có thể giữ toàn bộ khoản tiền thu được từ vụ tấn công thành công đầu tiên. Điều này có thể làm giảm đáng kể rào cản tài chính đối với những đối tượng đã có khả năng Initial Access nhưng chưa tham gia một chương trình RaaS cụ thể.

Eclipse còn mô tả chiến dịch đầu tiên của affiliate như một dạng “business card” – danh thiếp, nhằm chứng minh năng lực trước khi trở thành thành viên chính thức.

Đây là một chi tiết đáng lưu ý về mặt Threat Intelligence: các nhóm ransomware ngày càng vận hành giống những tổ chức kinh doanh có cấu trúc, bao gồm tuyển dụng, marketing, chính sách hoa hồng, hỗ trợ kỹ thuật và cơ chế giữ chân affiliate.

🕵️ Eclipse không chỉ bán ransomware – họ đang xây dựng mạng lưới

Trong thông điệp tuyển dụng, Eclipse sử dụng khá nhiều ngôn ngữ mang tính quảng bá:

• nền tảng có lợi nhuận cao;

• ưu đãi cho affiliate mới;

• tỷ lệ chia sẻ doanh thu cạnh tranh;

• cơ chế xác minh thành viên;

• chương trình ưu đãi giới hạn;

• xây dựng “thương hiệu” cho affiliate thông qua vụ tấn công đầu tiên.

Điều này phản ánh xu hướng chuyên nghiệp hóa ngày càng rõ của hệ sinh thái ransomware. Một cuộc tấn công ransomware hiện đại thường không chỉ có một hacker duy nhất. Đằng sau một incident có thể tồn tại cả một chuỗi:

Initial Access Broker → Affiliate → Ransomware Operator → Data Leak Infrastructure → Negotiation → Cryptocurrency Payment

Vì vậy, khi một RaaS bắt đầu tích cực tuyển affiliate, các tổ chức phòng thủ cần coi đây là một tín hiệu cần theo dõi.

🔥 Vì sao doanh nghiệp Việt Nam cần lưu ý?

Việt Nam có một lượng lớn doanh nghiệp đang vận hành các hệ thống quan trọng như:

• ERP, SQL Server, Oracle Database, VMware ESXi, Hyper-V, NAS Synology, NAS QNAP, File Server, Backup Server, Domain Controller, hệ thống kế toán, dữ liệu sản xuất, hệ thống camera và lưu trữ tập trung…

Đây cũng chính là những mục tiêu có giá trị cao đối với ransomware. Rủi ro lớn nhất không đơn thuần nằm ở việc file bị mã hóa. Trong nhiều sự cố ransomware hiện nay, attacker có thể thực hiện chuỗi hành động:

Xâm nhập → leo thang đặc quyền → vô hiệu hóa bảo mật → đánh cắp dữ liệu → phá backup → mã hóa server → tống tiền.

Một số chiến dịch thậm chí ưu tiên phá hủy hoặc xóa backup trước khi ransomware được kích hoạt.

🛡️ Khi phát hiện ransomware, không nên vội vàng xử lý

Đối với hệ thống có dữ liệu quan trọng, thao tác sai sau sự cố đôi khi có thể làm giảm đáng kể khả năng phục hồi.

Doanh nghiệp nên ưu tiên:

1. Cô lập hệ thống bị ảnh hưởng

Ngắt kết nối mạng của máy chủ hoặc storage nghi bị xâm nhập nhưng cần cân nhắc trước khi shutdown đột ngột các hệ thống lưu trữ phức tạp.

2. Không format hoặc cài lại hệ điều hành

Việc cài lại Windows, reset NAS hoặc recreate RAID có thể ghi đè lên các vùng dữ liệu còn khả năng phục hồi.

3. Không chạy phần mềm recovery trực tiếp trên dữ liệu gốc

Với hệ thống RAID, NAS, VMFS, database hoặc volume dung lượng lớn, cần tạo bản sao forensic hoặc image trước khi phân tích sâu nếu điều kiện cho phép.

4. Bảo toàn ransom note và file mẫu

Ransom note, tên file bị mã hóa, extension, metadata và một số file mẫu có thể giúp nhận diện ransomware cũng như cơ chế mã hóa.

5. Kiểm tra backup một cách độc lập

Không nên mặc định rằng backup còn an toàn chỉ vì backup server vẫn đang online.

6. Đánh giá cả khả năng bị đánh cắp dữ liệu

Ransomware hiện đại thường kết hợp Encryption + Data Exfiltration + Extortion.

🧬 Ransomware Recovery không chỉ là “giải mã”

Trong thực tế ứng cứu, TUNGTEK cho rằng không phải ransomware nào cũng có decryptor.

Khả năng phục hồi dữ liệu có thể đến từ nhiều hướng khác nhau như

Decrypt → Recover → Rebuild → Extract → Repair

Tùy từng trường hợp, kỹ thuật viên TRecovery có thể phải xử lý:

• RAID reconstruction, NAS filesystem, VMFS Datastore, VMDK/VHDX, SQL MDF/LDF, Oracle Database, ERP Database, Deleted Volume, damaged filesystem, partial encryption, fragmented file, corrupted database, deleted backup.

Do đó, việc phân tích hiện trạng hệ thống trước khi can thiệp là đặc biệt quan trọng. Ở TUNGTEK, chúng tôi có quy trình chặt chẽ thu thập các thông tin này.

🔴 CuuDuLieuMaHoa.com by TUNGTEK | Ransomware Recovery | Incident Data Recovery

TUNGTEK tập trung xử lý các sự cố dữ liệu phức tạp liên quan đến:

🔹 Ransomware
🔹 NAS Synology / QNAP
🔹 RAID Server
🔹 VMware ESXi / VMFS
🔹 VMDK / Virtual Machine
🔹 SQL Server / ERP Database
🔹 Dữ liệu bị mã hóa, xóa hoặc phá hủy bởi Ransomware.

Khi xảy ra ransomware, giá trị lớn nhất đôi khi không nằm ở việc hệ thống có thể bật lại hay không, mà nằm ở việc còn bao nhiêu dữ liệu có thể được bảo toàn và phục hồi trước khi bị ghi đè hoặc phá hủy thêm.

🆃🆄🅽🅶🆃🅴🅺 𝟎𝟗𝟔𝟑𝟓𝟎𝟗𝟏𝟏𝟓.

#Ransomware #EclipseRansomware #RaaS #ThreatIntelligence #DarkWeb #CyberSecurity #IncidentResponse #RansomwareRecovery #CuuDuLieuMaHoa #TUNGTEK

Tháng 8/2026, CCTV TECHDAY HCMC 2026 chính thức trở lại tại TP.HCM với chuỗi hoạt động kết hợp giữa công nghệ, thể thao, giao lưu doanh nghiệp và Gala Dinner. 🚀

Với tinh thần “Kết nối để dẫn đầu”, sự kiện là nơi gặp gỡ của cộng đồng CCTV, an ninh, lưu trữ, hạ tầng và các doanh nghiệp công nghệ, đồng thời tạo nên một sân chơi giao lưu chuyên nghiệp và đầy năng lượng. 🤝

⚽ CCTV TECHDAY HCMC 2026 diễn ra với nhiều hoạt động thể thao và công nghệ hấp dẫn:

• ⚽ Giải bóng đá CCTV: khai mạc và vòng bảng lúc 16:00 ngày 17/8/2026; bán kết và chung kết ngày 19/8/2026 tại Khu Thể thao Vạn Xuân.

• 🏓 Giải Pickleball CCTV: ngày 20/8/2026, từ 12:00–17:00.

• ⛳ Giải Golf CCTV: ngày 21/8/2026, từ 09:00–16:00 tại Sân Golf Tân Sơn Nhất.

• 🎾 Giải Tennis CCTV: ngày 21/8/2026, từ 07:00–17:00.

• 💻 Triển lãm Công nghệ & Gala Dinner: ngày 21/8/2026, từ 13:00–22:00, bao gồm khu vực triển lãm công nghệ, chương trình tri ân nhà tài trợ, trao giải, giao lưu đối tác và chương trình văn nghệ.

Chuỗi hoạt động tạo nên không gian kết nối giữa những người làm kỹ thuật, kinh doanh và quản lý trong hệ sinh thái CCTV – công nghệ tại Việt Nam.

🛡️ CuuDuLieu.TOP by TUNGTEK – một phần của CCTV TECHDAY HCMC 2026

Trong sự kiện năm nay, CuuDuLieu.TOP by TUNGTEK cũng là một phần của CCTV TECHDAY HCMC 2026, góp mặt trong cộng đồng công nghệ với thế mạnh chuyên sâu về:

🔹 Data Recovery
🔹 HDD/SSD Recovery
🔹 RAID & NAS Recovery
🔹 Ransomware Recovery

Việc tham gia CCTV TECHDAY HCMC 2026 là cơ hội để TUNGTEK giao lưu cùng cộng đồng kỹ thuật CCTV, hệ thống lưu trữ và các doanh nghiệp công nghệ; đồng thời chia sẻ thêm kinh nghiệm thực tế trong xử lý những sự cố dữ liệu phức tạp, đặc biệt đối với hệ thống camera, HDD/SSD, RAID, NAS và dữ liệu bị ransomware mã hóa.

Với TUNGTEK, đây không đơn thuần là một sự kiện thể thao hay triển lãm công nghệ, mà còn là dịp để kết nối chuyên môn, mở rộng quan hệ đối tác và cùng cộng đồng công nghệ phát triển bền vững hơn.

CCTV TECHDAY HCMC 2026 mang đến một mô hình sự kiện giàu tính kết nối: từ sân bóng ⚽, pickleball 🏓, golf ⛳, tennis 🎾 cho đến triển lãm công nghệ 💻 và Gala Dinner 🎉.

Sự kết hợp giữa Thể thao – Công nghệ – Doanh nghiệp giúp những mối quan hệ trong ngành không chỉ dừng lại ở công việc, mà còn được xây dựng bằng tinh thần đồng đội, sự tin tưởng và niềm đam mê chung.

🔥 CuuDuLieu.TOP by TUNGTEK hân hạnh là một phần của CCTV TECHDAY HCMC 2026.

🆃🆄🅽🅶🆃🅴🅺 𝟎𝟗𝟔𝟑𝟓𝟎𝟗𝟏𝟏𝟓

TRecovery Ticket #1307 là một ca phục hồi dữ liệu có độ khó cao trên ổ cứng HGST Enterprise 10TB – 7200RPM – SATA 6Gb/s, thuộc dòng thiết bị được thiết kế cho môi trường máy chủ và lưu trữ hoạt động liên tục.

Điểm khó của ca này không chỉ nằm ở dung lượng lớn 10TB. Ổ đã xuất hiện dấu hiệu lỗi khiến quá trình đọc dữ liệu không còn ổn định, đồng thời cần kiểm tra thêm khả năng liên quan đến cơ chế mã hóa chủ động của thiết bị.

Với những trường hợp như vậy, thao tác cắm thử nhiều lần, scan trực tiếp hoặc chạy các công cụ sửa filesystem có thể làm tình trạng ổ xấu hơn và giảm khả năng phục hồi.

Quy trình xử lý Ticket #1307

TRecovery ưu tiên quy trình bảo toàn dữ liệu nguồn:

Chẩn đoán phần cứng → kiểm tra firmware và bad sector → xác định trạng thái mã hóa → tạo bản sao bit-by-bit an toàn → phân tích filesystem/metadata → phục hồi và kiểm chứng dữ liệu.

Đặc biệt với ổ dung lượng 10TB, quá trình imaging có thể kéo dài đáng kể nếu xuất hiện vùng đọc chậm hoặc bad sector. Vì vậy chiến thuật đọc, timeout, retry và thứ tự ưu tiên vùng dữ liệu phải được điều chỉnh phù hợp thay vì cố gắng đọc tuần tự bằng mọi giá.

Điều quan trọng nhất. Khi ổ cứng Enterprise có dấu hiệu lỗi:

- Không Format.

- Không CHKDSK.

- Không Initialize Disk.

- Không scan đi scan lại nhiều lần trên ổ gốc.

- Không ghi thêm bất kỳ dữ liệu nào lên thiết bị.

Mục tiêu đầu tiên không phải là “mở được ổ”, mà là bảo toàn tối đa những sector còn đọc được trước khi tình trạng phần cứng tiếp tục suy giảm.

Ticket #1307 tiếp tục là một thử thách kỹ thuật đáng chú ý trong quá trình phục hồi dữ liệu dung lượng lớn của TRecovery.

🆃🆄🅽🅶🆃🅴🅺 0963509115

➖

#TUNGTEK

⚡ SSD “ĐỘT TỬ” – THÁCH THỨC MỚI TRONG CỨU DỮ LIỆU

➖➖➖

SSD ngày càng phổ biến nhưng có thể “ngừng hoạt động” đột ngột: không nhận ổ, mất phân vùng hoặc không truy cập được dữ liệu.

Khác HDD, SSD phụ thuộc vào controller, firmware và bảng ánh xạ dữ liệu. Khi lỗi xảy ra, việc khôi phục rất phức tạp dù chip nhớ vẫn còn tốt.

📷 Các SSD M.2 đang được kiểm tra – mỗi trường hợp là một bài toán riêng của CuuDuLieu.TOP.

⚠️ KHÔNG dùng SSD làm nơi lưu trữ duy nhất.

Khuyến nghị:

• 1 bản đang dùng

• 1 bản sao lưu

• 1 bản lưu tách biệt

Với dữ liệu quan trọng, chi phí sao lưu luôn thấp hơn nhiều so với khôi phục.

Khi SSD lỗi, không nên format, repair hay ghi thêm dữ liệu.

🔴 CuuDuLieu.TOP by TUNGTEK

☎️ 0963509115

Khôi phục là giải pháp cuối. Sao lưu mới là an toàn nhất.

#CuuDuLieuTOP #TUNGTEK #SSD #DataRecovery #Backup #NVMe #M2SSD