TỔNG QUAN

Mythic C2 là một nền tảng điều khiển và ra lệnh (C2) đa người dùng được thiết kế để quản lý các agent độc hại trong các cuộc tấn công mạng phức tạp. Mythic phát triển dựa trên kiến ​​trúc container Docker, với các thành phần core - máy chủ, agent và mô-đun vận chuyển, được viết bằng Python. Kiến trúc này cho phép kẻ tấn công có thể thêm các agent mới, kênh liên lạc và các sửa đổi tùy chỉnh một cách nhanh chóng.

Vì Mythic là một công cụ đa năng dành cho tin tặc, nên từ góc nhìn của người phòng thủ, việc sử dụng nó có thể phù hợp với nhiều giai đoạn của Unified Kill Chain, cũng như một số lượng lớn các chiến thuật, kỹ thuật và quy trình (TTP) trong framework MITRE ATT&CK®.

- Tấn công chuyển hướng (pivoting): Trong chiến thuật này, kẻ tấn công sử dụng một hệ thống đã bị xâm nhập làm điểm trung chuyển để giành quyền truy cập vào các hệ thống khác trong mạng. Bằng cách này, chúng dần mở rộng phạm vi hoạt động trong cơ sở hạ tầng của tổ chức, vượt qua tường lửa, phân đoạn mạng và các biện pháp kiểm soát an ninh khác.

- Thu thập (TA0009): Một chiến thuật tập trung vào việc thu thập và tổng hợp thông tin có giá trị đối với kẻ tấn công: Các tệp tin, thông tin đăng nhập, ảnh chụp màn hình và nhật ký hệ thống. Trong bối cảnh các hoạt động mạng, việc thu thập thường được thực hiện cục bộ trên các máy chủ bị xâm nhập, sau đó dữ liệu được đóng gói để gửi cho kẻ tấ công. Các công cụ như Mythic tự động hóa việc phát hiện và lựa chọn dữ liệu mà tác nhân đe dọa đang tìm kiếm.

- Rò rỉ dữ liệu (TA0010): Quá trình chuyển thông tin đã thu thập được ra khỏi mạng bảo mật thông qua các kênh hợp pháp hoặc bí mật, chẳng hạn như HTTP(s), DNS hoặc SMB,... Kẻ tấn công có thể sử dụng các agent hoặc các máy chủ trung gian (pivot hosts) để che giấu nguồn.

- Điều khiển và ra lệnh (TA0011): Bao gồm các cơ chế thiết lập và duy trì kênh liên lạc giữa người điều hành và các máy chủ bị xâm nhập, để truyền lệnh và nhận cập nhật trạng thái. Điều này bao gồm các kết nối trực tiếp, chuyển tiếp thông qua các máy chủ trung gian và sử dụng các giao thức bí mật. Các framework phần mềm như Mythic cung cấp các khả năng C2 nâng cao, chẳng hạn như thực thi lệnh theo lịch trình, tạo đường hầm và liên lạc đa kênh, làm phức tạp việc phát hiện và ngăn chặn hoạt động của chúng.

PHÁT HIỆN HOẠT ĐỘNG CỦA MYTHIC AGENT TRONG LƯU LƯỢNG MẠNG

Tại thời điểm hiện tại, Mythic hỗ trợ truyền dữ liệu qua HTTP/S, WebSocket, TCP, SMB, DNS và MQTT. Nền tảng này cũng có hơn chục agent khác nhau, được viết bằng Go, Python và C# và nhắm mục tiêu trên Windows, macOS và Linux.

Mythic sử dụng hai kiến ​​trúc chính cho mạng lưới điều khiển của mình:

- Trong mô hình đầu tiên, các agent giao tiếp với các agent liền kề tạo thành một chuỗi kết nối, cuối cùng dẫn đến một nút giao tiếp trực tiếp với máy chủ Mythic C2. Để thực hiện điều này, các agent sử dụng TCP và SMB.

- Trong mô hình thứ hai, các agent giao tiếp trực tiếp với máy chủ C2 thông qua HTTP/S, WebSocket, MQTT hoặc DNS.

Giao tiếp P2P

Mythic cung cấp khả năng chuyển hướng kết nối thông qua các SMB pipe được đặt tên và các socket TCP. Để phát hiện hoạt động của Mythic agent ở chế độ P2P, chúng ta sẽ kiểm tra lưu lượng mạng của chúng và tạo ra các tập luật phát hiện (chữ ký) Suricata tương ứng.

Giao tiếp P2P qua SMB

Khi quản lý các agent thông qua giao thức SMB, theo mặc định, một named pipe được sử dụng để liên lạc, với tên trùng khớp với UUID của agent. Mặc dù tham số này có thể thay đổi, nhưng nó đóng vai trò là một chỉ báo đáng tin cậy và có thể dễ dàng mô tả bằng biểu thức chính quy. Ví dụ: [a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}.

Đối với giao tiếp SMB, các agent mã hóa dữ liệu theo mẫu: base64(UUID+AES256(JSON)). Dữ liệu này sau đó được chia thành các khối và truyền qua mạng.

Hình 1. Giao diện phiên lớp mạng để thiết lập kết nối giữa các agent trong Wireshark

Các lệnh và phản hồi của chúng được đóng gói trong cấu trúc dữ liệu MythicMessage. Cấu trúc này chứa ba trường tiêu đề, cũng như chính các lệnh hoặc phản hồi tương ứng: Tổng kích thước (4 byte); Số lượng block dữ liệu (4 byte); Số block hiện tại (4 byte); Dữ liệu được mã hóa Base64

Hình 2. Hiển thị một ví dụ về giao tiếp SMB giữa các agent

Agent (10[.]63[.]101[.]164) gửi lệnh đến một agent khác ở định dạng MythicMessage. Ba WriteRequest đầu tiên gửi tổng kích thước thông điệp, tổng số block và số block hiện tại. Request thứ tư truyền dữ liệu được mã hóa Base64. Tiếp theo là một chuỗi các ReadRequest, cũng được truyền ở định dạng MythicMessage.

Hình 3. Dữ liệu được truyền tải trong trường thứ tư của cấu trúc MythicMessage

Nội dung mã hóa bằng Base64. Sau khi giải mã, cấu trúc của thông tin được truyền đi sẽ hiện rõ: Bắt đầu bằng UUID của máy chủ bị nhiễm, tiếp theo là một block dữ liệu mã hóa bằng AES-256. Việc dữ liệu từ một chuỗi UUID có thể được tận dụng để tạo ra một tập luật phát hiện dựa trên chữ ký, tìm kiếm các gói mạng theo mẫu định danh đó.

Để tìm kiếm các gói chứa UUID, có thể áp dụng tập luật sau. Sử dụng các loại yêu cầu cụ thể và cờ giao thức làm bộ lọc (Command: Ioctl (11), Function: FSCTL_PIPE_WAIT (0x00110018)), sau đó kiểm tra xem tên pipe có khớp với mẫu UUID hay không.

Hình 4. Ví dụ về tập luật tìm kiếm gói UUID

Hoạt động của agent cũng có thể được phát hiện bằng cách phân tích dữ liệu được truyền trong các gói SMB WriteRequest với cờ giao thức Command: Write (9) và cấu trúc gói riêng biệt, trong đó các trường BlobOffset và BlobLen được đặt thành 0. Nếu trường Data mã hóa Base64 và sau khi giải mã bắt đầu bằng một chuỗi định dạng UUID, điều này cho thấy một kênh C2.

Hình 5. Phát hiện hoạt động của agent

Hình 6 là giao diện người dùng KATA NDR hiển thị cảnh báo về việc phát hiện một Mythic agent đang hoạt động ở chế độ P2P qua SMB. Trong trường hợp này, tập luật đầu tiên kiểm tra loại request, cờ giao thức và mẫu UUID - đã được kích hoạt.

Hình 6. Giao diện NDR cảnh báo Mythic agent hoạt động ở chế độ P2P qua SMB

Cần lưu ý rằng các tập luật này có một hạn chế. Nếu sử dụng giao thức SMBv3 với tính năng mã hóa được bật, hoạt động của Mythic agent không thể được phát hiện bằng các phương pháp dựa trên chữ ký. Một giải pháp thay thế khả thi là phân tích hành vi. Tuy nhiên, trong bối cảnh này, phương pháp này có độ chính xác thấp và tỷ lệ false positive cao. Giao thức SMB được các tổ chức sử dụng rộng rãi cho nhiều mục đích khác nhau, khiến việc phân tích các mẫu hành vi chỉ ra hoạt động độc hại một cách chắc chắn trở nên khó khăn.

Giao tiếp P2P thông qua TCP

Mythic cũng hỗ trợ giao tiếp P2P thông qua TCP. Quá trình khởi tạo kết nối xuất hiện trong lưu lượng mạng như Hình 7.

Hình 7. Khởi tạo kết nối trong lưu lượng mạng

Tương tự như SMB, cấu trúc MythicMessage được sử dụng để truyền và nhận dữ liệu. Đầu tiên, độ dài dữ liệu (4 byte) được gửi dưới dạng DWORD big-endian trong một gói riêng biệt. Các gói tiếp theo truyền số lượng block dữ liệu, số block hiện tại và chính dữ liệu đó. Tuy nhiên, không giống như các gói SMB, giá trị của trường số block hiện tại luôn là 0x00000000, do tính năng phân mảnh gói tích hợp sẵn của TCP.

Phương thức mã hóa dữ liệu cũng tương tự như những gì chúng ta đã quan sát thấy với SMB và có dạng như sau: base64(UUID+AES256(JSON)).

Hình 8. Ví dụ về gói mạng chứa dữ liệu Mythic

Hình 9. Dữ liệu được giải mã

Cũng như như giao tiếp qua SMB, các tập luật phát hiện dựa trên chữ ký có thể được tạo cho lưu lượng TCP để xác định hoạt động của Mythic agent, bằng cách tìm kiếm các gói chứa chuỗi định dạng UUID. Dưới đây là hai tập luật phát hiện Suricata. Tập luật đầu tiên không tạo ra cảnh báo bảo mật, thay vào đó gắn thẻ phiên TCP bằng một cờ nội bộ, sau đó được kiểm tra bởi một tập luật khác.

Trong khi đó, tập luật thứ hai xác minh cờ và áp dụng các bộ lọc để xác nhận rằng gói hiện tại đang phân tích ở đầu phiên mạng. Sau đó, nó giải mã dữ liệu Base64 và tìm kiếm nội dung kết quả cho một chuỗi định dạng UUID.

Hình 10. Ví dụ về hai tập luật phát hiện Mythic agent trong lưu lượng TCP

Hình 11. Giao diện NDR cảnh báo Mythic agent đang hoạt động ở chế độ P2P qua TCP

MÔ-ĐUN VẬN CHUYỂN

Liên lạc bí mật

Để thực hiện các hoạt động bí mật, Mythic cho phép quản lý các agent thông qua các dịch vụ phổ biến. Điều này làm cho hoạt động của nó ít gây chú ý hơn trong lưu lượng mạng. Mythic bao gồm các mô-đun vận chuyển dựa trên các dịch vụ Discord, GitHub và Slack. Để cùng khám phá hiệu quả hơn, bài viết này sẽ nhấn mạnh và phân tích các tập luật trên nền tảng Discord.

Mô-đun vận chuyển Discord C2 Profile

Việc sử dụng dịch vụ Discord làm trung gian cho giao tiếp C2 trong framework Mythic đang ngày càng phổ biến gần đây. Trong kịch bản này, lưu lượng truy cập của agent không thể phân biệt được với hoạt động Discord thông thường, với các lệnh và kết quả thực thi được ngụy trang dưới dạng tin nhắn và tệp đính kèm. Giao tiếp với máy chủ diễn ra qua HTTPS và mã hóa bằng TLS. Do đó, việc phát hiện lưu lượng Mythic đòi hỏi phải giải mã dữ liệu này.

Phân tích lưu lượng TLS đã được giải mã

Giả sử chúng ta đang sử dụng nền tảng NDR kết hợp với hệ thống giải mã lưu lượng mạng (kiểm tra TLS) để phát hiện hoạt động mạng đáng ngờ. Trong trường hợp này, chúng ta hoạt động dựa trên giả định rằng có thể giải mã tất cả lưu lượng TLS. Hãy cùng xem xét các tập luật phát hiện khả thi cho kịch bản đó.

Việc giao tiếp giữa máy chủ và agent diễn ra thông qua các lệnh gọi API của Discord để gửi tin nhắn đến một kênh cụ thể. Quá trình giao tiếp này sử dụng cấu trúc MythicMessageWrapper, bao gồm các trường sau:

- message: Dữ liệu được truyền đi.

- sender_id: Một GUID tạo bởi agent, được bao gồm trong mỗi tin nhắn.

- to_server: cờ chỉ hướng, một thông báo dành cho máy chủ hoặc agent.

- ID: không được sử dụng.

- final: không được sử dụng.

Điều đặc biệt thu hút sự chú ý của Kaspersky là trường message, chứa dữ liệu được mã hóa bằng Base64. Tin nhắn MythicMessageWrapper được truyền đi dưới dạng văn bản thuần túy, do đó bất kỳ ai có quyền đọc tin nhắn trên máy chủ Discord đều có thể truy cập được.

Hình 12. Ví dụ về việc truyền dữ liệu thông qua tin nhắn trong kênh Discord

Để thiết lập kết nối, agent xác thực với máy chủ Discord thông qua lệnh gọi API /api/v10/gateway/bot.

Hình 13. Dữ liệu trong lưu lượng mạng được phát hiện

Sau khi khởi tạo thành công, agent có khả năng nhận và phản hồi các lệnh. Để tạo tin nhắn trong kênh, agent thực hiện POST request đến điểm cuối API /channels//messages.

Hình 14. Lưu lượng mạng của agent đến điểm cuối API

Hình 15. Nội dung của trường message sau khi giải mã Base64

Một đặc điểm cấu trúc của UUID có thể được nhận biết ngay từ đầu gói tin. Sau khi xử lý tin nhắn, agent sẽ xóa tin nhắn đó khỏi kênh thông qua DELETE request gửi đến điểm cuối API /channels/{channel.id}/messages/{message.id}.

Hình 16. Tập luật phát hiện hoạt động giao tiếp dựa trên Discord của agent

Hình 16 cho thấy tập luật phát hiện quá trình giao tiếp dựa trên Discord của agent, nó kiểm tra hoạt động API tạo tin nhắn HTTP để tìm sự hiện diện của dữ liệu được mã hóa Base64 chứa UUID của agent.

Hình 17. Giao diện NDR cảnh báo Mythic agent trong lưu lượng HTTP được giải mã

Phân tích lưu lượng TLS được mã hóa

Nếu việc sử dụng Discord được cho phép trên mạng và không có khả năng giải mã lưu lượng truy cập, việc phát hiện hoạt động của agent sẽ gần như bất khả thi. Trong trường hợp này, phân tích hành vi của các request gửi đến máy chủ Discord có thể tỏ ra hữu ích. Dưới đây là lưu lượng mạng cho thấy các kết nối TLS thường xuyên đến máy chủ Discord, điều này có thể cho thấy các lệnh đang được gửi đến một agent.

Hình 18. Lưu lượng mạng kết nối TLS đến máy chủ Discord

Trong trường hợp này, chúng ta có thể sử dụng tập luật Suricata để phát hiện các phiên TLS thường xuyên với máy chủ Discord.

Hình 19. Tập luật phát hiện phiên TLS kết nối đến Discord

Một phương pháp khác để phát hiện các liên lạc này là theo dõi nhiều truy vấn DNS tới tên miền discord.com.

Hình 20. Tập luật phát hiện truy vấn DNS đến tên miền discord.com

Hình 21 là giao diện NDR hiển thị ví dụ về một tập luật tùy chỉnh đang hoạt động, phát hiện hoạt động của mô-đun vận chuyển Discord C2 Profile cho một Mythic agent trong lưu lượng truy cập được mã hóa dựa trên các truy vấn DNS đặc trưng.

Hình 21. Giao diện NDR cảnh báo Mythic agent trong lưu lượng dựa trên truy vấn DNS

Các tùy chọn tập luật được đề xuất có độ chính xác thấp và có thể tạo ra số lượng lớn các kết quả false positives. Do đó, cần phải được điều chỉnh cho phù hợp với các đặc điểm cụ thể của cơ sở hạ tầng mà chúng sẽ hoạt động. Các tham số “threshold” và “count”, kiểm soát tần suất kích hoạt và cửa sổ thời gian cũng cần được tinh chỉnh.

KẾT LUẬN

Framework tấn công của Mythic tiếp tục phát triển nhanh chóng. Các agent mới đang xuất hiện, được thiết kế để hoạt động bí mật trong cơ sở hạ tầng mục tiêu. Mặc dù có sự phát triển này, các triển khai khác nhau của giao tiếp mạng trong Mythic vẫn chia sẻ nhiều đặc điểm chung và phần lớn vẫn nhất quán theo thời gian. Điều này cho phép các giải pháp IDS/NDR phát hiện hiệu quả hoạt động của các agent trong framework tấn công thông qua phân tích lưu lượng mạng.

Mythic hỗ trợ nhiều tùy chọn quản lý agent sử dụng một số giao thức mạng. Phân tích của Kaspersky về hoạt động của agent trên các giao thức này cho thấy rằng, hoạt động của agent có thể được phát hiện bằng cách tìm kiếm các mẫu dữ liệu cụ thể trong lưu lượng mạng. Tiêu chí phát hiện chính liên quan đến việc theo dõi các chuỗi UUID ở các vị trí cụ thể trong dữ liệu được mã hóa Base64 được truyền đi. Tuy nhiên, mặc dù phương pháp chung để phát hiện hoạt động của agent tương tự nhau trên các giao thức, mỗi giao thức lại yêu cầu các bộ lọc dành riêng cho giao thức đó. Do đó, việc tạo ra một tập luật duy nhất, phổ quát để phát hiện các Mythic agent trong lưu lượng mạng là một thách thức.