Micheal Elford

Michael is a cybersecurity professional that is passionate about 
malware analysis and reverse engineering.

Phân tích sâu hơn về tệp thực thi dẫn đến xác nhận tệp là độc hại.

Trong bài đăng trên blog này, tôi mong muốn chia sẻ những phát hiện từ cuộc điều tra, với mục tiêu làm cho khán giả biết về các kỹ thuật có thể được sử dụng để phân tích hiệu quả phần mềm độc hại nói chung và phân tích cụ thể ASyncRAT.

Phân tích ASyncRAT

Note: All malware analysis should be carried out in a sandboxed environment.

Đây là danh sách các công cụ đã được sử dụng cho phân tích này:

• pháo sángVM
• PEStudio
• dnSpy
• đầu bếp điện tử
• Người thu gom rác

Bắt đầu phân tích Giai đoạn Một của phần mềm độc hại, bước đầu tiên là kiểm tra tệp thực thi trong PEStudio, điều này xác nhận rằng chúng tôi đang xử lý tệp .NET . Hơn nữa, chúng tôi giải thích entropy khá cao là dấu hiệu cho thấy phần mềm độc hại đang đóng gói, trong đó phần mềm độc hại tăng thêm độ phức tạp để không bị các giải pháp bảo mật phát hiện.

Bước tiếp theo của chúng tôi là kiểm tra các chuỗi của phần mềm độc hại và lưu ý bất kỳ điều gì lạ mà chúng tôi có thể muốn xem xét sâu hơn một chút sau này.

Khi kiểm tra các chuỗi, chúng tôi ngay lập tức xác định được một số chuỗi có vẻ bị xáo trộn . Như một lưu ý cho chính chúng tôi, chúng tôi đã nhấn mạnh rằng chúng tôi có thể cần triển khai ' tìm và thay thế ' sau này.

Đi xa hơn

Sau khi xác định rằng tệp được viết bằng .NET và ghi chú các chuỗi bị xáo trộn, sau đó chúng tôi chuyển sang dnSpy , một trình gỡ lỗi .NET.

Một trong những điều đầu tiên chúng tôi nhận thấy là sự khác biệt trong cách đặt tên. Tên của tệp thực thi trên máy chủ và tên của tệp thực thi được hiển thị trong dnSpy hoàn toàn khác nhau. Lý do tại sao tệp thực thi có một tên hoàn toàn khác lại được quan tâm là do nhiều tác nhân đe dọa sử dụng phần mềm độc hại đổi tên chúng để chúng không thu hút nhiều sự chú ý và có thể ẩn trên máy chủ và lặng lẽ chạy trong nền để ngay cả khi người dùng nhận thấy có điều gì đó lạ đang xảy ra với hệ thống của họ, họ sẽ bỏ qua tệp vì nghĩ rằng điều đó là bình thường và không đưa ra bất kỳ cảnh báo nào với người dùng và AV của họ.

Nhìn qua mã, có một chức năng thay thế cho một chuỗi mà chúng tôi đã lưu ý trước đó. Bây giờ chúng tôi chắc chắn về những gì đang thay thế mẫu che giấu, chúng tôi có thể kiểm tra xem các chuỗi đó là gì, điều này có thể cho chúng tôi manh mối về những gì đang xảy ra.

Kéo sợi chỉ

Để phân tích các chuỗi bị xáo trộn, chúng tôi đã sử dụng CyberChef . Trong CyberChef, chúng tôi đã sử dụng tính năng `Tìm/Thay thế` để thực hiện chức năng thay thế có trong mã. Điều này cho phép chúng tôi xem văn bản rõ ràng về những gì đã bị xáo trộn, dẫn đến việc hiểu rõ hơn về những gì đang diễn ra trong mã.

Kết quả cuối cùng của bài tập trên đã cho chúng ta phiên bản không bị xáo trộn của các chuỗi chứa “Load” và “Invoke”. Điều này cho thấy rằng một cái gì đó sẽ được tải và thực thi (“được gọi”) bởi mã có trong tệp thực thi.

Nếu bất cứ lúc nào bạn không chắc những phương pháp này thực hiện hành động gì, điều tốt nhất nên làm là Google xung quanh và tìm một số tài liệu. Lúc đầu, việc này có thể tốn thời gian nhưng đây là một phần quan trọng trong việc phân tích phần mềm độc hại.

Ở giai đoạn phân tích này, chúng tôi đã tích lũy đủ các phát hiện để bắt đầu phác thảo quỹ đạo của luồng thực thi của phần mềm độc hại. Chúng tôi đã xác định phần mềm độc hại đang tải và thực thi thứ gì đó, đồng thời phần mềm độc hại được đóng gói và chứa dữ liệu thực thi mà chúng tôi sẽ thấy trong giai đoạn phân tích tiếp theo.

Săn tìm Ẩn

Công cụ Garbage Man được sử dụng để phân tích đống — một kỹ thuật cho phép các nhà phân tích can thiệp và quan sát khi phần mềm độc hại .NET tự làm sáng tỏ.

Việc phân tích phần mềm độc hại trong Garbage Man đã hỗ trợ trích xuất dữ liệu ẩn bao gồm tệp thực thi thứ hai trong tệp thực thi đầu tiên .

Để phân tích sâu hơn về phần mềm độc hại, chúng tôi đã thực thi phần mềm độc hại ban đầu được tìm thấy trên máy chủ trong Garbage Man. Để bắt đầu, chúng tôi đã thêm độ trễ 300 mili giây với 10 ảnh chụp nhanh được thực hiện trong khoảng thời gian 100 mili giây.

Chúng tôi đã thêm độ trễ để có thời gian cho quy trình bắt đầu chạy, đồng thời thêm các ảnh chụp nhanh và khoảng thời gian bổ sung để chúng tôi có thể so sánh sự khác biệt giữa các khoảng thời gian nếu cần.

Khi Garbage Man đã thực thi tệp, chúng tôi có các tùy chọn sau:

• Lọc qua đống theo cách thủ công và xem xét các chuỗi và giá trị có trong tệp thực thi
• Sử dụng chức năng tìm kiếm để xem qua tất cả các ảnh chụp nhanh. Cụ thể là tìm kiếm các byte bắt đầu bằng giá trị của MZ — là tiêu đề PE cho tệp thực thi và tệp dll, sau đó sắp xếp chúng theo kích thước theo thứ tự giảm dần. Chức năng tìm kiếm cung cấp cho chúng tôi danh sách kết quả và chúng tôi có thể lưu các tệp nhị phân với tiêu đề MZ và lưu chúng để phân tích thêm.

giai đoạn hai

Đi sâu vào stage2.exe của chúng tôi, chúng tôi nhận thấy rằng việc kiểm tra các chuỗi của nó đã làm nổi bật một số API Win32 đáng chú ý mà phần mềm độc hại tận dụng . Một số API xuất hiện có liên quan đến việc thao túng các quy trình [ T1055 ], cụ thể trong trường hợp này là làm rỗng quy trình [ T1055.012 ] — một kỹ thuật đối nghịch để tạo một quy trình hợp pháp, bị tạm dừng, sau đó tráo đổi bộ nhớ của nó bằng nội dung độc hại.

Khi giai đoạn hai của chúng tôi lại ở trong thế giới .NET, chúng tôi đã sử dụng dnSpy để tìm hiểu sâu hơn một chút. Khi mở tệp thực thi, chúng tôi đã gặp rất nhiều thông tin mà chúng tôi phải xem qua. Giống như giai đoạn đầu tiên, quy ước đặt tên của giai đoạn thứ hai cũng đáng ngờ.

Kiểm tra đầu ra của dnSpy, chúng tôi đã phát hiện ra một phần hoàn toàn khác với các phần khác của mã do nó bị xáo trộn và dường như đang thực hiện một chức năng trong bộ nhớ — cả hai đều là kỹ thuật được sử dụng để tránh bị phát hiện [ T1140 ] .

Một lần nữa, chúng tôi đã sử dụng Garbage Man để lén lút quan sát cách phần mềm độc hại tự giải mã. Tuy nhiên, nếu bạn muốn có một kỹ thuật thay thế để giải mã phần mã này, bạn có thể sử dụng de4dot cũng có thể trình bày nó ở định dạng dễ đọc hơn.

Tiếp theo, trong Garbage Man, mục tiêu là lấy được giai đoạn ẩn thứ ba . Kỹ thuật trước đây của chúng tôi có thể được triển khai lại ở đây, thực thi mã nhị phân và tìm kiếm các tiêu đề MZ.

Chúng tôi đã tìm thấy một tệp thực thi và lưu nó dưới dạng “stage3.exe”. Sau đó, chúng tôi đã đóng gói và chuyển nó đến PEstudio (Cũng có thông tin về procexp.sys có trong này nhưng chúng tôi sẽ không tập trung vào điều đó vào lúc này).

giai đoạn ba

Khi kiểm tra tệp thực thi giai đoạn thứ ba trong PEstudio, chúng tôi lại quan sát thấy tệp này là tệp .NET và chứa các chuỗi và API cho thấy tệp đang cố tạo kết nối mạng với nguồn bên ngoài — như API Gửi . Đây là một gợi ý lớn rằng đây là một Trojan Truy cập Từ xa; Tôi ngửi thấy mùi CHUỘT [ TA0011 ]!

Sau khi chúng tôi xem nhanh các chuỗi của giai đoạn ba thông qua PEstudio, chúng tôi đã quay trở lại với dnSpy đáng tin cậy. Rà soát qua giai đoạn ba, chúng tôi đã xác định rằng mã hóa AES đã được sử dụng để mã hóa cổng và IP/miền tạo nên lệnh và kiểm soát của đối thủ (C2). Chúng tôi chắc chắn đã xử lý RAT và chúng tôi muốn thu thập các IoC liên quan đến mã hóa này.

Chúng tôi đặt một điểm dừng trong dnSpy nơi thực hiện giải mã AES, sau đó chạy trình gỡ lỗi cho việc này để tìm chuỗi đã giải mã. Việc sử dụng kỹ thuật 'dừng bắt đầu' với các điểm ngắt trong trình gỡ lỗi cho phép nhà phân tích phần mềm độc hại tạm dừng phần mềm độc hại vào những thời điểm thích hợp khi nó tự giải mã hoặc giải mã. Điều này cho phép chúng tôi hiểu những gì phần mềm độc hại đang làm khi nó đang làm.

Khi chúng tôi đến điểm ngắt, nó tạm dừng quá trình thực thi của phần mềm độc hại. Giờ đây, chúng tôi đã thận trọng cho phép phần mềm độc hại tiến từng bước một bằng cách sử dụng nút bước qua. Chúng tôi đã làm điều này cho đến khi phần mềm độc hại cuối cùng bắt đầu giai đoạn giải mã và lần đầu tiên chúng tôi được tặng các cổng được sử dụng bởi RAT này.

Khi chúng tôi xem qua các phần khác nhau, chúng tôi có thể thấy rằng đối với RAT này, nó đang sử dụng các cổng “6606, 7707, 8808” và cuối cùng chúng tôi đã làm sáng tỏ RAT cho đến khi nó gửi cho chúng tôi máy chủ đối thủ mà nó đã báo cáo lại: “109.206.241 [.]84”.

Bảo vệ chống lại RAT

Các biện pháp khắc phục của chúng tôi sẽ khác nhau, nhưng bước đầu tiên là khuyên bạn nên chặn IPv4 công cộng này ở cấp độ tường lửa của tổ chức để RAT không thể báo hiệu nữa.

Lời khuyên để bảo vệ chống lại RAT thực sự là lời khuyên cho phần mềm độc hại nói chung:

• Lời khuyên chính là đào tạo nhân viên kiểm tra những gì họ đang tải xuống. Cho dù đó là từ tệp đính kèm email hay trang web hứa hẹn sẽ làm cho máy tính của họ chạy nhanh hơn nếu họ chạy thứ gì đó, đào tạo nâng cao nhận thức về bảo mật là lớp bảo vệ đầu tiên và tốt nhất mà chúng tôi khuyên bạn nên ưu tiên.
• Tận dụng phép đo từ xa của mạng để thử và theo dõi hoạt động không mong muốn. Cho dù đây là VPN, tường lửa hay luồng mạng tập trung vào bảo mật hơn, thì việc theo dõi lưu lượng truy cập vào và ra sẽ giúp phát hiện hành vi bất thường. Hơn nữa, việc xây dựng một danh sách từ chối được duy trì tốt cho các địa chỉ độc hại mới và đang nổi lên chỉ có thể là một điều tốt.
• Các công cụ bảo mật tốt là kẻ thù hoàn hảo của các đối thủ của chúng ta. Triển khai những gì phù hợp với tổ chức của bạn, chỉ cần triển khai một cái gì đó . Máy không có bất kỳ giải pháp bảo mật nào là máy gây ra rủi ro không thể quản lý, không thể chấp nhận được đối với doanh nghiệp của bạn.

Big thanks to Matthew Brennan and Chad Hudson for help and guidance. 
Hopefully this writeup has helped show examples of some good tools and 
techniques that can be used to help decrypt and understand what is going on 
with other .NET executables in the future.