Từ tháng 1/2025, một nhóm tấn công chưa xác định danh tính đã duy trì hoạt động gián điệp mạng nhắm vào các cơ quan chính phủ tại Afghanistan, Kyrgyzstan, Tajikistan, Uzbekistan, Kazakhstan và Syria, sử dụng hai họ backdoor mới được đội ngũ GReAT của Kaspersky đặt tên là OctLurk và SilkLurk. Nạn nhân trải rộng trên nhiều lĩnh vực: y tế, nghiên cứu, văn phòng chính phủ, bộ ngoại giao, logistics, cơ quan thực thi pháp luật, quy hoạch đô thị và giáo dục công lập.
Executive Summary
Đây là chiến dịch gián điệp có chủ đích (targeted espionage), không phải tấn công diện rộng — kẻ tấn công đã có được thông tin đăng nhập quản trị (admin credentials) trước khi triển khai malware, cho thấy giai đoạn xâm nhập ban đầu đã diễn ra từ trước hoặc thông qua một vector riêng mà báo cáo gốc chưa công bố. Rủi ro kinh doanh cụ thể với các tổ chức bị nhắm tới: đánh cắp toàn bộ mật khẩu Active Directory qua secretsdump, ghi lại thao tác bàn phím và dữ liệu clipboard, đánh cắp mật khẩu lưu trong trình duyệt, quét mạng nội bộ để mở rộng tấn công, và cuối cùng là exfiltrate tài liệu mật qua các ổ đĩa mạng chia sẻ.
Đặc điểm đáng chú ý nhất về mặt phòng thủ: cả hai backdoor gần như không để lại dấu vết trên đĩa. Payload thực sự được giải mã và chạy hoàn toàn trong bộ nhớ (in-memory), còn khóa giải mã lại được tính toán từ thông tin đặc thù của từng máy nạn nhân (serial number ổ đĩa C: với OctLurk, tên máy tính với SilkLurk). Nói cách khác, nếu lấy được mẫu OctLurk hoặc SilkLurk từ máy này đem chạy trên máy khác, backdoor sẽ không thể tự giải mã payload — điều này khiến việc phân tích tĩnh và sandbox tự động gần như vô dụng. Hành động ưu tiên nhất với các tổ chức trong khu vực: rà soát các scheduled task mang tên GoogleUpDate, các service lạ được tạo gần đây, và log logon type 10 (RDP) bất thường — đây là những dấu hiệu triển khai chung mà kẻ tấn công dùng lặp lại nhiều lần trong chiến dịch.
Hai backdoor, một kẻ đứng sau
Kaspersky đánh giá với độ tin cậy trung bình rằng cùng một nhóm tấn công vận hành cả OctLurk lẫn SilkLurk — nhiều nạn nhân bị nhiễm SilkLurk cũng phát hiện có OctLurk, và trong một số trường hợp cả hai backdoor dùng chung thư mục staging trên đĩa. Nhóm này được đánh giá là nói tiếng Trung (Chinese-speaking), nhưng tại thời điểm công bố báo cáo, Kaspersky chưa gán được hoạt động này cho bất kỳ nhóm APT đã biết nào.
Cả hai loader đều được cá nhân hóa theo từng nạn nhân và bị obfuscate nặng, khiến việc reverse engineering tốn nhiều công sức hơn bình thường. Sau khi cắm chân, kẻ tấn công tải thêm các plugin để mở command shell, thao tác hệ thống file, giả lập bàn phím/chuột, quét mạng, dump credential, keylog, đánh cắp mật khẩu trình duyệt, thu thập email và duy trì truy cập từ xa. Ngoài ra, nhóm này còn triển khai một công cụ riêng gọi là LurkProxy — không phải backdoor, mà là proxy mạng dùng kiến trúc gần như giống hệt OctLurk.
OctLurk: từ scheduled task đến reflective injection
Cách triển khai
Kẻ tấn công dùng thông tin đăng nhập quản trị để tạo scheduled task tên GoogleUpDate trên máy từ xa, chạy với quyền System. Task này thực thi file batch C:\Users\<username>\Videos\1.bat, script này lại tạo một service tên NgcCIntSvc để load loader DLL oleasapi.dll thông qua tham số ServiceMain.
Ở một biến thể khác dùng để triển khai LurkProxy, kẻ tấn công kiểm tra kết nối tới domain dns[.]ssentialserv[.]xyz (trỏ về C2 154[.]196[.]162[.]76) trước khi chạy script auto.bat, tạo service Cusrxsrv load DLL msbasesysdc.dll.
Kaspersky ghi nhận nhiều tên service khác được tái sử dụng cho kỹ thuật load DLL này: specitsrc, cmtastsvc, PNRPHostSvc, vmictimerosync, vmicagent.
Cơ chế loader và backdoor
Loader export hai hàm Refresh và RegisterService. Service gọi RegisterService, hàm này lại gọi Refresh — nơi chứa mã độc thực sự. Để tìm payload, loader thực hiện double-XOR-decrypt rồi giải nén zlib một chuỗi byte hard-code để lấy đường dẫn file payload; chính payload đó lại trải qua đúng quy trình double-XOR + zlib để ra được backdoor DLL.
Điểm then chốt nằm ở khóa giải mã: một khóa hard-code trong loader, khóa còn lại được lấy từ serial number ổ đĩa C: của máy nạn nhân — đây chính là lý do khiến mẫu OctLurk không thể tự giải mã nếu bị copy sang máy khác. Backdoor DLL sau đó được reflectively injected vào bộ nhớ và chạy trực tiếp entry point, hoàn toàn không ghi payload đã giải mã ra đĩa.
Sau khi khởi tạo, OctLurk mở kết nối socket tới C2 dns[.]multitoconference[.]com qua cổng 443, thu thập thông tin OS, tên máy, username, hostname, địa chỉ IP local và thời gian hệ thống. Dữ liệu được nén zlib rồi mã hóa hai lớp XOR — một khóa chuỗi hard-code, một khóa 83 byte sinh ngẫu nhiên — trước khi gửi đi theo một định dạng packet có header 16 byte báo trước kích thước gói tin kế tiếp.
Plugin: shell, file, tương tác hệ thống
OctLurk tải plugin trực tiếp từ C2 vào bộ nhớ, mỗi plugin export hai hàm ins_ctl_db và oct_lk_col (chứa logic thực thi). Ba plugin phổ biến nhất được ghi nhận trong chiến dịch:
Command Shell: mở cmd.exe, chuyển tiếp lệnh từ C2 và trả kết quả về, có cả nhánh dự phòng ghi output ra file tạm nếu shell chưa chạy sẵn.
File Manager: liệt kê ổ đĩa, tìm kiếm và duyệt file theo điều kiện thời gian/kích thước do C2 chỉ định, đọc/ghi file theo từng chunk kèm checksum CRC32, thực thi file qua ShellExecuteExW hoặc CreateProcessAsUserW, và các thao tác copy/move/rename/delete qua SHFileOperationW.
Interaction Manager: chụp toàn màn hình dạng BMP (một lần hoặc theo chu kỳ), đọc/ghi clipboard, và giả lập đầy đủ sự kiện chuột lẫn bàn phím ở mức API — đủ để kẻ tấn công điều khiển máy nạn nhân như đang ngồi trước màn hình.
Hoạt động hậu xâm nhập của OctLurk
Toàn bộ hoạt động dưới đây được thực hiện qua plugin Command Shell.
Fingerprinting nạn nhân
Kẻ tấn công tạo lại một scheduled task GoogleUpDate khác, lần này chạy script C:\windows\temp\in.bat — một chuỗi lệnh khá dài thu thập gần như toàn bộ dấu vân tay hệ thống: phiên bản PowerShell, session đang hoạt động, danh sách tiến trình, sự kiện RDP logon (event ID 4624, logon type 10), cấu hình mạng, thông tin người dùng hiện tại (WHOAMI /all), phần mềm diệt virus đang cài, kết nối TCP đang mở, trạng thái Microsoft Defender (bao gồm cả việc dò xem tamper protection có bật hay không và danh sách exclusion), thông tin BIOS/RAM/CPU/ổ đĩa, và cache DNS resolver. Kết quả được lưu vào ba file info.txt, <hostname>.datb, <hostname>_logs.datb trong %TEMP%.
Đáng chú ý là lệnh chcp 1256 đổi code page sang bảng mã hỗ trợ ký tự Ả Rập — một chi tiết nhỏ nhưng gợi ý thao tác viên có thể quen làm việc trong môi trường ngôn ngữ Ả Rập, hoặc đơn giản là script được viết để dùng chung cho nhiều mục tiêu ở Trung Đông.
Thu thập event log
Kẻ tấn công trích xuất riêng các sự kiện đăng nhập RDP thành công và tra cứu theo từng user cụ thể — phục vụ mục đích xác định ai đã truy cập máy chủ nào, phục vụ di chuyển ngang (lateral movement) có chọn lọc thay vì dò quét ngẫu nhiên.
Đánh cắp credential
Kẻ tấn công chạy Adobe.exe — thực chất là bản PE của công cụ secretsdump.py trong Impacket — để dump hash mật khẩu trực tiếp từ domain controller, sau đó liệt kê ngay nhóm "Domain Controllers" để xác định các DC khác làm mục tiêu tiếp theo.
Song song đó, một keylogger giả danh AnyDesk.exe được đặt tại C:\Users\Public\Pictures\ và chạy tự động mỗi khi có user đăng nhập thông qua scheduled task cùng tên. Dữ liệu bàn phím và clipboard được ghi vào hai file riêng (dev0, dev1), mã hóa đơn giản bằng cách trừ 2 vào mỗi byte trước khi lưu.
Một công cụ thứ ba, Browser Password Decryptor (64.exe), nhắm vào database Login Data và Local State của Chrome cũng như logins.json của Firefox để giải mã mật khẩu đã lưu.
Duy trì truy cập và mở rộng mạng
Kẻ tấn công cài Pandora RC agent (Pandora FMS) để có kênh remote-control hợp pháp song song với backdoor, triển khai qua cùng mẫu scheduled task GoogleUpDate chạy script 1.bat.
Để dò mạng nội bộ, kẻ tấn công dùng Fscan (%TEMP%\fc.exe) quét cổng SSH (22) và MySQL (3306) trên cả mạng nội bộ lẫn public-facing, kết hợp brute-force bằng danh sách credential có sẵn trong pp.txt.
Cuối cùng, kẻ tấn công dùng curl để đăng nhập trực tiếp vào mailbox nạn nhân qua giao thức IMAP/POP, xác thực và mở Inbox — phục vụ đọc hoặc lọc email nhạy cảm.
LurkProxy: không phải backdoor, mà là hạ tầng proxy
LurkProxy dùng chung loader đã obfuscate nặng với OctLurk và export cùng hàm curl_escape_easy, nhưng vai trò của nó thuần túy là proxy lưu lượng mạng. Sau khi chạy, nó lắng nghe trên tất cả interface ở cổng cứng 64980 và mở kết nối TLS tới C2 154[.]196[.]162[.]76, dùng giao thức nhị phân riêng: mỗi packet được nén zlib rồi mã hóa double-XOR.
LurkProxy hỗ trợ hai chế độ (chỉ chọn được một tại một thời điểm): SOCKS5 proxy — khi client kết nối, LurkProxy báo C2 địa chỉ đích để C2 mở kết nối tương ứng; và transparent proxy — địa chỉ đích được hard-code sẵn, mọi kết nối client đều được route qua một đích cố định, bỏ qua lớp SOCKS5. Trong mẫu Kaspersky phân tích, chế độ SOCKS5 được sử dụng — cho thấy kẻ tấn công cần một kênh linh hoạt để pivot vào các hệ thống nội bộ khác từ máy đã chiếm được, thay vì chỉ phục vụ một mục tiêu cố định.
SilkLurk: DLL side-loading và mã hóa gắn với tên máy
Triển khai
SilkLurk dùng kỹ thuật DLL side-loading qua các binary hợp pháp: NetSetSvc.exe (NVIDIA debug dump), nvgwls.exe (công cụ nền của NVIDIA), RtkSmbus.exe và RtkNGUI64.exe (phần mềm Realtek Audio) — mỗi binary này load một loader DLL cùng tên thư mục nhưng khác chức năng: nvml.dll, vulkan-1.dll, RtkSmbusLoc.dll, RtkNGUI64Loc.dll.
Cơ chế loader
Loader trước tiên xác minh nó đang chạy đúng trong tiến trình hợp pháp mong đợi — một bước chống sandbox/chống chạy độc lập đơn giản nhưng hiệu quả. Sau đó nó di chuyển file payload (ví dụ OneDrive.dat) sang một đường dẫn hard-code khác, tạo service RmSs để duy trì persistence (auto-start, tự khởi động lại khi lỗi), rồi khởi động service đó.
Khi service chạy, ServiceProc gọi hàm giải mã payload dựa trên hash 32-bit của tên máy tính nạn nhân — chính con số này được đưa qua một thuật toán tùy biến (kết hợp phép toán số học và logic) để giải mã đường dẫn payload lẫn nội dung payload. Vì gắn chặt với tên máy, một mẫu SilkLurk lấy từ nạn nhân này sẽ không tự giải mã được nếu đem chạy ở máy khác — cùng triết lý phòng thủ chống phân tích như OctLurk, chỉ khác điểm neo (anchor) là tên máy thay vì serial number ổ đĩa.
Payload giải mã ra là một shellcode chứa: stub code thực hiện reflective injection, giá trị hard-code XOR với hash tên máy, một byte XOR key để giải mã tên DLL/API import, và cuối cùng là blob backdoor đã mã hóa. Quá trình giải mã import và relocation cũng dùng chính hash tên máy làm khóa, sau đó các chuỗi tên DLL/API được xóa khỏi bộ nhớ ngay sau khi resolve xong địa chỉ — một kỹ thuật anti-forensic khiến memory dump khó truy ngược ra các API mà backdoor sử dụng.
Cấu hình và giao thức C2
SilkLurk lưu một block cấu hình 1196 byte (16 byte đầu là chuỗi mutex, phần còn lại là dữ liệu mã hóa) vào một file có tên hard-code ngẫu nhiên trong %APPDATA%. Cấu hình chứa tới 4 host C2 dự phòng kèm cổng riêng, cùng hai bộ thông tin proxy (địa chỉ, username, password) — cho thấy backdoor được thiết kế để tiếp tục hoạt động ngay cả khi một C2 bị chặn hoặc sập.
Sau khi kết nối C2 (trực tiếp hoặc qua proxy dạng HTTP CONNECT giả lập header trình duyệt Chrome), backdoor sinh một khóa mạng ngẫu nhiên 32 byte dùng cho toàn bộ phiên làm việc, gửi khóa này cho C2 trong một gói đã mã hóa, rồi mới gửi tiếp thông tin nạn nhân (tên máy, domain, username, kiến trúc CPU, phiên bản OS, IP, PID tiến trình, tick count). Cấu trúc header phản hồi từ C2 cho biết loại lệnh (message type) tiếp theo, gồm: lấy/đặt thời gian sleep trước khi reconnect, gửi hoặc cập nhật cấu hình backdoor, và — quan trọng nhất — nhận và inject thêm plugin vào bộ nhớ.
Hoạt động hậu xâm nhập của SilkLurk và PlugX
Khác với nhánh OctLurk thiên về thu thập dữ liệu hệ thống diện rộng, thao tác viên SilkLurk tập trung vào tìm kiếm tài liệu. Từ command shell mở qua SilkLurk, họ gọi PowerShell để net use kết nối vào các ổ đĩa mạng chia sẻ bằng credential quản trị, tìm tài liệu nhạy cảm, sau đó chủ động ngắt kết nối để xóa dấu vết đã truy cập server nào. Dữ liệu thu được được nén bằng WinRAR và 7-Zip — hai công cụ hợp pháp, khó bị EDR gắn cờ nếu không giám sát theo hành vi.
Ở giai đoạn tiếp theo, kẻ tấn công triển khai PlugX — RAT dạng module đã hoạt động từ ít nhất năm 2008 và gắn liền với lịch sử các nhóm nói tiếng Trung — thông qua dropper kmsonline.exe. Dropper này giả danh phần mềm Symantec, thả bộ ba file loader kinh điển: binary hợp pháp RasTls.exe, DLL loader RasTls.dll, và payload RasTls.dll.res. Kaspersky Threat Attribution Engine (KTAE) xác nhận mức độ tương đồng cao giữa kmsonline.exe với các mẫu PlugX đã biết.
PlugX trong chiến dịch này liên lạc với C2 gycudore[.]kozow[.]com, tiêm vào tiến trình svchost.exe, giả danh service "SymantecRAS" — và mang Campaign ID KG_MFA, một chi tiết gợi ý khá rõ mục tiêu địa lý cụ thể (KG thường là mã quốc gia Kyrgyzstan) và có thể cả loại tổ chức mục tiêu (MFA — Ministry of Foreign Affairs).
Hạ tầng và mối liên hệ với TrustFall/MystRodX
Một phần địa chỉ C2 của OctLurk và LurkProxy trùng khớp với dữ liệu trong báo cáo công khai của Cơ quan Kỹ thuật Nhà nước Kazakhstan (STS) về chiến dịch nhắm vào hạ tầng trọng yếu nước này hồi tháng 3/2025. Chiến dịch đó sử dụng malware TrustFall (tên nội bộ của STS) — cũng chính là MystRodX theo cách gọi của Qianxin và SilentRaid theo Cisco Talos, một backdoor nhắm vào hệ điều hành Linux. Đến tháng 10/2025, STS phát hiện thêm các mẫu TrustFall mới cùng các C2 mới qua kỹ thuật active probing, và ba trong số các địa chỉ C2 TrustFall này trùng với C2 đang được OctLurk và LurkProxy sử dụng.
Sự trùng lặp hạ tầng này cho thấy khả năng có sự chia sẻ tài nguyên C2 giữa các chiến dịch nhắm tới nhiều hệ điều hành khác nhau (Windows lẫn Linux), dù báo cáo gốc chưa xác định được liệu các hoạt động này diễn ra đồng thời hay ở các thời điểm tách biệt.
Bằng chứng gắn kết OctLurk và SilkLurk
Ngoài việc nhiều nạn nhân bị nhiễm cả hai họ malware, Kaspersky còn ghi nhận các bằng chứng trực tiếp hơn:
- Trong một sự cố, kẻ tấn công tạo service ngụy trang
svchost.exe -k ExAstSrc -s ExAstSrc để triển khai OctLurk, sau đó dùng chính command shell của OctLurk để thả loader SilkLurk (vulkan-1.dll).
Ở một sự cố khác, cả hai loader OctLurk (mscastrac.dll, msbasesysdc.dll) và SilkLurk (vulkan-1.dll) được thả vào cùng một thư mục C:\ProgramData\intel\.
Trong nhánh SilkLurk dẫn tới PlugX, PlugX liên lạc C2 qua gycudore[.]kozow[.]com trong khi SilkLurk backdoor dùng ctyuhjerf[.]kozow[.]com — cùng nằm trên hạ tầng dynamic DNS kozow[.]com, một dấu hiệu khác của cùng một bộ vận hành.
Nhận định
Điểm chung xuyên suốt cả OctLurk lẫn SilkLurk là chiến lược "để lại càng ít dấu vết trên đĩa càng tốt, và mã hóa mọi thứ gắn với đặc điểm riêng của từng máy nạn nhân". Cách tiếp cận này không mới về mặt lý thuyết, nhưng việc áp dụng nhất quán trên cả hai họ malware — cùng với việc duy trì song song nhiều kênh truy cập dự phòng (Pandora RC, PlugX, LurkProxy) — cho thấy đây là một nhóm có quy trình vận hành khá trưởng thành, ưu tiên tính bền vững của chiến dịch hơn là tốc độ triển khai.
Với các đội SOC trong khu vực Trung Á và các tổ chức có hồ sơ tương tự (chính phủ, ngoại giao, hạ tầng trọng yếu), ba tín hiệu đáng để đưa vào rule phát hiện ngay: scheduled task tên GoogleUpDate được tạo rồi query trạng thái ngay sau đó, service mới load DLL thông qua tham số ServiceMain trỏ tới các hàm không chuẩn như RegisterService/Refresh, và các file batch tạm thời (1.bat, auto.bat, in.bat) xuất hiện trong %TEMP%, thư mục Videos, hoặc Desktop của người dùng — những vị trí không điển hình cho hoạt động triển khai service hợp pháp.
Khuyến nghị
Rà soát Task Scheduler trên toàn bộ máy chủ và endpoint để tìm task tên GoogleUpDate — tên này được tái sử dụng ở ba giai đoạn khác nhau của chiến dịch (triển khai OctLurk, fingerprinting, cài Pandora RC agent). Đối chiếu thời điểm tạo task với log logon để xác định tài khoản quản trị nào đã bị dùng.
Truy vấn Windows Event Log tìm sự kiện Security 4624 với logon type 10 (RDP) bất thường, đặc biệt từ các nguồn IP không quen thuộc hoặc ngoài giờ hành chính — đây là chính lệnh mà nhóm tấn công dùng để tự kiểm tra dấu vết của mình.
Kiểm tra các service mới tạo có ServiceMain trỏ tới các hàm không chuẩn như RegisterService/Refresh/ServiceProc, đặc biệt nếu binary hoặc DLL liên quan nằm trong ProgramData, Users\Public, hoặc mang tên na ná phần mềm hợp pháp (oleasapi.dll, msbasesysdc.dll, vulkan-1.dll, nvml.dll, RtkNGUI64Loc.dll).
Chặn tạm thời (hoặc đưa vào watchlist) toàn bộ domain/IP C2 liệt kê trong phần IOC bên dưới trên firewall, proxy và DNS sinkhole.
Kiểm tra sự tồn tại của các file điển hình: C:\Users\Public\Pictures\AnyDesk.exe kèm scheduled task cùng tên (keylogger giả danh), và C:\ProgramData\microsoft\html help\kmsonline.exe (dropper PlugX).
Threat hunting trên EDR/SIEM tìm hành vi reflective DLL injection từ các service không thuộc danh mục phần mềm đã duyệt (baseline), thay vì chỉ dựa vào hash — vì loader được cá nhân hóa theo từng nạn nhân nên hash sẽ khác nhau ở mỗi tổ chức.
Rà soát log truy cập file share/NAS tìm hành vi mount rồi unmount ổ mạng trong thời gian ngắn kèm theo hoạt động nén file bằng WinRAR/7-Zip ngay sau đó — pattern exfiltration mà nhóm SilkLurk sử dụng.
Đổi mật khẩu toàn bộ tài khoản quản trị domain và tài khoản dịch vụ nếu có bất kỳ dấu hiệu nào ở trên được xác nhận, do khả năng cao credential đã bị dump qua secretsdump.
Kiểm tra cấu hình exclusion của Microsoft Defender trên các máy nghi ngờ — kẻ tấn công chủ động dò xem exclusion nào đang tồn tại, có thể đã lợi dụng exclusion sẵn có hoặc thêm exclusion mới để native persist.
Rà soát các cài đặt Pandora FMS agent không do đội IT phê duyệt, vì công cụ remote-control hợp pháp này được dùng như một kênh truy cập dự phòng song song với backdoor.
Áp dụng application whitelisting/allowlisting cho các thư mục thường bị lợi dụng để side-load DLL (ProgramData, thư mục cài driver NVIDIA/Realtek), giám sát riêng các binary hợp pháp bị load DLL lạ (side-loading detection).
Giảm phạm vi và giám sát chặt việc dùng tài khoản quản trị domain cho tác vụ thường nhật — phần lớn chuỗi tấn công trong báo cáo này phụ thuộc vào việc đã có sẵn credential quản trị từ trước.
Triển khai giám sát hành vi (behavioral detection) thay vì chỉ dựa vào chữ ký, do cả hai backdoor mã hóa payload gắn với đặc điểm riêng của từng máy (serial number ổ đĩa, tên máy) khiến việc phát hiện bằng hash tĩnh gần như không hiệu quả trên diện rộng.
Với các tổ chức chính phủ/ngoại giao tại Trung Á và khu vực lân cận có hồ sơ tương tự nạn nhân trong báo cáo, cân nhắc đăng ký dịch vụ Threat Intelligence Reporting của Kaspersky để nhận bộ IOC đầy đủ hơn, bao gồm các mẫu batch script và công cụ chưa được công khai.
Chỉ báo xâm nhập (IOC)
C2 domain/IP
OctLurk C2: dns[.]multitoconference[.]com, tj[.]tajikistandip[.]com, fm01[.]clouddevicemetrics[.]com, confbase[.]mdpsupport[.]net, digital[.]leroymerling[.]com, api2[.]annoyingremote[.]com, about[.]blsouqs[.]com, ssl[.]blsouqs[.]com, 45[.]138[.]157[.]165
LurkProxy C2: dns[.]ssentialserv[.]xyz, 154[.]196[.]162[.]76
SilkLurk C2: tyhbgtyuj[.]gleeze[.]com, 95[.]179[.]210[.]138, wedfcvbn[.]gleeze[.]com, 45[.]77[.]136[.]228, rgnojb[.]casacam[.]net, 95[.]179[.]141[.]26, ctyuhjerf[.]kozow[.]com, 45[.]32[.]152[.]50, 212[.]11[.]39[.]138, 195[.]86[.]120[.]2, uyhvfredc[.]accesscam[.]org, 154[.]196[.]187[.]73, 45[.]61[.]149[.]112, gycudore[.]kozow[.]com (PlugX), 64[.]7[.]198[.]130 (PlugX)
Hash file loader và payload
| File |
MD5 |
| oleasapi.dll (OctLurk loader) |
082d49ef9f14e6811d68c7e0e82e5069 |
| msbasesysdc.dll (OctLurk loader) |
f4578e869a735cfad691f927bae3e638 |
| mscastrac.dll (OctLurk loader) |
7c2f64461bb519c6cbf1fc687675514c |
| vulkan-1.dll (SilkLurk loader) |
8269d6ba1b6842f9152c90cf7add9b93 |
| kmsonline.exe (PlugX dropper) |
3c9a1ba8e0c7475706adc6376e9d7b7c |
| RasTls.dll (PlugX loader) |
ef59aad625eebda8650aec5820d6ce69 |
| Adobe.exe (Impacket secretsdump) |
32a5985543433a4f60da2fafd873b927 |
| AnyDesk.exe (keylogger) |
2a571f6cee42a17d873f4c942649813f |
| 64.exe (browser password stealer) |
37dc84e4bcad92fa28f1e7778d088283 |
| fc.exe (FSCAN) |
cf903e4a1629aa0582fd0363b5786676 |
Đường dẫn file đáng chú ý
C:\Users\[username]\Videos\1.bat, C:\windows\temp\in.bat, C:\Users\[username]\1.bat, C:\ProgramData\1.bat
C:\Users\Public\Pictures\AnyDesk.exe, C:\Users\Public\Libraries\msect\dev0, dev1
C:\ProgramData\microsoft\network\connections\vulkan-1.dll (và nhiều biến thể thư mục khác cùng tên file)
C:\ProgramData\microsoft\html help\kmsonline.exe
C:\ProgramData\Symantec\RasTls.exe, RasTls.dll, RasTls.dll.res
Kaspersky lưu ý danh sách IOC đầy đủ hơn (bao gồm cả các batch script và công cụ secretsdump không public) chỉ dành cho khách hàng dịch vụ Threat Intelligence Reporting.
Tài liệu tham khảo
