Phân tích mã độc - P4

Malware Analysis Notes (Wall of Text - Part 4)

• Packer 101
  • Packer là gì
  • Xác định pack/packer
• Unpacking 101
  • Hướng thực hiện
  • Scylla
  • Các tính năng của debuger trong khi debug
  • Sử dụng debugger để tìm entrypoint và dump
• Debugging Packed File
  • Debug packed File
• Phân tích mã độc nhiều stage và kỹ thuật trong thực tế
• Code injection
  • Shellcode injection
  • Api hooking
  • Process Hollowing
• Tổng kết

Packer 101

Packer là gì

• Packer là các công cụ được sử dụng để thay đổi tập tin PE với mục đích chính gồm:
  • Giảm kích thước của tập tin PE bằng cách nén các section
  • Che dấu code gốc ban đầu bằng cách mã hóa, làm rối,..
• Các packer phổ biến bao gồm cả free và có bản quyền: UPX, Enigma, MPRESS, Themida, VMProtect
  • UPX phổ biến vì ổn định và miễn phí và hiệu quả nén cao
    • Kèm theo công cụ unpack (upx -d) nhưng có thể bị custom để không thể unpack bằng công cụ chính thống
  • Các packer có bản quyền thường có nhiều tính năng với mục đích để bảo vệ code gốc tránh bị dịch ngược.
  • Vẫn có các packer tự viết, chưa được public thông tin
• Packer thường nhận input là 1 file PE và sinh ra output là 1 file PE khác bao gồm
  • Phần code unpack
  • Phần dữ liệu sau khi đã nén/mã hóa code trong file pe gốc.
• Một số packer có thể ẩn các thông tin quan trọng trong PE header như entrypoint, IAT, data, resource trong tập tin PE
• Đa số packer dùng chung 1 đoạn code để nén/mã hóa file gốc, chỉ thay đổi các tham số, nội dung dữ liệu dựa vào file cần pack
  • Có thể nhận diện được file bị pack hay không bằng cách xác định các dấu hiệu của đoạn code dùng để unpack
• Khi thực thi, đoạn code unpack của packer thực hiện unpack code gốc trên mem (giải nén, giải mã,..) sau đó sẽ thực thi code gốc
• Đa số các file trên windows không được pack, số ít phần mềm được pack để tránh bị dịch ngược
  • Đôi khi các file pack có thể bị crash khi thực thi đoạn code unpack nên NSX chọn không pack để đảm bảo tính ổn định
• Mã độc có thể dùng packer hoặc không dùng tùy vào mục đích của attacker
  • Không sử dụng pack để giảm độ nghi ngờ và ưu tiên tính ổn định
  • Sử dụng packer tự viết thay vì các packer đã có sẵn để làm khó việc dịch ngược đồng thời giảm khả năng bị phát hiện là được pack

Xác định pack/packer

• Các packer phổ biến thường đính signature của packer trong file pack
  • tên section (.upx0, .pack, .vmp0,…)
  • chuỗi chứa tên packer
• Một số dấu hiệu khác
  • Entropy (tính ngẫu nhiên) của file hoặc từng section chứa code, data lớn
    • entropy là độ ngẫu nhiên của dữ liệu, được đo theo thang từ 0-8
    • con số ước chừng cho entropy của 1 section bị pack là > 6.5
  • Ít các chuỗi có nghĩa và ít API trong IAT
  • Thuộc tính VirtualSize và RawSize của một section có chênh lệch lớn hoặc có bất thường (=0, data rất lớn, hoặc data rỗng,..)
  • Phân tích tần suất phân bổ của các byte trong file bằng công cụ bytehist để tạo và phân tích histogram
    • File chưa nén (unpack) thường có phân bổ byte ngẫu nhiên, lộn xộn, dàn trải hơn
    • File được nén (pack) thường có phân bổ các byte có tổ chức, sắp xếp, tập trung hơn
• Các công cụ có sẵn tập các dấu hiệu để nhận biết packer và hiển thị các thông tin khác giúp xác định packer: pestudio, DIE, Exeinfo,..
• Lợi ích khi xác định file bị pack/không pack và packer
  • Có hướng phân tích thích hợp (có thể phân tích tĩnh luôn hay cần unpack,..)
  • Biết packer có thể tìm kiếm thông tin để phân tích, unpack packer đã được phân tích

Unpacking 101

Hướng thực hiện

• Phương pháp unpack đơn giản nhất là để file pack thực thi và tự unpack ở trên mem sau đó dump vùng mem chứa mã đã unpack
  • Áp dụng đối với các packer đơn giản như UPX hoặc các bản modify của upx
  • Một số công cụ tự động unpack có thể áp dụng: upx -d, Ether, UnpacMe, các script có sẵn
  • Kiểm tra tiến trình khi thực thi để biết đã được unpack
    • Kiểm tra string trên memory: có nhiều string có nghĩa
      • Xem trực tiếp trên tiến trình bằng process hacker -> properties của tiến trình -> memory -> strings
      • Dùng các công cụ dump tiến trình (procdump, task manager,..) và kiểm tra string của file dump
    • Theo dõi các hành vi đối với file, registry, network, process
      • Các đoạn code unpack thường không hoặc ít tương tác với các tài nguyên mà chỉ tự giải mã trên vùng nhớ
      • Khi các hành vi cụ thể được thực thi thì nhiều khả năng file đã unpack trên mem
• Khi phân tích động, có thể vô hiệu hóa tính năng ASLR của mã độc để giữ nguyên ImageBase theo header khi debug
  • ASLR là tính năng tự động thay đổi giá trị địa chỉ ImageBase trên memory khi thực thi
    • Địa chỉ của ASLR cấp là ngẫu nhiên, khó khai thác lỗ hổng hơn
  • Nên tắt ASLR trên từng file bằng cách thay đổi giá trị cờ trong trường DllCharacteristics (Dll can move)
    • Cff explorer hoặc các công cụ parser PE cho phép chỉnh sửa
    • setdllcharacteristics
• Có thể tiến hành phân tích tĩnh vùng nhớ đã được dump để tìm kiếm thông tin
  • Vùng nhớ không thể sử dụng để phân tích động, không đúng cấu trúc file pe
• Để có thể dump file pe và phân tích động, cần nhiều hơn
  • Dump tiến trình theo pe header và rebuild header dựa trên các vùng nhớ trên mem
  • Rebuild bảng IAT
  • Tìm và khôi phục entry point
  • Sử dụng các công cụ để hỗ trợ các mục tiêu này
    • Debugger, Scylla, OllyDump, PE Tools, ImportFixers..

Scylla

• Scylla là công cụ dumping có thể thực thi độc lập hoặc dưới dạng plugin của trình duyệt, các chức năng chính
  • Dump tiến trình hoặc vùng nhớ
  • Rebuild header
  • Tìm và rebuild IAT
  • Có 2 bản 32/64 bit để dump tiến trình 32/64 tương ứng
• Các sử dụng thông dụng
  • Chọn một tiến trình đang thực thi tại bảng “Attach to an active process”
  • Nhấn Dump ở bảng dump để dump tiến trình theo định dạng từ peheader
    • Lưu lại file dump, mặc định file dump có thêm hậu tố _dump
  • Tại bảng IAT info, chọn IAT Autosearch -> Get Imports để tìm bảng IAT
  • Chọn Fix Dump từ bảng dump và chọn file dump đã lưu để thêm iat cho file dump
    • File kết quả có bảng IAT có thêm hậu tố _scy
• File sau khi dump và rebuild IAT có thể dùng để phân tích tĩnh nhưng không thực thi đúng được
  • File dump vẫn chứa code cũ, bao cả code dùng để unpack
  • entrypoint vẫn trỏ và thực thi tại đoạn code sử dụng để unpack khi chạy nhưng sẽ bị lỗi vì dữ liệu đã được unpack khi dump
  • Để có thể thực thi, cần tìm entrypoint thật (trỏ tới vùng code sau khi unpack) và sửa trường entrypoint trong PE header

Các tính năng của debuger trong khi debug

• Debugger có thể kiểm soát từng lệnh thực thi do đó có thể xác định entrypoint sau khi unpack
• Sử dụng Debugger với option chạy và dừng chương trình để dừng chương trình tại các vị trí mong muốn
  • Run (F9): chạy chương trình, chỉ dừng khi gặp breakpoint
  • Run until sellection (F4): Chạy chương trình và dừng khi chạy đến lệnh tại địa chỉ đang chọn
  • Pause (F12): Tạm dừng luồng thực thi, ở bất kì đâu, ko kiểm soát được vị trí dừng
  • Restart (Ctrl+F12): Khởi động lại chương trình
  • Step into (F7): chạy từng lệnh, khi gặp lệnh call sẽ step vào trong của hàm được gọi
  • Step over (F8): chạy từng lệnh, khi gặp lệnh call sẽ không step vào trong mà chạy đến lệnh tiếp theo sau hàm call
  • Execute till return (Ctrl+F9): Chạy chương trình và dừng khi gặp lệnh ret
  • Run to usercode (Alt+F9): Chạy chương trình và dừng khi chạy đến lệnh trong vùng usercode
    • Mặc định Usercode thường là các vùng nhớ trong module của tập tin được debug hoặc module dll khác dll hệ thống
    • Các vùng nhớ tạo ra bởi api như VirutalAlloc, malloc cần được thêm vào virtual memory trước khi áp dụng tính năng này
• Memory Map là bảng các vùng nhớ của tiến trình, bao gồm các vùng nhớ của từng header, section file exe, dll, stack và các vùng nhớ cấp phát động
• Có 2 loại breakpoint khi debug
  • software breakpoint: Debugger sửa giá trị tại địa chỉ muốn dừng = cách thay giá trị cũ = lệnh ngắt INT3 (0xcc) để dừng chương trình và khôi phục giá trị cũ khi chương trình đã dừng tại bp
    • SW BP có thể làm lỗi việc thực thi khi mã độc kiểm tra hoặc sử dụng các giá trị của nội dung code (vì code đã được sửa khi chèn bp)
    • Tại các vùng nhớ cấp phát động hoặc các vùng nhớ bị sửa đổi (chứa code unpack), khi đặt sw breakpoint chỉ có tác dụng tại thời điểm đó
      • Khi chương trình kết thúc các SW breakpoint đó có thể sẽ không lưu lại được
  • hardware breakpoint (tính năng của cpu): Luôn dừng khi cpu (eip, rip) thực thi đến địa chỉ đã đặt

Sử dụng debugger để tìm entrypoint và dump

• Dùng debugger và load file pack lên và bắt đầu debug tại vùng code của đoạn code unpack
• Xác định đoạn kết thúc của code unpack
  • Thường có các lệnh jump, call,.. đến 1 vùng nhớ khác chứa code đã được unpack
• Để chương trình thực thi đến hết đoạn code unpack và jump tới vùng nhớ khác
  • Sử dụng breakpoint để dừng tại địa chỉ mong muốn
  • Sử dụng sigle-step để chạy từng lệnh
  • Kiểm tra vùng nhớ được jump tới để xác định code đã unpack chưa bằng các so sánh trước và sau khi đoạn code unpack thực thi
    • Dựa vào string reference trong vùng nhớ
      • Search for -> current region -> string reference
    • Dựa vào API được gọi
      • Search for -> current region -> internmodular call (api)
• Dump tiến trình và chỉ định OEP (Original Entry Point) là địa chỉ của vùng nhớ chứa code đã được unpack
  • Sử dụng OllyDump hoặc Scylla để dump, lưu ý điền Entrypoint theo địa chỉ đã xác định
• Khôi phục IAT bằng scylla
  • IAT Autosearch -> Get Imports -> Fix Dump và chọn file dump để fix
  • Nếu các phương thức tìm IAT mà scylla dùng cho kết quả khác nhau, có thể thử từng trường hợp
• Tùy vào packer, việc xác định đoạn code unpack và vùng nhớ sau khi unpack chứa OEP cũng như khôi phục IAT sẽ có mức độ khó dễ khác nhau
  • Khi phân tích sẽ khó hơn và mất nhiều thời gian hơn
  • Bù lại, file dump có thể dùng để phân tích động, tĩnh
  • Có thể dump được chính xác hơn và có điểm bắt đầu phân tích code có điểm bắt đầu khi tìm được OEP

Debugging Packed File

Debug packed File

• Với cac packer phức tạp, khó để dump 1 file hoàn chỉnh, có thể dùng để phân tích động
  • Khó xác định, phân biệt bắt đầu và kết thúc các vùng nhớ unpack code và chứa code được unpack
  • Mất nhiều thời gian tìm và khôi phục OEP, IAT, PE header
• Hướng phân tích khác là debug trực tiếp trên debuger mà không dump
  • Sử dụng breakpoint để dừng tại tại các api hay dùng, đáng nghi ngờ
    • Giúp theo dõi tiến trình (ghi file, registry, process inject, network) và các tương tác với dữ liệu (decrypt, encrypt, hashing..)
      • Có thể sử dụng command SetBPX [tên api] hoặc bp [tên api] để đặt bp tại các điểm bắt đầu trước khi api thực thi
    • Có thể bắt đầu phân tích tại các hành vi mong muốn dựa vào api
    • Không hiệu quả khi malware sử dụng các api hiếm, ít gặp hoặc các cách bypass api khác
  • Xác định vùng nhớ chứa unpack code và phân tích để tìm đoạn code muốn kiểm tra
    • Xác định các vùng nhớ nghi ngờ qua cửa sổ Memory Map của debuuger
      • Các vùng nhớ của section trong file có thuộc tính Execute (E)
      • Các vùng nhớ khác chứa thuộc tính RWE
      • Các vùng nhớ nằm trong section có thuộc tính đặc biệt
        • tên section
        • các trường kích thước RawSize, VirtualSize khác biệt
    • Phân tích các vùng nhớ dựa vào String reference, api reference để tìm các vị trí gọi api hoặc xử lí chuỗi muốn debug
  • Sau khi tìm được các vị trị và đặt breakpoint, thực thi lại chương trình để dừng và tiếp tục debug tại các breakpoint đã chọn
    • Khi sử dụng software breakpoint mà không có tác dụng (BP bị vô hiệu hóa khi restart chương trình) có thể dùng hardware breakpoint

Phân tích mã độc nhiều stage và kỹ thuật trong thực tế

• Trên thực tế, mã độc thường có nhiều stage sử dụng kỹ thuật, phương thức khác nhau để đạt được mục đích
  • Kết hợp từ initial access qua phising, thực thi obfuscate script (js, powershell,..), lợi dụng file hệ thống, thực thi shellcode và file thực thi exe, dll
  • Mục tiêu thường gặp
    • persistent
    • trojan
    • c2c connect
    • steal data
    • ransomware
• Mã độc thường sử dụng process injection để thực thi code bên trong 1 tiến trình khác
  • Che dấu file thực thi ban đầu
  • Bypass các giải pháp bảo vệ (whitelist theo tên, path tiến trình)
  • Mã độc ưu tiên tạo tiến trình mới để làm mục tiêu inject hơn là chọn những tiến trình đang chạy
    • Tiến trình cha sẽ có full quyền tác động lên tiến trình con
    • Tránh trường hợp làm lỗi các tiến trình đang chạy, gây chú ý và bị phát hiện
    • Có thể sử dụng xem process dạng tree hoặc parser log tạo tiến trình theo tree để tìm tiến trình cha của các tiến trình bị inject
• Mã độc hay sử dụng các tiến trình hệ thống để thực hiện hành vi độc hại (LOLBIN), nhằm tránh bị phát hiện
  • wmic để tương tác với WMI và thực thi lệnh
    • Tiến trình wmiprvse.exe (C:\Windows\System32\wbem\WmiPrvSE.exe) chạy dưới dạng dịch vụ WMI Provider Host sẽ được dùng để khởi tạo các tiến trình con khi thực thi tiến trình mới qua WMI
  • mshta để thực thi html, hta hoặc trực tiếp js
    • mshta có thể tạo tiến trình mới và thực thi các script khác qua powershell, wscript/script
• Cơ chế persistent phổ biến của mã độc là thiết lập các giá trị để tự khởi động command, chương trình trong các khóa registry ASEPs (auto-start extensibility points)
  • Ngoài registry, còn có service, task schedule, thư mục startup,..
• Registry phân biệt giữa thiết lập chung của hệ thống và thiết lập của từng người dùng
  • HKLM (HKEY_LOCAL_MACHINE)là khóa registry chứa config của hệ thống
  • HKCU (HKEY_CURRENT_USER) là ánh xạ khóa registry chứa config của riêng user hiện tại, mỗi user sẽ có một registry key riêng
  • Đối với hệ thống 64 bit còn có khóa Wow6432Node để cho các ứng dụng 32 bit truy cập, các cấu hình tương tự 64 bit
• Một số entry registry ASEP phổ biến, có thể thiết lập trên HKLM, HKCU hoặc Wow6432Node
  • SOFTWARE\Microsoft\Windows\CurrentVersion
    • \Run
    • \Policies\Explorer\Run
    • \RunOnce
    • \Policies\System\Shell
  • \SOFTWARE\Microsoft\Windows NT\CurrentVersion
    • \Winlogon\Userinit
    • \Winlogon\Shell
    • \Windows\Appinit_Dlls
    • \Windows\Run
    • \Windows\Load
  • \Software\Policies\Microsoft\Windows\System\Scripts
    • \Startup
    • \Shutdwn
    • \Logon
    • \Logoff
• Các mã độc fileless không lưu trữ script hoặc nội dung thực thi trên file mà có thể lưu trữ nội dung dữ liệu trên registry
  • Mã độc sẽ sử dụng các tiến trình lolbin để đọc và thực thi nội dung từ registry
• Mã độc có thể chỉnh sửa khóa registry HKCU\Software\Classes để thay đỗi dữ liệu về định dạng hỗ trợ mở/thực thi.
  • Thay đổi chương trình để mở/chạy file theo phần mở rộng
  • Thêm phần mở rộng mới bất kì và command thực thi khi mở file với phần mở rộng đó
  • Nội dung trong khóa HKCU\Software\Classes
    • HKCU\Software\Classes.[phần mở rộng bất kì]: bắt đầu bằng dấu ., bên trong khóa có giá trị (Default) chứa ProgID của chương trình sẽ dùng để mở file với phần mở rộng này
    • HKCU\Software\Classes\[ProgID]\Shell\open\command: chứa command để thực thi khi mở file trong khóa có giá trị (Default)
• Có thể export dữ liệu từ registry ra bằng regedit, powershell, reg hoặc reg_export
  • Ctrl+A -> Ctrl+C: có thể copy được dữ liệu khi xem bằng regedit
• Mã độc có thể có nhiều stage khác
  • script js: obfuscate và thực thi bằng eval hoặc tạo object Wscript.shell và thực thi powershell
  • script powershell có thể sử dụng IEX (Invoke-Expression) và FromBase64String để giải mã và thực thi powershell script
• Đối với các stage script bị obfuscate, có thể sử dụng emulator, interpreter, amsi để phân tích kết hợp với đọc hiểu script, deobfuscate thủ công
• Các script powershell thường được dùng vì khả năng tương tác mạnh với hệ điều hành
  • Có nhiều library sẵn để mã hóa/giải mã, encode/decode, gọi api hệ thống
  • Tương thích với phần lớn hệ điều hành hiện tại (Từ powershell 2.0->7.0)
• Powershell có thể gọi api của bất kì dll nào thông qua [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer và Invoke
• Có thể sử dụng Powershell ISE để debug, chỉnh sửa script powershell
  • Hỗ trợ breakpoint, step, xem giá trị các biến, gọi các hàm
• Powershell có thể ghi dữ liệu dạng byte ra file bằng lệnh [io.file]::WriteAllBytes
• Thông thường các script powershell có thể giải mã và thực thi shellcode đồng thời truyền tham số cho shellcode
• Khi sử dụng scdbg
  • Có thể dùng command “.poke4”: để chỉnh sửa giá trị của địa chỉ, thanh ghi
    • Chỉnh sửa tham số thông qua stack (esp + x) hoặc qua register (ecx, edx,..)
  • Kiểm tra stack bằng lệnh “k”
  • Sử dụng g để thực thi shellcode
• Runsc có sẵn lệnh gọi shellcode và truyền tham số kèm theo là địa chỉ của shellcode
  • mặc định runsc sẽ tạo 1 vùng nhớ, và in ra địa chỉ vùng nhớ đã tạo, sau đó tạo thread mới ở trạng thái tạm dừng thực thi
    • Dùng debuger attach (File->Attach) vào và đặt breakpoint tại địa chỉ shellcode runsc hiển thị
    • Nhấn enter để runsc tiếp tục thực thi
• Khi sử dụng SetBPX (hoặc bp) trong xdbg và chỉ định các api cần đặt breakpoint, có thể thêm tên dll vào trước tên api để chỉ định chính xác api nằm trong dll nào
  • Ví dụ SetBPX advapi32.RegOpenKeyExA
• Khi debugger dừng tại các api có thể tìm đoạn code đã gọi tới api thông qua
  • Tính năng Run to usercode: Tự động chạy và dừng khi gặp usercode. Nếu debugger không xác định được đúng usercode sẽ bỏ qua mất đoạn code gọi tới api
  • Tính năng Run until return: Chạy và dừng mỗi khi gặp lệnh ret, thực hiện single step để quay lại và kiểm tra vùng nhớ vừa gọi tới api
  • Call Stack: Là bảng lưu các địa chỉ được đưa vào stack khi thực hiện lệnh call, do đó có thể dùng để trace địa chỉ gọi tới api.
    • Khi xác định được địa chỉ code gọi tới api, có thể đặt bp tại các lệnh tiếp theo sau địa chỉ đó và cho chương trình tiếp tục thực thi api đến khi dừng tại vị trí mong muốn
• VirutalAlloc thường được malware sử dụng để unpack
  • Tạo ra vùng nhớ mới để chứa unpack code
    • Khi debug api này, xác định vùng nhớ được tạo ra bằng cách theo dõi eax/rax khi api thực thi xong
    • Sử dụng chức năng Follow in Dump để xem và theo dõi vùng nhớ vừa tạo
  • Mã độc có thể sử dụng virtualalloc nhiều lần
    • Nên kiểm tra giá trị trả về của virtualalloc và theo dõi sự thay đổi của các vùng nhớ được cấp này mỗi khi api này được gọi
    • Sử dụng các cửa sổ dump2 dump3,.. để xem các vùng nhớ qua các tab khác nhau
  • Nhận dạng các vùng nhớ đặc biệt
    • Được cấp phát với thuộc tính permission RWE (0x40)
      • Mã độc có thể cấp phát với thuộc tính RW sau đó sử dụng VirtualProtect để thay đổi thuộc tính thành RWE hoặc RE
    • Chứa PE header (MZ, PE,..)
    • Chứa các dữ liệu giải mã (string đặc biệt như path, registry, c2c,..)
  • Đối với các vùng nhớ chứa PE header, có 2 dạng
    • File PE dạng raw, chưa được map lên memory theo virtual address, size, có thể dump và lưu trực tiếp ra file
      • Follow in MemoryMap -> Dump memory to File
    • File PE dạng virtual, đã được map lên memory theo virtual addres, size. Cần dump dạng rebuild dựa vào header
      • Dump bằng scylla hoặc ollydump
• Ngoài ra mã độc còn sử dụng LocalAlloc, HeapAlloc, malloc với mục đích tương tự

Code injection

Shellcode injection

• Ngoài tác dụng bypass các giải pháp bảo vệ và tránh bị phát hiện, Process Injection có thể được dùng để
  • Inject unpack code vào tiến trình khác, gây khó phân tích
  • Kết hợp với api hooking để tạo thành usermode rootkit
    • Rootkit là các mã độc với tính năng có thể che dấu sự tồn tại
      • Ẩn file, ẩn process, registry,..
      • Ngoài ra có thể dùng để theo dõi hoặc can thiệp vào các hoạt động khác
    • Usermode rootkit tác động riêng lẻ đối với từng tiến trình, kernel mode rootkit sử dụng driver để thực hiện việc che dấu trên toàn hệ thống
      • Với các bản windows mới, việc cài và thực thi drive khó khăn hơn
    • Trong process, api hooking là cơ chế cho phép chặn và sửa đổi các thông tin trong quá trình truyền dữ liệu cho api thực thi và nhận kết quả trả về từ api
• Quá trình process injection có 4 bước cơ bản
  • Tìm mục tiêu thích hợp để inject, có thể tạo mới hoặc inject vào các tiến trình có sẵn
  • Mở vào tạo vùng nhớ chứa code bên trong mục tiêu
  • Ghi mã cần inject vào vùng nhớ vừa tạo
  • Tạo thread để thực thi mã tại vùng nhớ vừa tạo
• Cách dễ nhận biết process injection là việc mã độc sử dụng tập các api sau để thực hiện các bước trên
  • CreateToolHelp32Snapshoot/EnumProcess: Lấy danh sách các tiến trình đang chạy để tìm mục tiêu thích hợp
  • OpenProcess: Api mở 1 handle của process mục tiêu, dùng handle để tác động tới process
  • VirutalAllocEx: tạo vùng nhớ mới bên trong tiến trình mục tiêu
  • CreateRemoteThread: Thực thi một thread mới bên trong tiến trình mục tiêu
  • Mã độc có thể sử dụng Native API thay thế các api trên
    • Native API bắt đầu bằng tiền tố Nt hoặc Zw, số ít có tiền tố Rtl
    • Native api được coi là lớp bên trong của các api
      • Các api thường sẽ gọi tới native api để thực hiện chức năng
      • Native api có chức năng rộng hơn api và thường liên quan trực tiếp đến hệ thống
    • Đa số native api được export bởi ntdll.dll
    • Lấy danh sách tiến trình: NtQuerySystemInfomation
    • Mở process: NtOpenProcess/ZwOpenProcess
    • Tạo vùng nhớ từ xa: NtAllocateVirtualMemory/ZwAllocateVirtualMemory
    • Ghi dữ liệu từ xa: NtWriteVirtualMemory/ZwWriteVirtualMemory
    • Tạo thread từ xa: NtCreateThreadEx/ZwCreateThreadEx/RtlCreateUserThread
• Để xác định process injection qua phân tích code, cần tìm vị trí reference gọi tới các api như CreateRemoteThread hoặc WriteProcessMemory và trace ngược lại để tìm các pattern còn lại
  • Sử dụng Symbol Reference trong Ghidra để tìm reference tới các api trong Symbol Table
• Đối với CreateRemoteThread, cần chú ý các tham số
  • hProcess: Handle dùng để tương tác với tiến trình mục tiêu, thường nhận được khi gọi OpenProcess
  • lpStartAddress: Địa chỉ để bắt đầu thực thi bên trong vùng nhớ của tiến trình mục tiêu
  • lpParameter: Tham số truyền vào cho thread
  • Ngoài ra createremotethread còn có các tham số như createionFlags, attribute,..
• Đối với writeprocessmemory, cần chú ý các tham số
  • hProcess: Handle dùng để tương tác với tiến trình mục tiêu
  • lpBuffer: vùng nhớ chứa dữ liệu sẽ ghi vào mục tiêu
  • lpBaseAddress: Vùng nhớ trong tiến trình mục tiêu sẽ được ghi
  • nSize: Số lượng dữ liệu muốn ghi vào vùng nhớ mục tiêu
• Nhiều khi các pattern api không được gọi liên tục mà có thể nằm bên trong các hàm con
  • Có thể sử dụng Function Call Tree để xem các hàm được gọi theo dạng tree và xác định các pattern về process injection
  • Function call tree của 1 hàm sẽ liệt kê các hàm gọi tới hàm này và các hàm mà hàm này gọi đi
    • Incoming Calls là các hàm gọi tới hàm được phân tích
    • OutGoing Calls là các hàm gọi đi
  • Function call graph có thể xem call tree ở dạng biểu đồ
• Với VirtualAllocEx, cần chú ý các tham số
  • flProctect: thuộc tính của vùng nhớ sẽ được tạo
    • Khi inject các vùng nhớ này thường có thuộc tính PAGE_EXECUTE_READWRITE (RWE-0x40) hoặc WRITE (W) EXECUTE (E)
• Flow thường gặp khi inject
  • CreateToolhel32Snapshot, Process32FirstW, [hàm/code để lọc ra process mục tiêu], Process32NextW
  • OpenProcess, VirtualAllocEx (có thể gặp VirtualProtectEx)
  • WriteProcessMemory
  • CreateRemoteThread
• Dll inject là 1 trong nhiều biến thể của process inject
  • Khi WriteProcessMemory, mã độc sẽ ghi string tên dll vào vùng nhớ mục tiêu
  • Khi CreateRemoteThread, mã độc sẽ gọi tới api LoadLibrary và chỉ định tham số là địa chỉ chứa string đã được ghi trên mục tiêu
    • Mã độc có thể sử dụng GetModuleHandle để lấy địa chỉ kernel32 và GetProcAddress để lấy địa chỉ của LoadLibrary làm tham số cho CreateRemoteThread
  • Khi thành công, LoadLibrary sẽ thực thi bên trong tiến trình mục tiêu và load dll được chỉ định
    • Mã độc có thể chỉnh sửa cấu trúc về danh sách load dll bên trong mục tiêu để ẩn thông tin về dll inject được load
      • DLL unlinking PEB

Api hooking

• Khi mục tiêu của injection là các tiến trình bình thường, có thể mã độc sẽ sử dụng api hooking để có chức năng của 1 rootkit user-mode
  • Mã độc có thể inject code và hook vào các api để thay đổi chức năng hoặc theo dõi hành vi của các tiến trình
  • Để hook api, cơ chế bao gồm các bước
    • Tìm và xác định api muốn hook
    • Tìm cách thay đổi luồng thực thi khi bắt đầu api để thực thi bản hook (api_hooked) của api đó
    • Sau khi thực thi bản hook và xử lí các tham số truyền vào, tiếp tục hoặc bỏ qua hàm api ban đầu và chỉnh sửa output của api nếu cần
  • Có nhiều cách để hook
    • inline hook: thay đổi lệnh đầu tiên của api bằng lệnh jump, call tới địa chỉ của api_hooked
    • call table hook: chỉnh sửa các bản chứa địa chỉ api thành địa chỉ của api_hooked
      • IRP (IO Request Packet), IDT (Interupt Descriptor Table), SSDT (System Service Descriptor Table) hook: Các hook ở kernel mode tác động vào các bảng chứa hàm xử lí của hệ thống
      • import/export table hook: Thay đổi bảng IAT, EAT của process
      • vftable hook: thay đổi bảng vftable của các đối tượng trong c++
    • Sử dụng exeption hook
    • Sử dụng các GUI hook như SwtWindowsHookEx API
• Khi thực hiện api thông thường
  • Tiến trình ở usermode gọi tới api
  • api gọi tới native api
  • native api gọi tới kernel mode nhận kết quả thưc thi
  • native api xử lí kết quả nhận được từ kernel mode và trả kết quả cho api
• Dữ liệu ở api call hoặc native api call được thực thi ở usermode
  • Mã độc có thể nhắm vào api call hoặc native api để hook
• Khi hook, quá trình sẽ bị thay đổi
  • Tiến trình ở usermode gọi tới api
  • Lúc này, API bị hook sẽ thực thi code của rootkit
  • code rootkit thực thi xong sẽ gọi tới code của api ban đầu
  • code api ban đầu thực thi xong các bước thông thường sẽ trả kết quả về cho code của rootkit
  • code rootkit xử lí kết quả và trả về cho api được gọi
• Khi thực hiện inline hook, mã độc cần thực thi các api
  • ReadProcessMemory: Đọc phần đầu tiên của code api để backup và sử dụng lại sau nếu cần
    • Các phần code này có thể được thực thi sau khi đoạn hooked được thực thi, phần còn lại của api (gọi là trampoline) sẽ được thi tiếp để api có thể hoạt động
  • VirtualProtectEx: Chỉnh sửa thuộc tính vùng nhớ chứa code api của tiến trình mục tiêu, thường sẽ cấp quyền ghi
    • Mặc định các code của api thường được gán thuộc tính RE, không Write nên mã độc cần chỉnh sửa trước khi hook
  • WriteProcessMemory: Ghi đè phần đầu của api bằng lệnh jump, call hoặc push+ret tới hooked code
    • lệnh jump có giá trị byte là 0xe9 + địa chỉ hooked
    • lệnh push+ret có giá trị byte là 0x68 + địa chỉ hooked + 0xc3
• Flow để thực hiện hook
  • VirtualProtectEx để thêm quyền write vào địa chỉ api nếu cần thiết
  • ReadProcessMemroy -> Check các byte đầu tiên (0xe9, 0x68,..) để kiểm tra api đã được hook chưa
  • Nếu chưa được hook -> ReadProcessMemory để lưu lại 1 phần code api
  • WriteProcessMemory để ghi lệnh jump hoặc push+ret vào địa chỉ api cần hook

Process Hollowing

• Thay vì chỉ thực hiện inject shellcode vào tiến trình khác, mã độc có thể thay thế toàn bộ tiến trình bằng nội dung của một file PE (bao gồm header, các section hoản chỉnh)
  • Kỹ thuật này được gọi là Process Hollowing/RunPE/process replacement
• Để thực hiện Process Hollowing
  • Mã độc cần tạo một tiến trình mới với cờ thuộc tính Suspend
    • Sử dụng CreateProcessA và tham số dwCreationFlags = 4 (CREATE_SUSPENDED)
  • NtUnmapViewOfSection: api được dùng để xóa toàn bộ dữ liệu file pe gốc đã được nạp lên vùng nhớ của tiến trình
  • VirtualAllocEx: Tạo vùng nhớ mới
  • WriteProcessMemory: Ghi vào vùng nhớ đã tạo theo cấu trúc PE file muốn inject
    • Tham số lpBuffer khi mã độc thực hiện ghi có thể sẽ trỏ tới PE file dùng để inject
    • Đặt breakpoint api và kiểm tra buffer được ghi với các dấu hiệu của PE file
      • Xác định các tham số truyền vào cho WriteProcessMemory qua stack
      • Khi xác định được địa chỉ buffer, có thể thực hiện Follow in Dump, Follow in MemoryMap và dump
  • GetThreadContext/SetThreadContext: Chỉnh sửa nội dung (eip sẽ trỏ tới entrypoint của file PE mới được inject) của thread sẽ được chạy trong tiến trình
  • ResumeThread: Khôi phục luông thực thi của thread đã chỉnh sửa, tiến trình tiếp tục thực thi nội dung file PE đã inject

Tổng kết

• Mã độc có thể sử dụng pack để khó phân tích hơn hoặc tốn nhiều thời gian hơn
  • Phân tích động sẽ dễ unpack hơn
  • Sử dụng debugger để dump có thể tốn thời gian
  • Khi không thể dump file hoàn chỉnh, có thể xác định các vùng chứa unpack code và debug
• Mã độc có thể dùng nhiều kỹ thuật để đạt được mục đích
  • Cần dùng nhiều kỹ thuật và công cụ khi phân tích để tìm ra mục đích của mã độc
• Mã độc dùng process injection để tránh bị phát hiện hoặc tạo ra usermode rootkit
  • Xác định mã độc có khả năng inject qua việc sử dụng các api của