Tháng 7/2024, Google giới thiệu cơ chế Application-Bound Encryption (ABE) cho Chrome 127 trên Windows, nhằm khắc phục điểm yếu cố hữu của DPAPI: bất kỳ tiến trình nào chạy trong user context đều có thể giải mã Cookie và Password lưu trong trình duyệt. ABE đặt key giải mã sau một SYSTEM service, chỉ trả về cho caller được xác thực là tiến trình Chrome hợp lệ.
Tuy nhiên chỉ chưa đầy 45 ngày sau khi ABE ra mắt, dấu hiệu bypass đầu tiên đã được ghi nhận. Các họ Infostealer MaaS như STEALC/VIDAR, METASTEALER, XENOSTEALER, LUMMA nhanh chóng phát triển nhiều kỹ thuật khác nhau để vượt qua cơ chế này. Trong bài này, chúng ta sẽ phân tích chi tiết một trong những kỹ thuật được sử dụng rộng rãi: lạm dụng COM Interface của Elevation Service kết hợp với Reflective DLL Injection để lấy master key và giải mã Cookie.
Cơ chế bảo vệ Chrome App-Bound Encryption
Các bản Chrome cũ trên Windows dùng DPAPI để mã hóa Cookie. Hạn chế cốt lõi: khóa DPAPI được dẫn xuất từ thông tin đăng nhập của người dùng, nên mọi mã độc chạy cùng ngữ cảnh người dùng đều có thể gọi CryptUnprotectData để giải mã trực tiếp. Đây chính là kịch bản mặc định của hầu hết Infostealer thế hệ cũ.
Từ Chrome 127, các dữ liệu nhạy cảm (Cookie, mật khẩu đăng nhập, thông tin thẻ thanh toán) được mã hóa bằng một khóa chính riêng. Khóa này được lưu trong file Local State dưới trường app_bound_encrypted_key, và chỉ có thể giải mã thông qua Google Chrome Elevation Service - một dịch vụ chạy với quyền SYSTEM. Service này thực hiện hai bước xác thực trước khi trả khóa:
Kiểm tra đường dẫn của tiến trình gọi có nằm trong thư mục cài Chrome/Edge hợp lệ hay không.
Kiểm tra chữ ký số của file thực thi.
Hai lớp kiểm tra này khiến cách tấn công truyền thống (gọi thẳng DPAPI hoặc đánh cắp khóa chính) không còn hiệu quả.
Các phương thức tấn công nhằm bypass ABE
Tính đến đầu năm 2026, một số kỹ thuật phổ biến đã được các dòng stealer sử dụng để bypass ABE bao gồm:
| Kỹ thuật | Cách hoạt động | Malware |
|---|---|---|
| Memory Scanning | Quét vtable CookieMonster trực tiếp trong process Chrome để lấy dữ liệu | STEALC, VIDAR, LUMMA |
| Remote Debugging | Khởi chạy Chrome với --remote-debugging-port=9222 rồi gọi Network.getAllCookies | PHEMEDRONE |
| COM + Injection | Inject DLL vào browser process để gọi DecryptData hợp lệ | XENOSTEALER |
| COM + SYSTEM Token | Impersonate SYSTEM rồi gọi COM Elevator | METASTEALER |
Kỹ thuật trong bài viết này - kết hợp COM với tiêm DLL vào tiến trình trình duyệt - tương tự cách XENOSTEALER triển khai trên Chrome. Phương pháp này chỉ yêu cầu quyền người dùng thông thường, không cần mạo danh SYSTEM như METASTEALER. Tuy nhiên, do phải thực hiện injection vào trình duyệt, nó vẫn có khả năng để lại dấu vết và bị phát hiện.
Kĩ thuật bypass ABE được sử dụng trong XENOSTEALER
XENOSTEALER là một infostealer mã nguồn mở được lưu trữ trên GitHub. Nó xuất hiện vào khoảng tháng 7 năm 2024. Đáng chú ý, tính năng bypass Chrome được commit vào ngày 26 tháng 9 năm 2024.
XENOSTEALER đầu tiên phân tích file JSON trong profile của Chrome để trích xuất app_bound_encrypted_key. Sau đó toàn bộ quá trình giải mã khóa được thực hiện trực tiếp bên trong tiến trình Chrome, và mã độc đã thực hiện điều này bằng cách khởi chạy một instance của chrome.exe, sau đó inject code thông qua một helper class có tên SharpInjector, đồng thời truyền encrypted key làm tham số.
Sau khi được inject, đoạn mã bên trong tiến trình Chrome sẽ gọi phương thức DecryptData của GoogleChromeElevationService để thực hiện giải mã app_bound_encrypted_key được truyền vào trước đó.
Giới thiệu cơ bản về COM
Component Object Model (COM) là cơ chế giao tiếp giữa các thành phần nhị phân trên Windows. Một COM object được định danh bằng CLSID (Class ID — GUID 128-bit) và cung cấp chức năng thông qua một hoặc nhiều Interface, mỗi Interface có IID riêng.
Bên gọi không truy cập trực tiếp object mà thông qua một Interface pointer. Pointer này tham chiếu tới một cấu trúc chứa con trỏ vtable — bảng lưu địa chỉ các hàm của object. Mọi COM Interface đều kế thừa từ IUnknown, bao gồm ba phương thức nền tảng: QueryInterface, AddRef và Release.
Một đặc điểm quan trọng của COM là COM server có thể hoạt động tách biệt với tiến trình của client - nghĩa là chạy trong tiến trình khác, thậm chí dưới ngữ cảnh người dùng khác. Khi client gọi CoCreateInstance với cờ CLSCTX_LOCAL_SERVER, COM runtime sẽ đóng gói các tham số thông qua cơ chế proxy/stub và chuyển chúng qua RPC tới tiến trình COM server đích.
Đây chính là cơ chế mà Chrome Elevation Service sử dụng để xử lý các yêu cầu đặc quyền từ tiến trình browser chạy dưới ngữ cảnh người dùng thông thường. Đồng thời, đây cũng là điểm mà malware có thể lợi dụng: nếu vượt qua hoặc khai thác được cơ chế xác thực client, nó có thể sử dụng kênh COM/RPC này để yêu cầu dịch vụ đặc quyền thực hiện thao tác thay cho mình.
Kỹ thuật Bypass ABE bằng COM Interface
Ý tưởng cốt lõi của kỹ thuật này là: thay vì cố gắng giả mạo code signature hay đánh lừa Elevation Service từ bên ngoài, malware sẽ inject mã của mình vào tiến trình browser hợp lệ và thực thi trực tiếp bên trong đó nhằm giả ngữ cảnh thực thi của trình duyệt. Khi payload chạy bên trong process thật (đúng path, đúng code signature, đúng COM context), các lệnh gọi tới CoCreateInstance và DecryptData sẽ bypass toàn bộ cơ chế kiểm tra của Elevation Service như thể chúng được thực hiện bởi chính trình duyệt hợp lệ.
Với trình duyệt Microsoft Edge được sử dụng cho phần thực nghiệm của bài viết này, các Interface liên quan bao gồm:
IElevatorEdgeFinal: Interface cuối cùng dùng để gọi DecryptData
IEdgeIntermediateElevator, IEdgeElevatorBase_Placeholder: kế thừa từ IUnknown, định nghĩa các slot trong vtable
Với Chrome thì interface tương ứng là IOriginalBaseElevator. Cả hai đều dẫn tới cùng method DecryptData. Dưới đây là luồng thực thi của kỹ thuật: từ tạo trình duyệt ở trạng thái tạm dừng đến trích xuất Cookie.
Triển khai chi tiết
Dưới đây là một mô hình cơ bản của kỹ thuật Bypass Chrome App-Bound Encryption, Code Lấy Key và Extract Cookie sẽ được triển khai như 1 DLL và thực hiện Inject vào Browser bằng kỹ thuật Reflective DLL Injection. Đối tương bị tiêm sẽ là trình duyệt Microsoft Edge.
Injector
Để tránh xung đột giữa các tiến trình Edge đang chạy, Injector kết thúc toàn bộ tiến trình msedge.exe hiện có rồi tạo một tiến trình Edge mới ở trạng thái tạm dừng:
Sau đó tiến hành Reflective DLL Injection vào tiến trình Edge này. Reflective Injection không gọi LoadLibrary (tránh để lại dấu vết trong PEB), mà tự nạp DLL từ vùng nhớ thông qua hàm ReflectiveLoader được nhúng sẵn trong DLL.
Reflective DLL - đọc Local State
Sau khi tự nạp thành công, DLL kiểm tra tiến trình đang chạy có phải msedge.exe, sau đó nạp bộ gồm CLSID và IID của Edge Elevator:
Giá trị bộ Config:
browser_configs = { {"edge", {"Edge", L"msedge.exe",
// CLSID: 1FCBE96C-1697-43AF-9140-2897C7C69767
{0x1FCBE96C, 0x1697, 0x43AF, {0x91, 0x40, 0x28, 0x97, 0xC7, 0xC6, 0x97, 0x67}},
// IID: C9C2B807-7731-4F34-81B7-44FF7779522B
{0xC9C2B807, 0x7731, 0x4F34, {0x81, 0xB7, 0x44, 0xFF, 0x77, 0x79, 0x52, 0x2B}},
fs::path("Microsoft") / "Edge" / "User Data"}} };
Mục đích là để sử dụng truy cập Interface IElevatorEdgeFinal sau này
DLL đọc file Local State (định dạng JSON) tại %LOCALAPPDATA%\Microsoft\Edge\User Data\Local State, trích trường app_bound_encrypted_key, giải mã base64 rồi kiểm tra 4 byte tiền tố "APPB":
Cấu trúc Local State và Format khóa mã hóa:
Gọi DecryptData qua COM và giải mã file Cookie
Đây là bước trọng tâm. Vì code đang chạy trong tiến trình msedge.exe (đúng đường dẫn, đúng chữ ký), Elevation Service sẽ chấp nhận bên gọi và trả về khóa chính:
Vì sao cần EOAC_DYNAMIC_CLOAKING?
Cờ này làm cho lời gọi RPC dùng token của luồng (thread) thay vì token của tiến trình khi gửi tới Elevation Service. Điều này quan trọng vì trong một số trường hợp, ngữ cảnh của luồng có quyền cao hơn (ví dụ sau khi mạo danh). Đây cũng là cờ được dùng cứng trong code gốc của Chrome khi gọi dịch vụ, nên việc lặp lại y hệt giúp yêu cầu không bị từ chối.
Với việc đã có Master Key, bước cuối là duyệt qua tất cả profile của Edge, đọc file Cookies (cơ sở dữ liệu SQLite), giải mã cột encrypted_value:
Kết quả cuối cùng thu được là Injector đã Extract thành công Cookie Data của người dùng.
Ngoài việc extract cookie để chiếm quyền phiên đăng nhập, kỹ thuật này còn có thể bị lạm dụng để trích xuất thêm thông tin tài khoản, mật khẩu và các credential nhạy cảm được lưu trong trình duyệt, từ đó mở rộng đáng kể phạm vi đánh cắp dữ liệu của infostealer.
Một điểm đáng chú ý là vào thời điểm bài viết này được thực hiện, kỹ thuật này hiện tại vẫn đang bypass được Windows Defender của Microsoft, và hoàn toàn có thể đạt hiệu quả tốt hơn nữa khi các Infostealer thật còn kết hợp kĩ thuật này với các kỹ thuật Bypass AV/EDR khác.
Tổng kết
Kỹ thuật sử dụng COM Interface để bypass App-Bound Encryption đã cho thấy sự phát triển nhanh chóng của các dòng mã độc, khi một bản vá của các Browser để bảo vệ dữ liệu đã nhanh chóng có cách để khai thác chỉ vài tháng sau đó, và được các dòng Infostealer mới như Lumma, StealC, … sử dụng rộng rãi. Tuy nhiên, kỹ thuật này vẫn có thể bị phát hiện thông qua hành vi tạo hàng loạt các tiến trình trình duyệt đáng ngờ. Và những người tham gia phân tích mã độc hoàn toàn có thể phát hiện ra kĩ thuật này thông qua các COM Interface mà chúng sử dụng.