Phân tích mã độc - P5
Sep 07, 2024Malware Analysis Notes (Wall of Text - Part 5)
Phát hiện debugger
- Một số mã độc sử dụng các phương pháp phát hiện công cụ debug để không thực thi khi phát hiện các công cụ này
- Che giấu hành vi khi bị debug để tránh bị phân tích
Sử dụng API IsDebuggerPresent
- API này sẽ return eax = 1 khi debugger đang attach vào tiến trình và eax = 0 khi chương trình không bị debug
- Mã độc sử dụng lệnh test eax, eax sau khi thực thi api và lệnh jmp có điều kiện để thay đổi luồng thực thi
- Nhảy vào nhánh thực thi hành vi độc hại khi eax = 0
- Nhảy vào nhánh không thực thi hành vi khi eax = 1
- Cách để bypass phương pháp IsDebuggerPresent (và các phương pháp phát hiện debugger khác nói chung)
- Cần xác định được đoạn code thực hiện việc phát hiện để thay đổi
- Search for > Current Region > Intermodular calls và tìm các đoạn code gọi IsDebugerPresent nghi ngờ
- Sau đó, khi debug, có thể thay đổi trực tiếp giá trị sau khi api được thực thi
- Đặt breakpoint tại lệnh sau lệnh call api
- Thay đổi eax = 0 khi api trả về eax = 1
- Sửa giá trị của cờ EFLAG tương ứng khi các lệnh jump có điều kiện được dùng
- Cách này phải thực hiện mỗi khi restart chương trình hoặc mỗi khi mã độc gọi api để kiểm tra
- Nếu xác định được các khối lệnh nhánh nào là thực thi hành vi độc
- Sử dụng kỹ thuật Patching để sửa các lệnh tác động tới luồng thực thi, có thể sửa theo 2 cách
- Thay lệnh jump có điều kiện = lệnh NOP nếu lệnh jump này nhảy tới đoạn code không thực thi hành vi
- Thay lệnh jump có điều kiện = lệnh jump không điều kiện (jmp) khi lệnh jump này nhảy tới vùng code thực thi hành vi
- Patching với x32dbg
- Xác định lệnh muốn sửa đổi
- Nhấn chuột phải và chọn assemble hoặc nhấn phím space
- Path bằng cách điền lệnh nop hoặc lệnh jmp, jne, je tùy mục đích muốn sửa
- Khi chỉnh sửa các lệnh, có 2 option
- Keep size: Chỉ cho phép sửa nếu kích thước của lệnh sau khi sửa <= kích thước lệnh trước khi sửa
- Ví dụ muốn sửa lệnh với kích thước 2 byte, cần dùng lệnh có kích thước 1 hoặc 2 byte
- Fill with NOP’s: thay thế toàn bộ intruction của lệnh cần sửa bằng lệnh nop nếu lệnh sau khi sửa có kích thước nhỏ hơn lệnh ban đầu
- Ví dụ với lệnh jnz address sẽ có kích thước là 6 byte và muốn patch bằng lệnh nop thay thế
- Nếu không chọn fill with nop, chỉ 1 byte đầu tiên trong 6 byte sẽ được thay bằng lệnh nop (bytecode 0x90), gây ra lỗi chương trình khi 5 byte còn lại không tạo thành lệnh có nghĩa
- Nếu chọn fill with nop, cả 5 byte còn lại sẽ được thay bằng lệnh nop, đảm bảo chương trình thực thi các lệnh vô nghĩa
- Sau khi chỉnh sửa lúc đang debug, lưu lại các thay đổi này vào file bằng các bước
- Menu File -> Patch file…
- Chọn các module muốn thay đổi và các đoạn code đã sửa trong module
- Chọn Path File để lưu lại file đã patch
Một số API khác để phát hiện debugger
- OutputDebugString
- Khi thực thi trong debugger
- Trả về 1 địa chỉ
- Không tạo ra error mới
- Khi thực thi không thông qua debugger
- Trả về 0 hoặc 1
- Tạo ra 1 error mới khác với giá trị GetLastError trước đó
- Có thể có trường hợp error trước đó trùng với error mà OutputDebugString tạo ra
- Mã độc có thể dùng api này để phát hiện debugger bằng cách
- Kiểm tra các lỗi error bằng cách gọi api trước và sau khi thực thi OutputDebugString để so sánh
- Kiểm tra giá trị trả về của OutputDebugString và so sánh với 0, 1 hoặc các giá trị lớn hơn
- CheckRemoteDebuggerPresent
- Hàm này nhận tham số là handle của 1 tiến trình và trả về kết quả là tiến trình cần kiểm tra có debugger không
- Có thể kiểm tra tiến trình khác bằng cách lấy handle thông qua OpenProcess
- Có thể kiểm tra tiến trình hiện tại bằng cách lấy handle thông qua GetCurrentProcess
- NtQueryInformationProcess/ZwQueryInformationProcess
- Có một vài tham số ProcessInfomationClass có thể sử dụng để phát hiện debugger
- ProcessDebugPort (0x7)
- Dữ liệu trả về = số port debug nếu debugger attach vào tiến trình
- Dữ liệu trả về = 0 nếu tiến trình không bị debug
- ProcessDebugObjectHandle (0x1e)
- Dữ liệu trả về = handle hợp lệ của debug object nếu debugger attach vào tiến trình
- Dữ liệu trả về = NULL (0) nếu tiến trình không bị debug
- ProcessDebugFlags (0x1f)
- Dữ liệu trả về = giá trị của trường NoDebugInherit trong cấu trúc EPROCESS, do đó = 0 nếu debugger attach vào tiến trình
- Dữ liệu trả về != 0 nếu tiến trình không bị debug
- Cũng có thể sử dụng handle trả về từ OpenProcess hoặc GetCurrentProcess
- Một số api khác
- RtlQueryProcessHeapInformation()
- RtlQueryProcessDebugInformation()
- NtQuerySystemInformation()
- …
- Để Bypass, thực hiện tương tự như đối với api IsDebuggerPresent
- Xác định đoạn code
- Sửa giá trị trả về của api, các cờ so sánh, hoặc sửa các lệnh nhảy có điều kiện
- Patch giá trị các lệnh so sánh, rẽ nhánh để lưu ra file
Kiểm tra trực tiếp không qua API
- Ngoài việc sử dụng API, mã độc có thể kiểm tra trực tiếp trong các cấu trúc dữ liệu của tiến trình
- IsDebuggerPresent kiểm tra giá trị BeingDebugged trong PEB của tiến trình
- BeingDebugged nằm ở offset 0x2 của PEB
- Trong PEB có trường NtGlobalFlag sẽ chứa giá trị = 0x70 nếu tiến trình chạy bởi debugger
- Giá trị 0x70 là kết hợp bởi các cờ
- FLG_HEAP_ENABLE_TAIL_CHECK (0x10)
- FLG_HEAP_ENABLE_FREE_CHECK (0x20)
- FLG_HEAP_VALIDATE_PARAMETERS (0x40)
- NtGlobalFlag nằm ở offset 0x68 trong PEB của tiến trình 32bit và offset 0xBC trong PEB của tiến trình 64bit
- Code asm tương ứng sẽ truy cập vào PEB tại FS:[0x30] và kiểm tra các trường này
- mov eax, dword ptr fs:[0x30]
- mov ebx, [eax+0x2] ; ebx = BeingDebugged
- mov dl, [eax+0x68] ; dl = NtGlobalFlag
- Ngoài PEB, mã độc có thể sử dụng cấu trúc _KUSER_SHARED_DATA nằm ở địa chỉ 0x7FFE0000 (đối với xp, win 7, win 10) và kiểm tra trường KdDebuggerEnabled nằm ở offset 0x2D4 để xác định kernel mode debugger
- KdDebuggerEnabled = 3 nếu kernel mode debugger đang hoạt động
- KdDebuggerEnabled = 0 nếu kernel mode debugger không hoạt động
- Code asm
- mov dl, [0x7FFE02D4] ; dl = KdDebuggerEnabled
- test dl, **3 **
- Có thể chủ động thay đổi các trường này trong debugger khi debug để tránh bị phát hiện
- Một số giá trị flag trong các cấu trúc khác
- Heap Flags
- Heap Protection
Sử dụng so sánh thời gian thực thi
- Thời gian cũng là một trong các yếu tố mã độc hay sử dụng để phát hiện debugger
- Khi thực thi trong debugger, thời gian thực thi của các lệnh sẽ lâu hơn nhiều lần so với bình thường
- Do debugger phải xử lý đọc và hiển thị, phân tích thông tin từ câu lệnh, các thanh ghi, vùng nhớ,…
- Các api hay dùng để xác định thời gian gồm
- GetTickCount: Trả về thời gian tính bằng mili giây kể từ khi hệ thống khởi động
- GetLocalTime/GetSystemTime/NtQuerySystemTime: Trả về các thời gian hiện tại tương tứng
- Lệnh rdtsc cũng trả về giá trị time counter ứng với mỗi cycle của CPU
- Giá trị trả về nằm trong eax, edx
- Mã độc có thể kiểm tra khoảng cách giữa 2 lệnh bằng các api trả về thời gian để phát hiện debugger
- Cách xử lý tương tự như khi xử lý việc phát hiện debugger bằng api
- Xác định đoạn code gọi các hàm về thời gian và sửa giá trị trả về của api hoặc sửa/patch các lệnh so sánh, jump rẽ nhánh về đúng hướng của mã độc
Tự động bypass bằng ScyllaHide
- x32dbg có plugin ScyllaHide dùng để tự động xử lý các trường hợp anti-debug bằng api, thời gian, check flag trong PEB phổ biến
- Đối với các flag trong PEB, ScyllaHide sẽ sửa các giá trị trong cấu trúc của tiến trình để tránh bị phát hiện
- Đối với các api, ScyllaHide sẽ hook các api và thay đổi giá trị trả về của api
- Mở ScyllaHide bằng cách vào Menu Plugins -> ScyllaHide -> Option
- Tích tùy chọn các option mà mã độc hay sử dụng
- Đôi khi các api có thể được dùng với mục đích không phải để phát hiện debugger do đó việc dùng ScylaHide để can thiệp API có thể làm lỗi quá trình thực thi
- Có thể tạo profile để lưu nhanh các option cần xử lý
Xác định các công cụ phân tích
- Mã độc có thể xác đinh máy ảo, sandbox, các công cụ phân tích đang chạy để thay đổi hành vi và che dấu luồng thực thi độc
Một số dấu hiệu xác định
- Tên tập tin thực thi được phân tích có thể được fix cứng và dễ đoán (1.exe, a.exe, malware.exe, virus.exe,..)
- Tên tài khoản (john, user, test, malware,..), tên máy (JOHN-PC, Johnson, WIN7-TRAPS,..)
- Địa chỉ mac
- 00:50:56, 00:0C:29 với VMware
- 08:00:27 với Virtualbox
- Tên phần cứng: card vga, audio
- VirtualBox Graphics Adapter
- VMware SVGA
- Độ phân giải màn hình khác chuẩn HD, FHD, 2k, 4k,..
- Số lượng tập tin tài liệu, ảnh ít
- Kích thước ổ đĩa <= 256GB, ram <= 2gb, số core của cpu
- Có kết nối internet hay không
- Con trỏ chuột có thay đổi vị trí không
- Danh sách các chương trình được cài
- Thiếu các ứng dụng như office, web browser,..
- Có cài các chương trình phân tích (IDA, wireshark, VM guest tool,..)
- Danh sách các cửa sổ/tiến trình nghi ngờ
- Debugger, ProcessHacker, Ghidra,..
- Các dll được các hệ thống sandbox hoặc công cụ phân tích inject vào mỗi tiến trình để theo dõi
- Các file/registry key gắn với các ứng dụng đặc biệt của máy ảo, sandbox hoặc các công cụ phân tích
Một số cách để xác định
- Sử dụng CPUID để xác định tên cpu
- Sử dụng dữ liệu PEB để xác định số core của cpu
- API CountClipboardFormats: xác định nội dung clipboard, môi trường thật nội dung clipboard thường không để trống
- API GetCursorPos: Xác định và kiểm tra sự thay đổi vị trí của con trỏ chuột
- API GetForeGroundWindow: Xác định cửa sổ nền, môi trường thật người dùng sẽ mở và thay đổi qua lại giữa nhiều cửa sổ
- GetTickCount/GetLocalTime: Xác định Uptime của hệ thống
- SetWindowsHookExA: Tạo hook vào các cửa sổ và chỉ thực thi khi có event của người dùng như chuột (WH_MOUSE_LL), bàn phím (WH_KEYBOARD_LL),..
- API BlockInput: Chặn việc sử dụng chuột và phím tương tác với tiến trình
- API GetModuleHandleW: Truyền vào tên các dll của sandbox, công cụ phân tích để xác định dll có được chèn vào tiến trình không
- API FindWindow: Tìm kiếm tên các cửa sổ và so sánh với các công cụ, ứng dụng
- CreateToolhelp32Snapshot, Process32FirstW, Process32NextW:** xác định tên các tiến trình** và so sánh với các công cụ, ứng dụng
- RegOpenKeyExW để mở và kiểm tra key có tồn tại không
Cách để bypass
- Có thể thay đổi cấu hình, thiết lập của máy ảo, sandbox để tránh phát hiện và cố gắng dựng môi trường lab gần với môi trường end-user hơn
- Ngoài ra, có thể áp dụng phương pháp bypass các cách phát hiện debugger
- Xác định vùng code
- Step qua từng dòng và hiểu luồng thực thi khi phát hiện các công cụ
- Thay đổi và patch lại để bypass các cách phát hiện
Che dấu, mã hóa dữ liệu
- Để tránh bị phát hiện các chuỗi, mã độc có thể sử dụng các phương pháp mã hóa hoặc nén dữ liệu và chỉ giải mã khi cần sử dụng lúc thực thi
XOR
- Là một phương pháp mã hóa phổ biến
- Có thể sử dụng key 1 byte hoặc n byte tùy chọn
- Key có thể ở dạng nhiều bytes hoặc chuỗi (nhiều bytes có thể hiển thị được)
- Sử dụng xorsearch để tìm các chuỗi khi biết/đoán được 1 phần bản rõ và bruteforce key
- Option -s để lưu lại file sau khi tìm ra key và giải mã toàn bộ
- file output có tên dạng [tên_ban_đầu.XOR.key]
- file output có thể có nhiều string khác có nghĩa sau khi giải mã với key tìm được
- Option -i để tìm bất kể in hoa hay in thường
- Có thể biết/đoán thông qua monitor theo dõi ip, url, path, registry key,..
- Nếu không biết/đoán được 1 phần bản rõ, có thể sử dụng brxor.py để bruteforce cả key và bản rõ
- Hỗ trợ các mã hóa xor với key 1 byte
- brxor.py bruteforce key từ 0x01->0xff và hiển thị kết quả nếu sau khi giả mã, từ đó có trong từ điển tiếng anh
- bbcrack là một công cụ khác sử dụng nhiều thuật toán khác nhau (XOR, ROL, ADD) để bruteforce key và hiển thị kết quả dựa trên việc chấm điểm kết quả
- Option -l 1 để sử dụng 1 thay vì kết hợp nhiều phương pháp
- Sau khi tìm được key, có thể sử dụng strings để trích xuất các chuỗi khác đã được giải mã bên trong các file kết quả
- Các thuật toán xor phức tạp hơn sẽ cần phân tích và đọc hiểu code để có thể thực hiện giải mã
Stackstring
- Là kỹ thuật phổ biến để che dấu chuỗi khỏi các công cụ như strings mà không cần mã hóa bằng cách lưu từng ký tự vào stack
- Mã độc có thể kết hợp stackstring với mã hóa để làm khó việc phân tích
- Stackstring sử dụng assembly để gán từng ký tự trong 1 chuỗi vào buffer trong stack
- Thường gặp nhất là lệnh mov với source là 1 byte và dest là 1 địa chỉ stack
- Ngoài ra mã độc có thể sử dụng thanh ghi làm trung gian và mov giá trị từ thanh ghi vào stack để làm rối
- Các byte gán vào stack thường có giá trị nằm trong khoảng các ký tự in được
- Trong ghidra, có thể convert các giá trị byte sang ký tự bằng cách nhấn chuột phải vào byte, chọn convert, chọn kiểu dữ liệu là Char
- Thiết lập phím tắt để chuyển nhanh khi chọn
- Edit -> Tool Option -> Tìm option Key Binding -> Tìm option Convert To Char và gán phím tắt
- Ví dụ một số lệnh thiết lập stackstring
- mov [ebp - 0xc], 0x4d ; chr(0x4d) = ‘M’
- mov al, 0x6f
- mov [ebp - 0xa], al ; chr(0x6f) = ‘o’
- mov [ebp - 0x8], 0x7a ; chr(0x7a) = ‘z’
- …
- lea eax, [ebp-0xc] ; eax = con trỏ tới string Moz…
- Một số công cụ giúp trích xuất stackstring
- strdeob.pl
- Công cụ sử dụng objdump để trích xuất mã assembly và in ra tất cả ký tự được convert từ byte khi tìm thấy lệnh movb với source là 1 byte
- floss:
- Công cụ tự động trích xuất chuỗi, bao gồm cả chuỗi mã hóa và stackstring
- Áp dụng cho pefile và shellcode
- Có khả năng tự động xác định các hàm dùng để giải mã string trong tập tin để emulate và giải mã dữ liệu
- Hàm giải mã chuỗi thường được gọi rất nhiều lần
- Floss hiển thị kết quả ra console nên cần thêm ‘>’ để lưu kết quả ra file hoặc sử dụng pipe kết quả qua less
- floss [file] > output.txt
- Output của floss chia làm nhiều phần dựa theo kết quả trích xuất được
- Phần đầu là cleartext, tương tự như output khi dùng string
- Các phần sau là stackstring và decode string
Decrypt/Decompress
- Mã độc có thể sử dụng RtlDecompressBuffer hoặc CryptDecrypt để giải nén hoặc giải mã dữ liệu
- Đối với RtlDecompressBuffer, các tham số gồm
- CompressionFormat : Thuật toán dùng để nén
- UncompressedBuffer : Địa chỉ chứa buffer sau khi giải nén
- UncompressedBufferSize : Kích thước của buffer chứa dữ liệu sau khi giải nén
- CompressedBuffer : Buffer chứa dữ liệu ở dạng nén
- CompressedBufferSize : Kích thước của buffer chứa dữ liệu dạng nén
- FinalUncompressedSize : COn trỏ chứa kích thước của dữ liệu sau khi giải nén
- Đối với CryptDecrypt, có nhiều tham số, cần chú ý các tham số
- hKey : Handle của key sử dụng để giải mã, thường được tạo bởi api CryptImportKey
- CryptImportKey sẽ tạo ra handle với key giải mã bằng thuật toán thích hợp
- pbData : Địa chỉ buffer sẽ chứa dữ liệu sẽ được giải mã, dữ liệu sau khi giả mã sẽ được ghi đè vào buffer này
- pdwDataLen : Con trỏ trỏ tới kích thước của buffer pbData
- Thông thường luồng thực thi khi giải mã sẽ bao gồm các api
- CryptAcquireContext : 1. Chọn thuật toán mã hóa
- CryptImportKey/ : 2.1 Import key giải mã trực tiếp
- CryptCreateHash/CryptHashData : 2.2.a Sử dụng hash để giải mã, verify (có thể có hoặc không dùng)
- CryptDeriveKey : 2.2.b Import key từ hash object
- CryptDecrypt : 3. Giải mã dữ liệu
- CryptDestroyKey/CryptReleaseContext : 4. Kết thúc việc mã hóa
- Cần chú ý theo dõi buffer chứa dữ liệu sau khi mã hóa
- Sử dụng breakpoint tại api và xác định các tham số thông qua stack frame, chú ý các tham số chứa dữ liệu như UncompressedBuffer, pbData
- Theo dõi các tham số qua cửa sổ Dump
- Mã độc có thể chỉnh sửa, tác động thêm vào các buffer chứa dữ liệu giải mã
- Thử Step into/over một vài lần và theo dõi thay đổi của buffer
- Các dấu hiệu có thể nhận biết việc buffer được giải mã
- Dữ liệu là các string
- Dữ liệu là shellcode, có thể thử disassembly để kiểm tra
- Follow in Disassembler
- Chuyển chế độ hiển thị của cửa sổ dump thành dạng Disassembly: Nhấn chuột phải, chọn Disassembly
- Dữ liệu là PE file: Dựa vào các signature của cấu trúc PE: MZ, PE, section name,..
- Có thể dump PE bằng cách follow in Memory Map và thực hiện Dump Memory to File
Thay đổi luồng thực thi
- Mã độc có thể sử dụng nhiều phương pháp thay đổi luồng thực thi của các lệnh call, jump để làm khó việc phân tích
- Lệnh call/jmp có thể được thay bằng push + ret
- Chèn thêm nhiều code rác để làm rối
- Khi tuần tự các lệnh bị thay đổi, disassembler không nhận dạng đúng được luồng thực thi
SEH (Structured Exception Handling)
- SEH là cơ chế của windows để xử lý các lỗi phát sinh trong khi thực thi
- Khi chương trình gặp lỗi, các hàm exception handler sẽ được gọi để xử lý các lỗi đó
- Một số Handler được windows tạo ra, 1 số được định nghĩa bởi người dùng
- try except là 1 cách để programmer tạo ra SEH khi lập trình
- Trên windows 32 bit, SEH được lưu trong 1 danh sách linked list 1 chiều nhiều cấu trúc SEH record
- Mỗi record bao gồm 2 phần tử
- Phần tử đầu trỏ tới SEH record trước đó
- Phần tử thứ 2 trỏ tới hàm Handler
- SEH chain này cho phép windows gọi các handler để thể xử lý tuần tự khi gặp lỗi
- SEH chain được lưu trong stack, Windows theo dõi phần tử SEH record cuối cùng được thêm vào chain qua cấu trúc TIB của tiến trình
- Phần tử đầu tiên trong TIB là con trỏ tới linked list của cấu trúc _EXCEPTION_REGISTRATION (SEH record)
- Địa chỉ TIB được lưu tại thanh ghi FS
- Để đọc giá trị của phần tử SEH record đầu tiên, có thể truy cập qua FS:[0]
- mov eax, fs:[0] ; eax = pointer to first SEH record in list of records
- Windows đọc phần tử đầu tiên, sau đó duyệt toàn bộ phần tử trong list SEH record đến khi hết các record
- Phần tử cuối cùng trong list có giả trị con trỏ tới phần tử tiếp theo là 0xFFFFFFFF
- Đối với** windows 64 bit, **SEH được mô tả trong 1 bảng Exception Directory data directory của PE header
- Ngoài ra, microsoft hỗ trợ thêm vectored exception handling
- Ứng dụng cần đăng kí handler qua api
- SetUnhandledExceptionFilter
- AddVectoredExceptionHandler
- x32dbg cho phép theo dõi danh sách các handler được thêm vào thông qua tab Handler
- Ngoài ra có thể theo dõi địa chỉ của phần tử SEH đầu tiên bằng cửa sổ Watch và theo dõi giá trị fs:[0]
- Mã độc có thể lợi dụng SEH để thay đối luồng thực thi
- Chèn 1 record mới với handler là giá trị của hàm (địa chỉ muốn thực thi tiếp theo)
- Tự tạo ra exception để windows gọi tới handler đã được chèn
- Các bước thực hiện
- Đưa địa chỉ SEH handler cần thêm vào stack
- mov eax, handler_addr
- push eax
- Đưa đia chỉ của SEH record trước đó vào stack. Lúc này đỉnh stack là địa chỉ của 1 record mới (chứa SEH trước đó và handler).
- Gán địa chỉ của SEH record vừa được tạo thành vào struct TIB
- Tạo ra exception để windows gọi handler đã chèn
- Để tiếp tục debug handler qua debuger, có thể
- Xác định SEH chain, record và đặt breakpoint tại handler đầu tiên trong danh sách
- Thiết lập x32dbg để bỏ qua exception (debuger sẽ không dừng khi gặp exception)
- Option -> Preference -> chọn tab Exception
- Chọn IgnoreRange để thêm danh sách các exception code sẽ không dừng bởi debuger
- Điền Start 00000000, End FFFFFFFF để bỏ qua toàn bộ exception
- Tại ô Break On, chọn Do not break
- Hoặc sử dụng chức năng bỏ qua exception
- Step Into(skip exceptions)(Shift+F7): Bỏ qua exception và dừng tại lệnh tiếp (step vào trong lệnh call)
- Step Over(skip exceptions)(Shift+F8): Bỏ qua exception và dừng tại lệnh tiếp theo (step qua lệnh call)
- Execute Till Return(skip exceptions)(Ctrl+Shift+F9): Bỏ qua và cho chạy tiếp chương trình, chỉ dừng khi gặp breakpoint
- Có thể sử dụng Hardware Breakpoint tại handler nếu Software breakpoint không hoạt động
- Khi x32bdg break tại hàm handler, có thể step từng lệnh và tiếp tục phân tích
- Một vài mã độc tạo ra SEH handler để thực thi đoạn code unpack
- Sau khi thực thi handler xong sẽ nhảy đến đoạn code đã được unpack
- Mã độc sẽ khôi phục stack ở trạng thái khi chưa có phần tử nào được thêm vào
- Có thể sử dụng Hardware breakpoint tại địa chỉ stack đầu tiên được mã độc thêm vào
- Click chuột phải vào địa chỉ stack muốn dừng, chọn Breakpoint -> Hardware, Access -> Dword
- Có thể dừng lại và kiểm tra trạng thái mỗi khi địa chỉ stack này được truy cập. Chương trình có thể dừng khi
- Mã độc unpack xong và xóa record để truyền luồng thực cho đoạn code đã unpack
- Mã độc thêm phần tử mới vào stack lúc thực thi code đã unpack
- Ngoài ra có 1 số FP khác chương trình sẽ dừng (do windows hoặc mã độc chưa thật sự unpack)
- Khi chương trình dừng do breakpoint tại stack đã đặt, kiểm tra đoạn code đã unpack chưa bằng cách
- Kiểm tra eip xem đang thuộc module, địa chỉ vùng nhớ nào
- Tìm chuỗi, api được gọi
- Nếu chương trình đã đến đoạn code đã unpack, có thể dump bằng OllyDumpEx và khôi phục IAT bằng Scylla
TLS (Thread Local Storage)
- Là cơ chế để mỗi thread trong 1 tiến trình khởi tạo các biến, stack trước khi thực thi
- Thực tiến tiến trình không chạy, chỉ 1 hoặc nhiều thread trong tiến trình chạy
- Khi các thread chạy, windows sẽ thực thi TLS callback trước
- Mã độc có thể sử dụng TLS callback để thực thi trước khi thực thi tại Entrypoint
- Thông tin về TLS được lưu trong bảng TLS Directory của PE header
- Để dừng tại TLS Callback, cần thiết lập trong setting của x32dbg
- Setting -> Events -> Tại ô Break on, tích chọn TLS Callback
- Mã độc có thể dùng TLS callback để thực thi nhiều cơ chế kiểm tra khác trước khi thực thi tại entrypoint
- Sử dụng các kỹ thuật phát hiện debuger để thay đổi hành vi, nội dung khi entrypoint thực thi
- Kết hợp các kỹ thuật khác như mã hóa, SEH để thay đổi luồng thực thi
Một số lưu ý khác khi phân tích
Che dấu call reference
- Mã độc có thể lưu địa chỉ api vào các biến/tham số trong stack để gọi nhằm tránh bị phát hiện
- Search for intermodular call chỉ tìm thấy các lệnh call có địa chỉ là các api
- Tìm kiếm sẽ không phát hiện ra các lệnh gọi tới địa chỉ trong stack
- call dword ptr ss:[ebp+0x28]
- Có thể sử dụng tính năng của plugin xAnalyzer để phân tích 1 hàm, đoạn code hoặc cả module
- Khi phân tích 1 hàm, xAnalyzer sẽ chỉ ra các tham số, biến của hàm và mô tả dựa trên giá trị của chúng
- Nhận biết được địa chỉ các api được lưu vào stack
- Nhấn chuột phải vào cửa sổ disassembler tại hàm muốn phân tích, chọn xAnalyzer -> Analyze function
- Theo dõi các biến ở tab Local, cạnh các tab Dump
Memory breakpoint
- Trong quá trình unpack, mã độc có thể ghi đoạn code unpack vào vùng nhớ, sau đó jump đến OEP nằm trong vùng nhớ đó
- Khi xác định được vùng nhớ mà mã độc sử dụng để ghi đoạn code unpack, có thể sử dụng tinh năng Memory Breakpoint để dừng chương trình khi lệnh trong vùng nhớ được thực thi
- Khi tạo ra memory breakpoint, debuger sẽ thay đổi thuộc tính của vùng nhớ
- Muốn break khi đọc -> xóa bỏ quyền đọc
- Muốn break khi ghi -> xóa bỏ quyền ghi
- Muốn break khi thực thi -> Xóa bỏ quyền thực thi
- Khi đó, mỗi khi vùng nhớ bị tác động mà không có quyền, exception sẽ xảy ra, chương trình sẽ break tại lệnh tác động tới vùng nhớ và debugger sẽ khôi phục lại thuộc tính của vùng nhớ
- Các api như VirtualProtect có thể thay đổi quyền của vùng nhớ dẫn đến vô hiệu hóa memory breakpoint
- Để tạo ra memory breakpoint tại 1 vùng nhớ khi lệnh trong vùng nhớ thực thi
- Chọn Follow [địa chỉ] in Dump -> nhấn chuột phải chọn breakpoint -> memory, execute -> singleshoot
- singleshoot: break 1 lần duy nhất
- Restore on hit: tiếp tục đặt memory breakpoint
- Khi memory breakpoint xảy ra, eip thường đang trỏ tới OEP của vùng code đã unpack
- Có thể dump vùng nhớ ra
- Lúc này, cả vùng nhớ đang ở trạng thái sẵn sàng thực thi trên memory (địa chỉ theo virutal address của section) -> cần chỉnh sửa để khôi phục về trạng thái file PE trên đĩa (địa chỉ theo raw address của section)
- Sử dụng pe_unmmaper để khôi phục
- Cần lưu lại địa chỉ của vùng nhớ khi thực hiện dump
- pe_unmapper /in [file_file_from_memory] /base [địa chỉ cùng vùng nhớ đã dump] /out [file_file_from_memory_fixed]
- Có thể dùng thêm Scylla để fix IAT sau khi dùng pe_unmapper
Detect breakpoint on API call
- Do khi sử dụng Software breakpoint, debugger cần chèn các byte 0xCC vào vị trí muốn đặt breakpoitn, mã độc có thể kiểm tra các API để xem có bị đặt breakpoint không
- Lấy địa chỉ các api:
- GetProcAddress
- PEB -> ModuleList -> duyệt export table
- Đọc giá trị đầu tiên tại địa chỉ api và so sánh với byte 0xCC
- Ví dụ:
- mov ebx,dword ptr byte ds:[eax] ; eax = address of api
- cmp byte ptr ds:[ebx], 0xCC
- Cần dùng Hardware breakpoint tại các api để tránh bị phát hiện
- Có thể tìm các điểm khác trong api để đặt breakpoint
Tổng kết
- Mã độc có thể phát hiện debuger, công cụ phân tích, môi trường phân tích
- Thay đổi hành vi, tránh bị phát hiện
- Làm khó việc phân tích
- Cần nhận biết các kỹ thuật phát hiện để xử lý và phân tích theo đúng hành vi mã độc muốn thực hiện
- Khi mã độc muốn che dấu thông tin, thông tin đó có thể chứa nhiều giá trị
- String, unpack pe file, shellcode, key,..
- Xác định các dữ liệu trước, sau khi mã hóa, giải mã để tìm các thông tin giá trị
- Sử dụng api breakpoint
- Stackstring
- Các công cụ xử lý mã hóa xor đơn giản
- Nhận biết các pattern code của các loại hình mã hóa phổ biến: rsa, aes, rc4,..
- Luồng thực thi của mã độc có thể được che giấu, thay đổi bằng nhiều cách thức khác nhau
- Nhận biết các kỹ thuật và áp dụng các phương pháp thích hợp để xử lý
- Khi phân tích, không có 1 phương pháp áp dùng cho toàn bộ mã độc
- Có thể thử nhiều lần, nhiều phương pháp khác nhau
- Kết hợp các phương pháp thích hợp