Helpex - Trao đổi & giúp đỡ Đăng nhập
22

Trong vài năm qua, phần mềm độc hại (và một số công cụ kiểm tra bút như tải trọng máy đo của Metasploit) đã bắt đầu sử dụng phương pháp tiêm DLL phản chiếu (PDF) để tải một DLL vào bộ nhớ của một quy trình. Lợi ích là tệp không bao giờ được ghi vào đĩa và rất khó bị phát hiện. Nhiều ví dụ tôi đã thấy dựa trên công việc của Joachim Bauch .

Tuy nhiên, tại DEF CON 20 Andrew King đã chứng minh rằng ông có thể phát hiện ra DLL được tiêm bằng cách sử dụng tiêm DLL phản chiếu . Bài thuyết trình của ông được gọi là " Phát hiện tiêm phản xạ ". Thật không may, anh ta đã không phát hành mã nguồn (mà anh ta chắc chắn không có nghĩa vụ phải làm).

CẬP NHẬT : Rõ ràng là tôi đã bỏ lỡ nó, nhưng Andrew đã làm công việc này bằng mã nguồn mở vài năm trước: https://github.com/aking1012/dc20

Ngoài ra, một công cụ được gọi là " Antimeter " có thể phát hiện động cơ đồng hồ đo khi được tải bằng cách sử dụng phun dll phản chiếu. Một lần nữa, nguồn đóng.

Tôi hiểu rằng công cụ của Andrew King và Antimeter đều được viết bằng Python và sử dụng pydbg / pydasm để liệt kê bộ nhớ của các tệp thực thi đang chạy.

Có ai có một số mã nguồn chung (bằng Python, C, Delphi hoặc cách khác) mà họ sẵn sàng chia sẻ để chứng minh cách phát hiện việc tiêm DLL phản chiếu không? Có những công cụ pháp y về bộ nhớ có thể phân tích kết xuất bộ nhớ và tìm ra điều này, nhưng tôi đang tìm cách thực thi một ứng dụng trên hệ thống đang chạy (như máy đo thời gian) và tìm các quy trình có DLL được đưa vào phản chiếu.

Nếu bạn quan tâm đến việc hiểu cách hoạt động của việc tiêm DLL phản chiếu, có một số mã nguồn mở được viết bằng Delphi cho thấy cách thực hiện việc này.

CẬP NHẬT : Tôi đã thử nghiệm và tôi có thể đưa tệp DLL vào mà không có quyền quản trị viên (và với tư cách là người dùng thông thường), nhưng tất nhiên với tư cách là NGƯỜI DÙNG, tôi chỉ có thể đưa vào các quy trình chạy ở cùng mức toàn vẹn (và trong phiên của tôi) ... nhưng điều đó vẫn bao gồm các ứng dụng như bộ Office, Internet Explorer, v.v.

22 hữu ích 5 bình luận 6.5k xem chia sẻ
4

Điều gì về nối API VirtualProtect. Bởi vì các DLL tự tải chắc chắn sẽ thiết lập thực thi trên dải mã bộ nhớ của nó. Điều này là do (như bạn đã đề cập) họ sử dụng quyền truy cập của Người dùng nên họ phải sử dụng API không gian người dùng của quy trình.

NTSYSAPI NTSTATUS NTAPI ZwProtectVirtualMemory(
    IN HANDLE ProcessHandle,
    IN PVOID *  BaseAddress,
    IN SIZE_T *     NumberOfBytesToProtect,
    IN ULONG    NewAccessProtection,
    OUT PULONG  OldAccessProtection 
);

Nếu bạn kết nối điều đó ngay từ đầu chương trình của mình, bạn có thể lọc ra các lệnh gọi bảo vệ đáng ngờ (lệnh cho phép thực thi mã). Sau đó, tôi sẽ quét tiêu đề PE hoặc tương tự ở phía trước các trang được yêu cầu để biết rằng mô-đun có thể tải được của nó ... lưu ý: tôi nghĩ rằng điều này không được gọi cho các DLL thông thường vì LoadLibrary xử lý điều này bên trong không gian Kernel. đúng? VIỆC CẦN LÀM: xác minh

Thông thường, tiêu đề PE nằm ở vị trí 0x1000 (4096) byte hoặc một trang phía trước mã thực thi đầu tiên. Vì vậy, một cách tiếp cận RẤT cơ bản có thể là quét thẻ "MZ":

char* pe = ((char*)BaseAddress) - 0x1000;
if ((NewAccessProtection == PAGE_EXECUTE || ... ) & pe[0] == 'M' && pe[0] == 'Z')
{
    // do checks here
}

Nếu bạn cần thêm thông tin về API hooking, chỉ cần hỏi hoặc đọc rất nhiều bài báo trên mạng. Một ứng cử viên khác là: FlushInstructionCache (...). Nhưng tôi nghĩ chỉ có Blizzard đang sử dụng điều này cho các mô-đun chống gian lận của warden vì không có lý do gì trên kiến ​​trúc x86 để gọi điều này.

... chỉ là một suy nghĩ,

sẽ

4 hữu ích 1 bình luận chia sẻ
loading
Không tìm thấy câu trả lời bạn tìm kiếm? Duyệt qua các câu hỏi được gắn thẻ python c windows delphi winapi , hoặc hỏi câu hỏi của bạn.

Có thể bạn quan tâm

loading