CHFI v11 Hướng Dẫn Thực Hành Mô-đun 10: Điều tra các cuộc tấn công web

by ITPRO | 31/12/2024 | Lượt xem: 25

Mô-đun 10: Điều tra các cuộc tấn công web

Kịch bản thực hành:

Các nhà điều tra pháp y cần điều tra các cuộc tấn công web trên máy chủ web để xác định loại tấn công web và mức độ nghiêm trọng của nó. Là một phần của cuộc điều tra này, các nhà điều tra phải phân tích các tệp nhật ký máy chủ web, IDS, và các công cụ SIEM, trong đó chứa địa chỉ IP, trình duyệt và thông tin hệ thống của kẻ tấn công. Một ví dụ về một cuộc tấn công web quy mô lớn, nghiêm trọng sẽ là một kịch bản trong đó trang web của một tổ chức ngân hàng nổi tiếng bị đánh sập bởi những kẻ tấn công và toàn bộ dữ liệu trên đó, bao gồm thông tin chi tiết của chủ tài khoản, thông tin chi tiết của chủ lao động và nhân viên, v.v., bị rò rỉ trực tuyến trên web đen. Để điều tra cuộc tấn công web này, các nhà điều tra sẽ cần phân tích nhật ký IDS, nhật ký máy chủ web, và cảnh báo SIEM. Bằng cách phân tích các chi tiết này, họ có thể xác định các loại tấn công web đã được những kẻ tấn công cố gắng thực hiện. Chúng có thể bao gồm kịch bản chéo trang, tiêm SQL, tấn công brute-force, và các cuộc tấn công khác.

Là một nhà điều tra pháp y chuyên nghiệp, bạn nên biết cách điều tra các cuộc tấn công liên quan đến web.

Mục tiêu thực hành:

Mục tiêu của bài thực hành này là giúp sinh viên hiểu cách điều tra các loại tấn công web khác nhau, bao gồm:

Phát hiện và phân tích cuộc tấn công XSS bằng cách kiểm tra nhật ký Apache, nhật ký ModSecurity và nhật ký IIS.
Phát hiện và phân tích cuộc tấn công tiêm SQL bằng cách kiểm tra nhật ký Apache.
Phát hiện và phân tích cuộc tấn công duyệt thư mục bằng cách kiểm tra nhật ký Apache, nhật ký ModSecurity, và nhật ký IIS.
Phát hiện và phân tích cuộc tấn công tiêm lệnh bằng cách kiểm tra nhật ký Apache.
Phát hiện và phân tích cuộc tấn công XXE bằng cách kiểm tra nhật ký Apache.
Phát hiện và phân tích cuộc tấn công brute-force bằng cách kiểm tra nhật ký Apache và nhật ký IIS.

Tổng quan về việc điều tra các cuộc tấn công web:

Các cuộc tấn công web có nhiều loại khác nhau. Một cuộc tấn công từ chối dịch vụ (DoS) có thể được coi là một ví dụ về cuộc tấn công web. Trong các cuộc tấn công DoS, khách truy cập một trang web bị từ chối truy cập vào bất kỳ thông tin hoặc dịch vụ nào có sẵn trên trang web. Trong những trường hợp như vậy, khách truy cập có thể báo cáo việc không thể truy cập các dịch vụ trực tuyến mà họ đang cố gắng truy cập. Những kẻ tấn công cũng có thể sử dụng các kỹ thuật khác, chẳng hạn như tiêm SQL, tiêm lệnh, tấn công brute-force, v.v. để khai thác bất kỳ trang web dễ bị tấn công nào.

Một dấu hiệu của một cuộc tấn công web có thể là việc chuyển hướng người dùng đến một trang web không xác định. Hiệu suất mạng chậm bất thường và việc máy chủ khởi động lại thường xuyên cũng có thể cho thấy một cuộc tấn công web. Trong trường hợp nghi ngờ một cuộc tấn công web, các nhà điều tra cần kiểm tra dữ liệu nhật ký từ các nguồn khác nhau để hiểu nơi cuộc tấn công bắt nguồn và giảm thiểu nó sớm nhất có thể.

Nhiệm vụ thực hành:

Bài thực hành được đề xuất để hỗ trợ bạn trong việc điều tra các cuộc tấn công web:

Xác định và điều tra các cuộc tấn công ứng dụng web bằng Splunk
Xác định và điều tra các cuộc tấn công ứng dụng web bằng Python

Bài thực hành 1: Xác định và điều tra các cuộc tấn công ứng dụng web bằng Splunk

Kịch bản thực hành:

Một công ty thương mại điện tử đã bị tấn công mạng vào ứng dụng web của mình, nơi liệt kê và bán nhiều loại hàng hóa/sản phẩm. Những kẻ tấn công không chỉ đánh sập trang web mà còn đánh cắp thông tin nhận dạng cá nhân của người dùng/khách hàng của nó. Công ty đã tìm kiếm dịch vụ của bộ phận pháp y mạng của sở cảnh sát tiểu bang để giải quyết vụ án, lấy lại thông tin cụ thể của khách hàng bị đánh cắp, bảo mật hệ thống của mình và tất cả thông tin liên quan đến khách hàng, và do đó giúp khôi phục niềm tin của khách hàng vào doanh nghiệp của họ.

Để điều tra vụ án và xác định các loại tấn công web đã được những kẻ tấn công thực hiện trên ứng dụng web của công ty, Robert, nhà điều tra pháp y, bây giờ cần kiểm tra và phân tích các tệp nhật ký từ máy chủ Apache, máy chủ IIS, và tường lửa ứng dụng web ModSecurity bằng công cụ SIEM.

Mục tiêu thực hành:

Các tệp nhật ký ghi lại các sự kiện và hoạt động diễn ra trong hệ điều hành hoặc trong thời gian chạy của phần mềm hoặc dịch vụ máy tính. Việc kiểm tra pháp y các tệp nhật ký này giúp nhà điều tra xác định các hoạt động độc hại diễn ra trên máy chủ web.

Mục tiêu của bài thực hành này là giúp bạn hiểu cách kiểm tra các tệp nhật ký và tìm kiếm các hiện vật liên quan đến các cuộc tấn công ứng dụng web bằng công cụ SIEM.

Tổng quan về bài thực hành:

Bài thực hành này giúp bạn làm quen với quá trình kiểm tra các tệp nhật ký được tạo bởi máy chủ và tường lửa ứng dụng web để kiểm tra các chỉ báo về các cuộc tấn công web bằng các công cụ SIEM như Splunk Enterprise.

Trong bài thực hành này, chúng tôi sẽ kiểm tra các nhật ký được tạo bởi máy chủ Apache và IIS cũng như các nhật ký được tạo bởi tường lửa ứng dụng web ModSecurity. Nhật ký Apache và ModSecurity được kiểm tra trong bài thực hành này đã được tạo ra trên máy Ubuntu, trong khi nhật ký IIS được tạo ra trên máy ảo Windows Server 2022. Trong suốt bài thực hành này, bạn sẽ gặp phải các trường hợp bạn cần áp dụng các bộ lọc văn bản thuần túy và mã hóa để tìm nạp các mục nhật ký cụ thể liên quan đến các cuộc tấn công web khác nhau. Trong trường hợp ứng dụng Splunk Enterprise không hiển thị cho bạn các đề xuất thông qua danh sách thả xuống cho các bộ lọc mà bạn đang nhập vào trường New Search của nó, bạn sẽ phải nhập thủ công chúng và sau đó nhấp vào biểu tượng Search. Số lượng mục nhật ký thu được khi tải lên tệp bằng chứng hoặc áp dụng bộ lọc trong Splunk Enterprise có thể khác nhau trong môi trường thực hành của bạn.

Nhiệm vụ thực hành:

Theo mặc định, máy ảo Windows Server 2022 được chọn. Nhấp Ctrl+Alt+Delete.
Theo mặc định, hồ sơ người dùng Administrator được chọn, nhấp Pa w0rd để dán mật khẩu vào trường Password và nhấn Enter để đăng nhập.
Nếu ngăn Networks xuất hiện, nhấp Yes để cho phép PC của bạn được phát hiện bởi các PC và thiết bị khác trên mạng này.
Điều hướng đến E:\CHF\Tools… và nhấp đúp vào splunk-9.1.2-b6b9c8185839-x64-release.msi.
Cửa sổ Splunk Enterprise Installer sẽ xuất hiện. Đảm bảo bạn chọn Check this box to accept the License Agreement và nhấp Next để tiếp tục.
Cửa sổ Splunk Enterprise Setup bây giờ sẽ xuất hiện, yêu cầu bạn tạo thông tin đăng nhập cho tài khoản quản trị viên. Nhập Username, Password (Password có thể là bất kỳ thứ gì nhưng phải chứa ít nhất 8 ký tự ASCII có thể in được) và sau đó xác nhận lại mật khẩu như được hiển thị trong ảnh chụp màn hình. Ở đây, chúng tôi đã nhập Username là Investigator. Nhấp Next sau khi tạo thông tin đăng nhập.
Splunk Enterprise Setup bây giờ sẽ đưa bạn đến bước cài đặt tiếp theo. Đảm bảo chọn Create Start Menu Shortcut và sau đó nhấp Install.
Cài đặt sẽ mất một thời gian để hoàn thành. Bạn sẽ được thông báo bởi công cụ khi cài đặt hoàn tất. Ở bước cuối cùng của quá trình thiết lập, đảm bảo tích vào tùy chọn Launch browser with Splunk Enterprise. Nhấp Finish để thoát khỏi trình hướng dẫn thiết lập.
Nếu cửa sổ How do you want to open this? xuất hiện, hỏi bạn về trình duyệt nào bạn muốn sử dụng để khởi chạy và duyệt Splunk, thì hãy đảm bảo bạn chọn Google Chrome và sau đó nhấp OK, như được chỉ ra trong ảnh chụp màn hình sau:
Splunk Enterprise bây giờ sẽ được khởi chạy thông qua Google Chrome. Sau khi khởi chạy ứng dụng thông qua trình duyệt, bạn sẽ thấy 127.0.0.1:8000 trong thanh địa chỉ của nó.
Ở đây, chúng tôi sẽ sử dụng địa chỉ IP của máy ảo Windows Server 2022 để duyệt Splunk Enterprise. Do đó, hãy nhập 10.10.1.22:8000 vào thanh địa chỉ của trình duyệt và sau đó nhấn Enter.
Trong trang web kết quả, hãy nhập thông tin đăng nhập Sign In mà bạn đã tạo cho tài khoản Splunk Enterprise trong quá trình thiết lập và sau đó nhấp vào Sign In.
Hoạt động trên sẽ đăng nhập bạn vào tài khoản Splunk Enterprise của bạn.
Các bước tiếp theo từ đây sẽ minh họa việc thực hiện các nhiệm vụ thực hành của chúng ta sau khi đăng nhập vào tài khoản Splunk Enterprise.
Bây giờ bạn sẽ thấy trang chủ của Splunk Enterprise, nơi bạn sẽ tìm thấy tùy chọn Add Data, như trong ảnh chụp màn hình. Nhấp vào Add Data.
Nếu cửa sổ Welcome, Administrator xuất hiện, nhấp Skip.
Bây giờ, cuộn xuống trang chủ để tìm và nhấp vào tùy chọn Upload files from my computer.
Nếu cửa sổ Helping You to Get More Value from Splunk Software xuất hiện, như trong ảnh chụp màn hình bên dưới. Nhấp Got it! để tiếp tục.
Phần Select Source bây giờ sẽ xuất hiện. Nhấp vào Select File, như trong ảnh chụp màn hình bên dưới:
Khi cửa sổ Open xuất hiện, hãy điều hướng đến E:\CHF\Tools\Evidence Files\Log Files\Apache Logs và chọn tệp XSS. Nhấp Open để tải tệp lên.
Tệp XSS bây giờ sẽ được tải lên thành công. Nhấp vào Next để tiếp tục.
Ở bước tiếp theo, bạn sẽ thấy phần Set Source Type. Nhấp vào Save As, như được hiển thị trong ảnh chụp màn hình sau:
Cửa sổ Save Source Type bây giờ sẽ xuất hiện. Nhập XSS (Apache Logs) vào trường Name. Sau đó nhấp Save để tiếp tục.
Bạn sẽ quay lại phần Set Source Type. Nhấp Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Input Settings. Nhấp Review để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Review. Đảm bảo các chi tiết trong phần Review là chính xác và sau đó nhấp Submit để tiếp tục. Nếu cần, hãy áp dụng chỉnh sửa cho các chi tiết bằng cách xem lại các phần trước bằng cách nhấp Back, sau đó quay lại phần Review và nhấp Submit để tiếp tục.
Sau khi nhấp Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, nhấp vào Start Searching để kiểm tra tệp nhật ký. Nếu cửa sổ bật lên xuất hiện, hãy nhấp vào Skip tour.
Nếu bạn thấy cửa sổ Welcome, Administrator, hãy nhấp Skip.
Bạn bây giờ sẽ thấy các mục nhật ký từ tệp đã tải lên được hiển thị trong cửa sổ Splunk Enterprise trong tab Events, như được hiển thị trong ảnh chụp màn hình bên dưới. Nhiệm vụ của chúng ta bây giờ là kiểm tra tệp nhật ký để tìm dấu hiệu của cuộc tấn công XSS.
Để kiểm tra tệp nhật ký để tìm dấu hiệu của cuộc tấn công XSS, trước tiên chúng tôi sẽ áp dụng bộ lọc
Bây giờ, chúng tôi sẽ áp dụng một dạng mã hóa của bộ lọc
In case you do not see the search term suggestion %3c%2fscript%3e%3cbr in the drop-down
appearing below the New Search box, manually type the entire filter
(i.e., %3c%2fscript%3e%3cbr) in the New Search box and then click on the Search icon.
Chúng ta bây giờ có thể thấy một vài mục nhật ký được hiển thị dưới dạng kết quả trong tab Events, như được hiển thị trong ảnh chụp màn hình bên dưới.

Vì mục đích trình diễn, chúng tôi đã sử dụng tệp nhật ký chỉ chứa các mục dành riêng cho các cuộc tấn công web đã được ghi lại. Trong các kịch bản thời gian thực, tuy nhiên, bạn có thể thấy một vài mục nhật ký sau khi áp dụng bộ lọc và bạn có thể phải cuộn xuống cửa sổ để tìm kiếm thủ công mục nhật ký chứa các chỉ báo của cuộc tấn công XSS.

Khi chúng tôi kiểm tra kết quả đầu tiên được trả về sau khi áp dụng bộ lọc mã hóa, chúng tôi có thể thấy sự hiện diện của một tập lệnh được mã hóa trong chuỗi truy vấn. Tập lệnh được mã hóa được tô sáng trong ảnh chụp màn hình bên dưới.
Tập lệnh được mã hóa có nội dung %3CSCRIPT%3Evar+x+%3D+String(%2FXSS%2F)%3Bx+%3D+x.substring(1%2C+x.length-1)%3Balert(x)%3C%2FSCRIPT%3E. Để xác định xem tập lệnh mã hóa có độc hại hay không, chúng ta có thể giải mã nó bằng cách tham khảo bảng được cung cấp bên dưới:

Giá trị được mã hóa	Ký tự được giải mã
%3C
%20	khoảng trắng
%22	“
%3A	:
%3E	>
%2F	/
%26	&
%3B	;
%3D	=
%2C	,
%27	‘
%2D	–

Với sự trợ giúp của bảng trên, chúng ta có thể giải mã tập lệnh được mã hóa ở trên là (+ sẽ được chuyển đổi thành Dấu cách trong khi giải mã JavaScript được mã hóa). Bằng cách kiểm tra JavaScript đã giải mã, chúng ta có thể suy ra rằng mục nhật ký đang được xem xét cho thấy một nỗ lực tấn công XSS trên trang web.
Dựa trên quan sát chi tiết về mục nhật ký, chúng ta có thể tóm tắt các phát hiện của mình như sau:A. Ngày và giờ của cuộc tấn công: 07 tháng 7 năm 2020 và 2:46:58 AMB. Địa chỉ IP của kẻ tấn công: 192.168.198.1C. Trang web mà kẻ tấn công nhắm mục tiêu: //wp-admin/options-general.php? (điều này cho thấy đây là một cuộc tấn công vào trang quản trị của một trang web WordPress)D. Tập lệnh độc hại được sử dụng trong chuỗi truy vấn: %3CSCRIPT%3Evar+x+%3D+String(%2FXSS%2F)%3Bx+%3D+x.substring(1%2C+x.length-1)%3Balert(x)%3C%2FSCRIPT%3EE. Mã trạng thái HTTP 302: Điều này cho thấy chuyển hướng URL. Điều này cho thấy kẻ tấn công đã có được quyền quản trị bằng cách sử dụng tập lệnh XSS độc hại.
Chúng ta bây giờ sẽ kiểm tra tệp nhật ký tấn công XSS được tạo bởi ModSecurity, một tường lửa ứng dụng web mã nguồn mở.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang web Splunk Enterprise.
Bạn sẽ được chuyển hướng đến trang chủ của Splunk Enterprise một lần nữa. Chúng ta bây giờ sẽ kiểm tra tệp nhật ký tấn công XSS từ Nhật ký ModSecurity. Để có thể tải lên bằng chứng này, hãy nhấp vào biểu tượng Add Data trên trang chủ và sau đó làm theo các bước để tải lên, như bạn đã làm khi tải lên tệp bằng chứng XSS trong trường hợp trước.
Khi cửa sổ Open xuất hiện, hãy điều hướng đến E:\CHF\Tools\Evidence Files\Log Files\ModSecurity Logs, chọn XSS và nhấp Open để tải tệp lên.
Tệp XSS bây giờ sẽ được tải lên thành công. Nhấp vào Next để tiếp tục.
Ở bước tiếp theo, bạn sẽ thấy phần Set Source Type. Nhấp vào nút Save As.
Cửa sổ Save Source Type bây giờ sẽ xuất hiện. Trong trường Name, nhập XSS (ModSecurity Logs). Nhấp Save để tiếp tục.
Bạn bây giờ sẽ quay lại phần Set Source Type một lần nữa. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Input Settings. Nhấp Review để tiếp tục.
Trong bước tiếp theo, phần Review sẽ xuất hiện. Đảm bảo chi tiết trong phần Review là chính xác, sau đó nhấp Submit để tiếp tục.
Sau khi nhấp vào Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, hãy nhấp Start Searching để lấy các mục nhật ký từ tệp nhật ký.
Tất cả các mục từ tệp nhật ký bây giờ sẽ hiển thị trong Splunk Enterprise trong tab Events.
Để kiểm tra tệp nhật ký để tìm cuộc tấn công XSS, trước tiên chúng tôi sẽ áp dụng bộ lọc văn bản thuần
Bây giờ, chúng tôi sẽ áp dụng một hình thức mã hóa của bộ lọc
Sau khi áp dụng bộ lọc được mã hóa, chúng tôi quan sát thấy rằng một vài mục nhật ký được hiển thị dưới dạng kết quả trong tab Events.
Vì mục đích trình diễn, chúng tôi đã sử dụng tệp nhật ký chỉ chứa các mục cụ thể cho các cuộc tấn công web đã ghi. Trong các kịch bản thời gian thực, tuy nhiên, bạn có thể thấy một vài mục nhật ký khi áp dụng bộ lọc và bạn có thể phải cuộn xuống cửa sổ để tìm kiếm thủ công mục nhật ký chứa các chỉ số của cuộc tấn công XSS.
Sau khi kiểm tra kết quả, chúng tôi nhận thấy sự hiện diện của một tập lệnh mã hóa trong chuỗi truy vấn. Tập lệnh
đọc %3CSCRIPT%3Evar+x+%3D+String(%2FXSS%2F)%3Bx+%3D+x.substring(1%2C+x.length-1)%3Balert(x)%3C%2FSCRIPT%3E.
Khi chúng tôi giải mã tập lệnh độc hại đã mã hóa này với sự trợ giúp của bảng giải mã được cung cấp trong các bước để điều tra tệp nhật ký XSS từ Apache Logs, chúng tôi tương tự như vậy thấy sự hiện diện của các thẻ HTML sau trong JavaScript:

. Khi quan sát thấy sự hiện diện của các thẻ HTML được mã hóa, chúng ta có thể suy ra rằng tập lệnh này có hại và đã được sử dụng cho cuộc tấn công XSS.

Một quan sát chi tiết về nội dung trong mục nhật ký cung cấp cho chúng tôi các phát hiện sau đây:A. Ngày và giờ của cuộc tấn công: 07 tháng 7 năm 2020 và 05:37:55 AMB. Địa chỉ IP của kẻ tấn công: 192.168.198.1C. Trang web mà kẻ tấn công đã nhắm mục tiêu bằng yêu cầu GET: /wp-admin/options-general.php?pa (điều này cho thấy đó là một cuộc tấn công vào trang web của một trang WordPress)D. Tập lệnh độc hại được sử dụng trong chuỗi truy vấn: %3CSCRIPT%3Evar+x+%3D+String(%2FXSS%2F)%3Bx+%3D+x.substring(1%2C+x.length-1)%3Balert(x)%3C%2FSCRIPT%3E%3CBR+E. Địa chỉ IP của Host: 192.168.198.140F. Thông báo HTTP 403 Forbidden: Điều này cho thấy rằng quyền truy cập vào tài nguyên được yêu cầu đã bị chặn bởi tường lửa ModSecurity.G. Thông báo được máy chủ tạo để phản hồi lại yêu cầu GET của kẻ tấn công: You don’t have permission to access this resource.
Chúng ta bây giờ sẽ kiểm tra tệp nhật ký tấn công XSS được tạo bởi máy chủ IIS.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang web Splunk Enterprise.
Bạn sẽ được chuyển hướng đến trang chủ của Splunk Enterprise một lần nữa. Chúng ta bây giờ sẽ kiểm tra tệp nhật ký tấn công XSS từ IIS Logs. Để có thể tải lên bằng chứng này, nhấp vào biểu tượng Add Data trên trang chủ và sau đó làm theo các bước để tải nó lên, như bạn đã làm khi tải lên tệp bằng chứng XSS trong trường hợp trước đó.
Khi cửa sổ Open xuất hiện, hãy điều hướng đến E:\CHFI-Tools\Evidence Files\Log Files\IIS Logs và chọn XSS.txt. Nhấp Open để tải tệp lên.
Tệp XSS.txt bây giờ sẽ được tải lên thành công. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Set Source Type. Nhấp vào nút Save As.
Cửa sổ Save Source Type bây giờ sẽ xuất hiện. Trong trường Name, nhập XSS.txt (IIS Logs). Sau đó, nhấp vào Save để tiếp tục.
Bạn sẽ quay lại phần Set Source Type một lần nữa. Nhấp vào Next ở trên cùng bên phải của trang để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Input Settings. Nhấp vào Review ở trên cùng bên phải của trang để tiếp tục.
Trong bước tiếp theo, phần Review sẽ xuất hiện. Đảm bảo chi tiết trong phần Review là chính xác và sau đó nhấp vào Submit để tiếp tục.
Sau khi nhấp vào Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, hãy nhấp vào Start Searching để lấy tất cả các mục nhật ký từ tệp nhật ký.
Tệp nhật ký đã tải lên bây giờ sẽ được mở trong Splunk Enterprise và các mục của nó sẽ được hiển thị trong tab Events, như được hiển thị trong ảnh chụp màn hình bên dưới:
Để kiểm tra tệp nhật ký để tìm các cuộc tấn công XSS, trước tiên chúng tôi sẽ áp dụng bộ lọc văn bản thuần
Bây giờ, chúng tôi sẽ áp dụng một hình thức mã hóa của bộ lọc
Sau khi áp dụng bộ lọc được mã hóa, ứng dụng hiển thị một vài mục nhật ký làm kết quả. Chúng ta cần kiểm tra các kết quả này để tìm dấu hiệu của cuộc tấn công XSS.
Đối với mục đích trình diễn, chúng tôi đã sử dụng tệp nhật ký chứa các mục cụ thể chỉ cho các cuộc tấn công web đã ghi lại. Trong các kịch bản thời gian thực, tuy nhiên, bạn có thể thấy một vài mục nhật ký khi áp dụng bộ lọc và bạn có thể phải cuộn xuống cửa sổ để tìm kiếm thủ công mục nhật ký chứa các chỉ báo của một cuộc tấn công XSS.
Khi kiểm tra mục nhật ký ở trên cùng, chúng ta có thể thấy rằng chuỗi truy vấn của nó chứa một tập lệnh được mã hóa độc hại. Tập lệnh được mã hóa độc hại có nội dung
%3CSCRIPT%3Evar+x+%3D+String(%2FXSS%2F)%3Bx+%3D+x.substring(1%2C+x.length-1)%3Balert(x)%3C%2FSCRIPT%3E. Dựa trên các quan sát trước đây của chúng tôi, đây là cùng một tập lệnh độc hại mà chúng tôi đã tìm thấy khi điều tra các tệp nhật ký XSS từ máy chủ Apache và tường lửa ModSecurity.
Một quan sát chi tiết về mục nhật ký cung cấp cho chúng tôi các phát hiện sau đây:A. Ngày và giờ của cuộc tấn công: Ngày 08 tháng 7 năm 2020 và 1:37:26 chiềuB. Địa chỉ IP của kẻ tấn công: 192.168.198.1C. Trang web bị nhắm mục tiêu trong cuộc tấn công: http://192.168.198.142/forensics/wp-admin/options-general.php? (điều này cho thấy đó là một cuộc tấn công vào trang web của WordPress)D. Tập lệnh độc hại được sử dụng trong cuộc tấn công: %3CSCRIPT%3Evar+x+%3D+String(%2FXSS%2F)%3Bx+%3D+x.substring(1%2C+x.length-1)%3Balert(x)%3C%2FSCRIPT%3EE. Mã trạng thái HTTP 200: Điều này có nghĩa là yêu cầu được thực hiện tới máy chủ đã được nhận và đang được xử lý
Bây giờ chúng ta sẽ phát hiện và phân tích các cuộc tấn công tiêm SQL bằng cách kiểm tra các tệp nhật ký.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang web.
Bạn bây giờ sẽ được đưa đến trang chủ của Splunk Enterprise. Bây giờ chúng ta cần tải lên tệp nhật ký tiêm SQL. Để có thể tải lên tệp bằng chứng, hãy nhấp vào biểu tượng Add Data trên trang chủ và sau đó làm theo các bước để tải tệp lên.
Trong cửa sổ Open xuất hiện, hãy điều hướng đến E:\CHFI-Tools\Evidence Files\Log Files\Apache Logs, chọn SQL Injection.log, và nhấp vào Open để tải tệp lên.
Tệp SQL Injection.log sẽ được tải lên thành công. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, phần Set Source Type sẽ xuất hiện. Nhấp vào nút Save As.
Cửa sổ Save Source Type bây giờ sẽ xuất hiện. Trong trường Name, hãy nhập SQL Injection.log (Apache Logs) là tên tệp nguồn, như được tô sáng trong ảnh chụp màn hình bên dưới. Sau khi nhập tên, chúng ta cần nhấp vào Save để tiếp tục.
Bây giờ bạn sẽ quay lại phần Set Source Type một lần nữa. Nhấp vào Next ở trên cùng bên phải của trang để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Input Settings. Nhấp Review ở trên cùng bên phải của trang để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Review. Đảm bảo chi tiết trong phần Review là chính xác và sau đó nhấp vào Submit để tiếp tục. Nếu cần, hãy áp dụng chỉnh sửa cho các chi tiết bằng cách xem lại các phần trước bằng cách nhấp Back, và sau đó quay lại phần Review và nhấp Submit để tiếp tục.
Bây giờ bạn sẽ thấy các mục từ tệp nhật ký được tải lên hiển thị trong Splunk Enterprise trong tab Events.
Để tìm kiếm cuộc tấn công tiêm SQL, trước tiên chúng tôi sẽ áp dụng bộ lọc văn bản thuần ‘ or 1=1–. Để áp dụng bộ lọc, hãy nhập ‘ or 1=1– vào ô New Search và sau đó nhấp vào biểu tượng Search, như được hiển thị trong ảnh chụp màn hình bên dưới. Khi áp dụng bộ lọc, tuy nhiên, chúng tôi thấy rằng không có kết quả nào được tạo ra.
Khi áp dụng bộ lọc được đề cập ở trên, bạn có thể xem các mục từ tệp nhật ký có nguồn gốc trước đó. Trong trường hợp như vậy, bạn cần chỉ định tệp nhật ký hiện tại cùng với bộ lọc tìm kiếm, ví dụ: ‘ hoặc 1=1– sourcetype = “SQL Injection.log (Apache Logs)”, để tìm nạp các kết quả liên quan.
Chúng ta bây giờ sẽ áp dụng biến thể được mã hóa của bộ lọc ‘or 1=1–. Để áp dụng biến thể được mã hóa của bộ lọc này, hãy nhập %27%20or%201%3D1%2D%2D vào ô New Search và sau đó nhấp vào biểu tượng Search. Chúng tôi thấy rằng không có kết quả nào thu được ngay cả sau khi áp dụng biến thể được mã hóa của bộ lọc ‘or 1=1–.
Khi áp dụng bộ lọc được đề cập ở trên, bạn có thể xem các mục từ tệp nhật ký có nguồn gốc trước đó. Trong trường hợp như vậy, bạn cần chỉ định tệp nhật ký hiện tại cùng với bộ lọc tìm kiếm, ví dụ: %27%20or%201%3D1%2D%2D sourcetype = “SQL Injection.log (Apache Logs)”, để tìm nạp các kết quả liên quan.
Chúng ta bây giờ sẽ áp dụng bộ lọc root’ union select. Chúng tôi thấy rằng không có kết quả nào được tạo ra khi áp dụng bộ lọc này.
Khi áp dụng bộ lọc được đề cập ở trên, bạn có thể xem các mục từ tệp nhật ký có nguồn gốc trước đó. Trong trường hợp như vậy, bạn cần chỉ định tệp nhật ký hiện tại cùng với bộ lọc tìm kiếm, ví dụ: root’ union select sourcetype = “SQL Injection.log (Apache Logs)”, để tìm nạp các kết quả liên quan.
Bây giờ, chúng tôi sẽ áp dụng một biến thể được mã hóa của bộ lọc root’ Union Select để tìm kiếm các dấu hiệu của cuộc tấn công tiêm SQL. Để áp dụng bộ lọc được mã hóa,
hãy nhập root%27%20%20union%20select vào ô New Search và sau đó nhấp vào biểu tượng Search.
Khi áp dụng bộ lọc được mã hóa ở trên, chúng tôi thấy một số kết quả được tạo.
Vì mục đích trình diễn, chúng tôi đã sử dụng tệp nhật ký chỉ chứa các mục cụ thể cho các cuộc tấn công web đã ghi. Trong các kịch bản thời gian thực, tuy nhiên, bạn có thể thấy một vài mục nhật ký khi áp dụng bộ lọc và bạn có thể phải cuộn xuống cửa sổ để tìm kiếm thủ công mục nhật ký chứa các dấu hiệu của cuộc tấn công tiêm SQL.
Sau khi kiểm tra mục nhật ký ở trên cùng, chúng tôi thấy rằng nó chứa một yêu cầu GET với truy vấn UniON SeLeCT. Hơn nữa, truy vấn UniON SeLeCT đang tham chiếu các tham số như 1,table_name,3,4,5 From Information_schema.tables where Table_Schema=DatabasE() limit 0,1– – v.v. Từ đây, chúng ta có thể suy ra rằng kẻ tấn công đã cố gắng truy cập chi tiết của các bảng hiện diện trong cơ sở dữ liệu và nội dung được lưu trữ trong đó bằng cách sử dụng truy vấn UniON SeLeCT, là một dấu hiệu của cuộc tấn công tiêm SQL.
Một quan sát chi tiết về mục nhật ký cung cấp cho chúng tôi các phát hiện sau đây:A. Ngày và giờ của cuộc tấn công: 24 tháng 6 năm 2020 và 09:00:25 AMB. Địa chỉ IP của kẻ tấn công: 10.0.0.19C. Phần độc hại của truy vấn được sử dụng để thực hiện cuộc tấn công: GET
/sqli/example1.php?name=root%27%20%20UniON%20SeLeCT%201,table_name,3,4,5%20
From%20Information_schema.tables%20where%20Table_Schema=DatabasE()%20limit%2
00,1–%20-D. Mã trạng thái HTTP 200: Điều này cho thấy rằng yêu cầu được thực hiện tới máy chủ đã được xử lý và cuộc tấn công đã thành công
Bây giờ chúng tôi sẽ kiểm tra cuộc tấn công duyệt thư mục trong các tệp nhật ký được tạo bởi máy chủ Apache.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang và tiếp tục theo hướng dẫn …

Bạn sẽ được chuyển hướng đến trang chủ của Splunk Enterprise. Bây giờ chúng ta cần tải lên tệp nhật ký Duyệt thư mục từ Nhật ký Apache. Để tải lên tệp bằng chứng, hãy nhấp vào biểu tượng Add Data trên trang chủ và sau đó làm theo các bước để tải lên.
Khi cửa sổ Open xuất hiện, hãy điều hướng đến E:\CHFI-Tools\Evidence Files\Log Files\Apache Logs, chọn Directory Traversal, và nhấp vào Open để tải tệp lên.
Tệp Directory Traversal sẽ được tải lên thành công. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, phần Set Source Type sẽ xuất hiện. Nhấp vào Save As.
Cửa sổ Save Source Type sẽ xuất hiện. Trong trường Name, hãy nhập Directory Traversal (Apache Logs) để gán tên cho tệp nguồn, sau đó nhấp vào Save để tiếp tục.
Bạn sẽ quay lại phần Set Source Type một lần nữa. Nhấp vào Next ở trên cùng bên phải của trang để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Input Settings. Nhấp vào Review để tiếp tục.
Trong bước tiếp theo, phần Review sẽ xuất hiện. Đảm bảo các chi tiết trong phần Review là chính xác và sau đó nhấp vào Submit để tiếp tục.
Sau khi nhấp vào Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, hãy nhấp vào Start Searching để lấy các mục nhật ký để kiểm tra tệp nhật ký Directory Traversal.
Bạn sẽ thấy các mục từ tệp nhật ký được tải lên được hiển thị trong Splunk Enterprise trong tab Events.
Để tìm các chỉ báo liên quan đến cuộc tấn công duyệt thư mục, trước tiên chúng tôi sẽ áp dụng bộ lọc văn bản thuần túy ../ bằng cách nhập nó vào ô New Search và sau đó nhấp vào biểu tượng Search. Mục đích của việc áp dụng bộ lọc này là sự hiện diện của chuỗi ../ (chấm chấm gạch chéo) trong một mục nhật ký sẽ giúp nhà điều tra xác định sự xuất hiện của một cuộc tấn công duyệt thư mục.
Khi áp dụng bộ lọc được đề cập ở trên, bạn có thể thấy các mục từ các tệp nhật ký có nguồn gốc trước đó. Trong trường hợp như vậy, bạn cần chỉ định tệp nhật ký hiện tại cùng với bộ lọc tìm kiếm, ví dụ: ../ sourcetype=”Directory Traversal (Apache Logs)”, để tìm nạp các kết quả liên quan.
Khi áp dụng bộ lọc, chúng tôi thấy rằng một vài mục nhật ký đã được truy xuất dưới dạng kết quả. Chúng ta cần kiểm tra các mục này để tìm dấu hiệu của một cuộc tấn công duyệt thư mục.
Vì mục đích trình diễn, chúng tôi đã sử dụng tệp nhật ký chỉ chứa các mục cụ thể cho các cuộc tấn công web đã ghi lại. Trong các kịch bản thời gian thực, tuy nhiên, bạn có thể thấy một vài mục nhật ký khi áp dụng bộ lọc và bạn có thể phải cuộn xuống cửa sổ để tìm kiếm thủ công mục nhật ký chứa các chỉ báo của một cuộc tấn công duyệt thư mục.
Khi kiểm tra mục nhật ký đầu tiên, chúng tôi nhận thấy rằng nó chứa một chuỗi chấm chấm gạch chéo (../../../) trong chuỗi truy vấn, khớp với bộ lọc mà chúng tôi đã áp dụng (../). Hơn nữa, chúng tôi cũng nhận thấy rằng một nỗ lực đã được thực hiện để tải xuống tệp wp-config.php bằng cách sử dụng chấm chấm gạch chéo (../../../), là một chỉ báo của cuộc tấn công duyệt thư mục. wp-config.php là tệp WordPress cốt lõi lưu trữ thông tin liên quan đến cơ sở dữ liệu WordPress như thông tin máy chủ, tên người dùng và mật khẩu.
Trong trường hợp bộ lọc văn bản thuần túy ../ không tìm nạp được bất kỳ mục nhật ký nào, bạn có thể áp dụng các biến thể được mã hóa khác nhau của bộ lọc ../ như %2E%2E%2F, %2E%2E/ hoặc ..%2F để tìm kiếm các nỗ lực tấn công duyệt thư mục.
Quan sát chi tiết về mục nhật ký cung cấp cho chúng tôi các phát hiện sau:
A. Ngày và giờ của cuộc tấn công: 07 tháng 7 năm 2020, 02:21:55 AM
B. Địa chỉ IP của kẻ tấn công: 192.168.198.1
C. Truy vấn độc hại được sử dụng trong cuộc tấn công Duyệt thư mục: GET /wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php
D. Mã trạng thái HTTP 200: Điều này có nghĩa là yêu cầu được thực hiện tới máy chủ đã được xử lý và cuộc tấn công đã thành công
Bây giờ chúng tôi sẽ kiểm tra tệp nhật ký Directory Traversal được tạo bởi tường lửa ứng dụng web ModSecurity.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang web.
Khi trang chủ của Splunk Enterprise mở ra, hãy nhấp vào biểu tượng Add data và sau đó làm theo các bước để tải lên tệp bằng chứng.
Cửa sổ Open sẽ xuất hiện. Điều hướng đến E:\CHFI-Tools\Evidence Files\Log Files\ModSecurity Logs và chọn Directory Traversal. Nhấp vào Open để tải tệp lên.
Tệp Directory Traversal sẽ được tải lên thành công. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Set Source Type. Nhấp vào nút Save As.
Cửa sổ Save Source Type sẽ xuất hiện. Trong trường Name, chúng tôi sẽ nhập Directory Traversal (ModSecurity Logs). Nhấp vào Save để tiếp tục.
Bạn sẽ thấy phần Set Source Type một lần nữa. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, phần Input Settings sẽ xuất hiện. Nhấp vào Review để tiếp tục.
Trong bước tiếp theo, phần Review sẽ xuất hiện. Đảm bảo các chi tiết trong phần Review là chính xác, sau đó nhấp vào Submit để tiếp tục.
Khi nhấp vào Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, hãy nhấp vào Start Searching để lấy các mục nhật ký từ tệp nhật ký Directory Traversal.
Bạn sẽ thấy các mục nhật ký từ tệp nhật ký được tải lên hiển thị trong Splunk Enterprise trong tab Events, như được hiển thị trong ảnh chụp màn hình bên dưới:
Như trong trường hợp trước, bây giờ chúng tôi sẽ áp dụng bộ lọc văn bản thuần túy ../ để kiểm tra các chỉ báo liên quan đến cuộc tấn công duyệt thư mục. Để áp dụng bộ lọc, hãy nhập ../ vào ô New Search và sau đó nhấp vào biểu tượng Search.
Khi áp dụng bộ lọc được đề cập ở trên, bạn có thể thấy các mục từ các tệp nhật ký có nguồn gốc trước đó. Trong trường hợp như vậy, bạn cần chỉ định tệp nhật ký hiện tại cùng với bộ lọc tìm kiếm, ví dụ: ../ sourcetype = “Directory Traversal (ModSecurity Logs)”, để tìm nạp các kết quả liên quan.
Khi áp dụng bộ lọc như được hiển thị ở trên, chúng ta thấy một vài mục nhật ký được hiển thị dưới dạng kết quả trong tab Events, như được hiển thị trong ảnh chụp màn hình bên dưới.
Đối với mục đích trình diễn, chúng tôi đã sử dụng tệp nhật ký chỉ chứa các mục cụ thể cho các cuộc tấn công web đã ghi lại. Trong các kịch bản thời gian thực, tuy nhiên, bạn có thể thấy một vài mục nhật ký khi áp dụng bộ lọc và bạn có thể phải cuộn xuống cửa sổ để tìm kiếm thủ công mục nhật ký chứa các chỉ báo của một cuộc tấn công Duyệt thư mục.
Như trong trường hợp trước, chúng ta cần tìm kiếm sự hiện diện của ../ (chấm chấm gạch chéo) trong chuỗi truy vấn để phát hiện cuộc tấn công duyệt thư mục. Khi kiểm tra mục nhật ký ở trên cùng một cách chi tiết, chúng tôi thấy rằng chuỗi truy vấn chứa một số chuỗi ../, như trong ảnh chụp màn hình bên dưới:
Trong trường hợp bộ lọc văn bản thuần túy ../ không tìm nạp được bất kỳ mục nhật ký nào, bạn có thể áp dụng các biến thể được mã hóa khác nhau của bộ lọc ../ như %2E%2E%2F, %2E%2E/ hoặc ..%2F để tìm kiếm các nỗ lực tấn công duyệt thư mục.
Một quan sát chi tiết về nội dung trong mục nhật ký cung cấp cho chúng tôi các phát hiện sau (bạn phải nhấp vào tùy chọn Show all 50 lines hiện diện bên dưới mục nhật ký để có thể xem các chi tiết được liệt kê bên dưới):
A. Ngày và giờ của cuộc tấn công: 07 tháng 7 năm 2020 và 06:03:22 AM
B. Địa chỉ IP của kẻ tấn công: 192.168.198.1
C. Truy vấn độc hại được sử dụng cho cuộc tấn công duyệt thư mục: GET /wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php (như trong trường hợp trước của cuộc tấn công duyệt thư mục được ghi lại bởi máy chủ Apache, tệp được nhắm mục tiêu trong trường hợp này cũng là wp-config.php)
D. Địa chỉ IP của Host: 192.168.198.140
E. Thông báo HTTP/1.1 403 Forbidden: Điều này có nghĩa là quyền truy cập vào tài nguyên được yêu cầu đã bị chặn bởi tường lửa ModSecurity
F. Thông báo được tạo bởi máy chủ để phản hồi lại yêu cầu GET của kẻ tấn công: You don’t have permission to access this resource.
Cuộn xuống cửa sổ ứng dụng để tìm các quan sát E và F, như được chỉ ra trong ảnh chụp màn hình bên dưới.
Bây giờ chúng ta sẽ kiểm tra tệp nhật ký Directory Traversal.txt được tạo bởi máy chủ IIS.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang web.
Bạn sẽ được chuyển hướng đến trang chủ của Splunk Enterprise. Nhấp vào biểu tượng Add Data trên trang chủ và sau đó làm theo các bước để tải nó lên.
Cửa sổ Open sẽ xuất hiện. Điều hướng đến E:\CHFI-Tools\Evidence Files\Log Files\IIS Logs và chọn Directory Traversal.txt. Nhấp Open để tải lên tệp.
Tệp Directory Traversal.txt sẽ được tải lên thành công. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Set Source Type. Nhấp vào Save As.
Cửa sổ Save Source Type bây giờ sẽ xuất hiện. Trong trường Name, chúng tôi sẽ nhập Directory Traversal.txt (IIS Logs). Nhấp vào Save để tiếp tục.
Bạn sẽ quay lại phần Set Source Type một lần nữa. Nhấp Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Input Settings. Nhấp vào Review để tiếp tục.
Trong bước tiếp theo, phần Review sẽ xuất hiện. Đảm bảo các chi tiết trong phần Review là chính xác và sau đó nhấp vào Submit để tiếp tục.
Khi nhấp vào Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, hãy nhấp vào Start Searching để lấy tất cả các mục nhật ký từ tệp nhật ký.
Các mục nhật ký từ tệp nhật ký Directory Traversal.txt bây giờ sẽ được hiển thị trong Splunk Enterprise trong tab Events.
Như trong hai trường hợp trước, chúng tôi sẽ áp dụng bộ lọc văn bản thuần túy ../ ở đây. Để áp dụng bộ lọc, hãy nhập ../ vào ô New Search và sau đó nhấp vào biểu tượng Search.
Khi áp dụng bộ lọc được đề cập ở trên, bạn có thể thấy các mục từ các tệp nhật ký có nguồn gốc trước đó. Trong trường hợp như vậy, bạn cần chỉ định tệp nhật ký hiện tại cùng với bộ lọc tìm kiếm, ví dụ: ../ sourcetype = “Directory Traversal.txt (IIS Logs)”, để tìm nạp các kết quả có liên quan.
Khi áp dụng bộ lọc như được hiển thị ở trên, chúng ta có thể thấy một vài mục nhật ký được hiển thị dưới dạng kết quả trong tab Events.
Đối với mục đích trình diễn, chúng tôi đã sử dụng tệp nhật ký chỉ chứa các mục cụ thể cho các cuộc tấn công web đã ghi lại. Trong các kịch bản thời gian thực, tuy nhiên, bạn có thể thấy một vài mục nhật ký khi áp dụng bộ lọc và bạn có thể phải cuộn xuống cửa sổ để tìm kiếm thủ công mục nhật ký chứa các chỉ báo của một cuộc tấn công Duyệt thư mục.
Như trong hai trường hợp trước đó, chúng ta cần tìm sự hiện diện của ../ (chấm chấm gạch chéo) hoặc biến thể được mã hóa của nó trong chuỗi truy vấn để phát hiện cuộc tấn công duyệt thư mục. Khi kiểm tra mục nhật ký ở trên cùng, chúng tôi thấy rằng chuỗi truy vấn chứa chuỗi ../, như trong ảnh chụp màn hình bên dưới.
Trong trường hợp bộ lọc văn bản thuần túy ../ không tìm nạp được bất kỳ mục nhật ký nào, bạn có thể áp dụng các biến thể được mã hóa khác nhau của bộ lọc ../ như %2E%2E%2F, %2E%2E/ hoặc ..%2F để tìm kiếm các nỗ lực tấn công duyệt thư mục.
Một quan sát chi tiết về mục nhật ký cung cấp cho chúng tôi các phát hiện sau:
A. Ngày và giờ của cuộc tấn công: 08 tháng 7 năm 2020 và 01:53:28 chiều
B. Địa chỉ IP của máy chủ: 192.168.198.142
C. Truy vấn độc hại được sử dụng trong cuộc tấn công duyệt thư mục: GET /forensics/wp-content/plugins/ebook-download/filedownload.php ebookdownloadurl=../../../wp-config.php (một lần nữa, tệp được nhắm mục tiêu bởi kẻ tấn công là wp-config.php)
D. Địa chỉ IP của kẻ tấn công: 192.168.198.1
E. Mã trạng thái HTTP 200: Điều này cho thấy rằng yêu cầu được thực hiện tới máy chủ đã được nhận và đang được xử lý
Bây giờ chúng ta sẽ kiểm tra tệp nhật ký tiêm lệnh được tạo bởi máy chủ Apache.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang.
Bạn sẽ được chuyển hướng đến trang chủ của Splunk Enterprise. Bây giờ chúng ta cần tải lên tệp Command Injection.log. Để có thể tải lên tệp bằng chứng, hãy nhấp vào biểu tượng Add data trên trang chủ và sau đó làm theo các bước để tải tệp lên.
Cửa sổ Open sẽ xuất hiện. Điều hướng đến E:\CHFI-Tools\Evidence Files\Log Files\Apache Logs và chọn Command Injection.log. Nhấp vào Open để tải tệp lên.
Tệp Command Injection.log sẽ được tải lên thành công. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, phần Set Source Type sẽ xuất hiện. Nhấp vào Save As.
Cửa sổ Save Source Type sẽ xuất hiện. Trong trường Name, chúng ta sẽ nhập Command Injection.log (Apache Logs). Nhấp vào Save để tiếp tục.
Bạn sẽ quay lại phần Set Source Type một lần nữa. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, phần Input Settings sẽ xuất hiện. Nhấp vào Review để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Review. Đảm bảo các chi tiết trong phần Review là chính xác và sau đó nhấp vào Submit để tiếp tục.
Sau khi nhấp vào Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, nhấp vào Start Searching để lấy các mục nhật ký từ tệp nhật ký.
Các mục nhật ký từ tệp Command Injection.log bây giờ sẽ được hiển thị trong cửa sổ Splunk Enterprise trong tab Events.
Bây giờ chúng tôi sẽ áp dụng các bộ lọc văn bản thuần túy |ifconfig và cat để tìm bất kỳ chỉ báo nào về cuộc tấn công tiêm lệnh. Tuy nhiên, chúng tôi thấy rằng không có kết quả nào được trả về sau khi áp dụng các bộ lọc này, như được hiển thị trong ảnh chụp màn hình bên dưới:

      Khi áp dụng bộ lọc được đề cập ở trên, bạn có thể thấy các mục từ các tệp nhật ký có nguồn gốc trước đó. Trong trường hợp như vậy, bạn cần chỉ định tệp nhật ký hiện tại cùng với bộ lọc tìm kiếm, ví dụ: ifconfig sourcetype="Command Injection.log (Apache Logs)" hoặc cat sourcetype="Command Injection.log (Apache Logs)", để tìm nạp các kết quả có liên quan.
Trong kịch bản trên, chúng tôi đã sử dụng toán tử Pipe (|) kết hợp với các lệnh cụ thể của Linux như một phương tiện để áp dụng bộ lọc trong nỗ lực xác định các chỉ số của cuộc tấn công tiêm lệnh, vì tệp nhật ký tiêm lệnh đã được tạo trên máy Linux. Trong trường hợp tệp nhật ký được tạo trên máy Windows, chúng tôi sẽ sử dụng toán tử Pipe (|) kết hợp với các lệnh cụ thể của Windows như một phương tiện áp dụng bộ lọc.

Use code with caution.

Vì việc áp dụng các bộ lọc ở trên không mang lại bất kỳ kết quả nào, bây giờ chúng ta phải tìm kiếm thủ công các mục nhật ký chứa các dấu hiệu của cuộc tấn công tiêm lệnh. Đối với mục đích trình diễn dễ dàng, vì bài thực hành này sử dụng các tệp nhật ký chỉ dành riêng cho các cuộc tấn công web đã ghi lại, chúng tôi sẽ kiểm tra mục nhật ký đầu tiên/trên cùng để tìm các dấu hiệu của cuộc tấn công tiêm lệnh.
Trong kịch bản thời gian thực, bạn có thể phải cuộn xuống cửa sổ ứng dụng để tìm kiếm thủ công các mục nhật ký tiết lộ các chỉ báo của cuộc tấn công tiêm lệnh.
Do đó, hãy quay lại trang trước hiển thị các mục nhật ký trong tab Events khi tải lên tệp Command Injection.log. Khi kiểm tra mục nhật ký trên cùng, chúng ta thấy rằng chuỗi truy vấn của nó chứa toán tử Pipe (|) kết hợp với lệnh cat (nối), là lệnh shell được sử dụng trên máy Linux. Toán tử Pipe (|) được sử dụng kết hợp với bất kỳ lệnh shell Linux phổ biến nào hoạt động như một vector cho các cuộc tấn công tiêm lệnh.
Chuỗi truy vấn cũng tiết lộ rằng lệnh nối đã được sử dụng để truy cập tệp /etc/passwd, như được hiển thị trong ảnh chụp màn hình bên dưới. Tệp /etc/passwd lưu trữ mật khẩu của tài khoản người dùng trên các hệ thống Linux. Các phát hiện này là dấu hiệu mạnh mẽ của cuộc tấn công tiêm lệnh.
Một quan sát chi tiết về mục nhật ký cung cấp cho chúng tôi các phát hiện sau:
A. Ngày và giờ của cuộc tấn công: 24 tháng 6 năm 2020 và 06:31:36 AM
B. Địa chỉ IP của kẻ tấn công: 10.0.0.8
C. Truy vấn độc hại được sử dụng trong cuộc tấn công: GET /commandexec/example1.php?ip=127.0.0.1|cat+/etc/passwd
D. Mã trạng thái HTTP 200: Điều này biểu thị rằng yêu cầu được thực hiện tới máy chủ đã được xử lý.
Chúng ta bây giờ sẽ kiểm tra tệp nhật ký tấn công Thực thể ngoài XML (XXE) được tạo bởi máy chủ Apache.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang web.
Bạn bây giờ sẽ được chuyển hướng đến trang chủ của Splunk Enterprise. Chúng ta bây giờ cần tải lên tệp XXE Attack.log từ thư mục Nhật ký Apache. Để có thể tải lên tệp bằng chứng, hãy nhấp vào biểu tượng Add Data trên trang chủ và sau đó làm theo các bước để tải tệp lên.
Cửa sổ Open sẽ xuất hiện. Điều hướng đến E:\CHFI-Tools\Evidence Files\Log Files\Apache Logs và chọn XXE Attack.log. Nhấp vào Open để tải tệp lên.
Tệp XXE Attack.log sẽ được tải lên thành công. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Set Source Type. Nhấp vào Save As.
Cửa sổ Save Source Type sẽ xuất hiện. Trong trường Name, hãy nhập XXE Attack.log (Apache Logs) và sau đó nhấp Save để tiếp tục.
Bạn sẽ quay lại phần Set Source Type một lần nữa. Nhấp vào Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Input Settings. Nhấp vào Review để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Review. Đảm bảo các chi tiết trong phần Review là chính xác và sau đó nhấp Submit để tiếp tục.
Sau khi nhấp Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, hãy nhấp vào Start Searching để lấy tất cả các mục nhật ký từ tệp nhật ký.
Bạn sẽ thấy các mục nhật ký từ tệp đã tải lên được hiển thị trong cửa sổ Splunk Enterprise trong tab Events, như được hiển thị trong ảnh chụp màn hình bên dưới:
Để tìm kiếm sự xuất hiện của một cuộc tấn công XXE, chúng tôi sẽ áp dụng bộ lọc văn bản thuần Để làm điều này, hãy nhập ”XXE Attack.log (Apache Logs)” vào trường New Search và sau đó nhấp vào biểu tượng Search. Tuy nhiên, như trong ảnh chụp màn hình bên dưới, chúng tôi thấy rằng không có kết quả nào được trả về sau khi áp dụng bộ lọc này.
Vì bộ lọc văn bản thuần ở trên không mang lại bất kỳ kết quả nào, bây giờ chúng tôi sẽ áp dụng biến thể được mã hóa của nó. Để áp dụng biến thể được mã hóa của bộ lọc, hãy nhập %3C!Doctype sourcetype=”XXE Attack.log (Apache Logs)” vào trường New Search và sau đó nhấp vào biểu tượng Search. Khi áp dụng bộ lọc được mã hóa, chúng tôi thấy rằng một vài mục nhật ký được truy xuất và hiển thị trong tab Events, như được hiển thị trong ảnh chụp màn hình bên dưới:

      Đối với mục đích trình diễn dễ dàng, chúng tôi đã sử dụng tệp nhật ký chỉ chứa các mục cụ thể cho các cuộc tấn công web đã ghi.  Trong các kịch bản thời gian thực, tuy nhiên, bạn có thể thấy một vài mục nhật ký sau khi áp dụng bộ lọc và bạn có thể phải cuộn xuống cửa sổ để tìm kiếm thủ công mục nhật ký chứa các chỉ báo của một cuộc tấn công XXE.

Use code with caution.

Khi kiểm tra mục nhật ký trên cùng, chúng tôi thấy rằng chuỗi truy vấn trong đó chứa đầu vào XML được mã hóa có nội dung xml=%3C!DOCTYPE%20test%20[%3C!ENTITY%20xxe%20SYSTEM%20%22file%3A%2F%2F%2Fetc%2Fhosts%22%3E]%3E%3Ctest%3E%26xxe%3B%3C%2Ftest%3E, như được tô sáng trong ảnh chụp màn hình bên dưới:
Khi chúng tôi giải mã đầu vào XML được mã hóa ở trên bằng cách sử dụng bảng giải mã được cung cấp trước đó trong bài thực hành, nó được hiểu là: xml=]>&xxe;. Đầu vào XML được hiển thị trong chuỗi truy vấn ở trên được thiết kế để lấy tệp /etc/hosts của hệ thống Linux. Tệp /etc/hosts lưu trữ thông tin liên quan đến việc ánh xạ tên máy chủ với địa chỉ IP của chúng trên mạng. Từ đó, có thể suy ra rằng một cuộc tấn công XXE đã xảy ra và kẻ tấn công đã cố gắng truy cập tệp /etc/hosts.
Bạn cũng có thể áp dụng bộ lọc được mã hóa ở trên là %3c!Doctype %3c!Entity.
Một quan sát chi tiết về mục nhật ký cung cấp cho chúng tôi các phát hiện sau:A. Ngày và giờ của cuộc tấn công: 24 tháng 6 năm 2020 và 06:10:23 AMB. Địa chỉ IP của kẻ tấn công: 10.0.0.19C. Truy vấn độc hại được sử dụng để thực hiện cuộc tấn công: GET
/xml/example1.php?xml=%3C!DOCTYPE%20test%20[%3C!ENTITY%20xxe%20SYSTEM%2
0%22file%3A%2F%2F%2Fetc%2Fhosts%22%3E]%3E%3Ctest%3E%26xxe%3B%3C%2Ftest
%3ED. Mã trạng thái HTTP 200: Điều này cho thấy rằng yêu cầu được thực hiện tới máy chủ đã được xử lý
Bây giờ chúng tôi sẽ kiểm tra các tệp nhật ký tấn công brute-force được tạo từ máy chủ Apache.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang web để chuyển đến trang chủ của Splunk Enterprise. Bây giờ chúng ta cần tải lên tệp nhật ký Brute-Force từ thư mục Nhật ký Apache. Nhấp vào biểu tượng Add Data trên trang chủ và sau đó làm theo các bước để tải tệp lên.
Trong cửa sổ Open, hãy điều hướng đến E:\CHFI-Tools\Evidence Files\Log Files\Apache Logs, chọn tệp Brute-Force, và nhấp vào Open.
Tệp Brute-Force sẽ được tải lên thành công. Nhấp Next để tiếp tục.
Ở bước tiếp theo, bạn sẽ thấy phần Set Source Type. Nhấp Save As.
Cửa sổ Save Source Type sẽ xuất hiện. Trong trường Name, hãy nhập Brute-Force (Apache Logs). Nhấp Save để tiếp tục.
Bạn sẽ quay lại phần Set Source Type một lần nữa. Nhấp Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Input Settings. Nhấp Review để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Review. Đảm bảo chi tiết trong phần Review là chính xác và sau đó nhấp Submit để tiếp tục.
Sau khi nhấp Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, nhấp Start Searching để lấy các mục nhật ký từ tệp nhật ký.
Bạn bây giờ sẽ thấy các mục nhật ký từ tệp nhật ký đã tải lên được hiển thị trong cửa sổ Splunk Enterprise trong tab Events, như trong ảnh chụp màn hình bên dưới:
Các mục nhật ký được tìm nạp cho thấy một trang web WordPress đã bị nhắm mục tiêu. Ảnh chụp màn hình bên dưới hiển thị hai vùng được tô sáng được đánh dấu là 1 và 2.
Vùng được tô sáng được đánh dấu 1 đại diện cho các mục nhật ký cùng nhau tiết lộ nhiều/lặp lại các nỗ lực đăng nhập từ địa chỉ IP 192.168.198.1 trên trang web /wp-login.php, được lưu trữ trên máy chủ có địa chỉ IP 192.168.198.140. Tất cả các nỗ lực đăng nhập này đã xảy ra trong một khung thời gian rất ngắn.
Trong vùng được tô sáng được đánh dấu 2, chúng ta có thể thấy rằng mã định danh trang web trong dòng đầu tiên của chuỗi truy vấn, trước đó được phản ánh là /wp-login.php đứng trước bởi yêu cầu POST, bây giờ đã được thay đổi thành /wp-admin/ đứng trước bởi yêu cầu GET, cho thấy rằng kẻ tấn công đã thành công trong việc truy cập vào tài khoản quản trị của trang web sau một số nỗ lực đăng nhập. Đây là một dấu hiệu mạnh mẽ của cuộc tấn công brute-force.
Bạn cần cuộn xuống cửa sổ ứng dụng để tìm nhiều mục nhật ký được mô tả ở trên.
Chúng ta có thể tóm tắt các quan sát của mình từ những điều trên như sau:

      I. Ngày và giờ mà cuộc tấn công brute-force đã được cố gắng: 07 tháng 7 năm 2020, 03:08:44 AM, 03:08:47 AM và 03:08:51 AM (bạn sẽ tìm thấy nhiều nỗ lực brute-force hơn khi cuộn xuống thêm)
II. Ngày và giờ mà kẻ tấn công đã truy cập thành công quyền quản trị: 07 tháng 7 năm 2020, 03:08:51 AM
III. Địa chỉ IP của kẻ tấn công: 192.168.198.1
IV. Địa chỉ IP của máy chủ: 192.168.198.140
V. Mã trạng thái HTTP 200: Điều này cho thấy rằng yêu cầu được thực hiện tới máy chủ đã được xử lý
VI. Mã trạng thái HTTP 302: Điều này cho thấy chuyển hướng URL
VII. Trang web mà các lần đăng nhập lặp lại đã được thử bằng cách sử dụng yêu cầu POST: /wp-login.php
VIII. Mã định danh trang web cho thấy rằng kẻ tấn công đã truy cập thành công quyền quản trị bằng cách sử dụng yêu cầu GET: /wp-admin/, trong dòng đầu tiên của chuỗi truy vấn ở mục nhật ký trên cùng được đánh dấu bởi vùng được tô sáng 2 trong ảnh chụp màn hình ở trên

Use code with caution.

Chúng ta bây giờ sẽ kiểm tra tệp nhật ký tấn công brute-force được tạo bởi máy chủ IIS.
Nhấp vào splunk>enterprise ở trên cùng bên trái của trang web. Bạn sẽ được chuyển hướng đến trang chủ của Splunk Enterprise. Chúng ta bây giờ cần tải lên tệp nhật ký Brute-Force.txt từ thư mục IIS Logs. Để tải lên tệp bằng chứng, hãy nhấp vào biểu tượng Add Data trên trang chủ và sau đó làm theo các bước để tải tệp lên.
Cửa sổ Open bây giờ sẽ xuất hiện. Điều hướng đến E:\CHFI-Tools\Evidence Files\Log Files\IIS Logs và chọn Brute-Force.txt. Nhấp vào Open để tải tệp lên.
Tệp Brute-Force.txt sẽ được tải lên thành công. Nhấp Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Set Source Type. Nhấp vào Save As.
Cửa sổ Save Source Type sẽ xuất hiện. Trong trường Name, hãy nhập Brute-Force.txt (IIS Logs). Nhấp Save để tiếp tục.
Bạn sẽ quay lại phần Set Source Type một lần nữa. Nhấp Next để tiếp tục.
Trong bước tiếp theo, bạn sẽ thấy phần Input Settings. Nhấp vào Review để tiếp tục.
Trong bước tiếp theo, phần Review sẽ xuất hiện. Đảm bảo chi tiết trong phần Review là chính xác và sau đó nhấp Submit để tiếp tục.
Sau khi nhấp vào Submit, cửa sổ ứng dụng sẽ hiển thị thông báo sau: File has been uploaded successfully. Bây giờ, nhấp vào Start Searching để lấy tất cả các mục nhật ký từ tệp nhật ký.
Bạn bây giờ sẽ thấy các mục nhật ký từ tệp nhật ký được tải lên được hiển thị trong cửa sổ Splunk Enterprise trong tab Events, như trong ảnh chụp màn hình sau:
Các mục nhật ký được tìm nạp cho thấy một trang web WordPress đã bị nhắm mục tiêu. Cuộn xuống kết quả để tìm các mục nhật ký cùng nhau tiết lộ nhiều nỗ lực đăng nhập, như được chỉ ra trong vùng được tô sáng 1 trong ảnh chụp màn hình bên dưới. Trong tất cả các mục này, chúng tôi thấy rằng nhiều/lặp lại các nỗ lực đăng nhập đã được thực hiện từ địa chỉ IP 192.168.198.1 trên trang web /forensics/wp-login.php, được lưu trữ trên máy chủ có địa chỉ IP 192.168.198.142.
Tương tự, khi kiểm tra mục nhật ký được đánh dấu bằng vùng được tô sáng 2 ở trên cùng, chúng ta có thể thấy rằng mã định danh trang web trong dòng đầu tiên của chuỗi truy vấn, trước đó được phản ánh là /forensics/wp-login.php đứng trước bởi yêu cầu POST trong vùng được tô sáng 1, bây giờ đã được thay đổi thành /forensics/wp-admin/ đứng trước bởi yêu cầu GET.
Những quan sát này cho thấy rằng địa chỉ IP 192.168.198.1 thuộc về một người dùng/kẻ tấn công độc hại, người hiện đã có được quyền quản trị trên trang web WordPress bị ảnh hưởng. Như trong ảnh chụp màn hình bên dưới, các nỗ lực đăng nhập lặp lại này đã được thực hiện trong một khung thời gian rất ngắn. Dựa trên điều này, chúng ta có thể suy ra rằng một cuộc tấn công brute-force đã được cố gắng.
Đối với mục đích trình diễn dễ dàng, vì bài thực hành này đã sử dụng tệp nhật ký chỉ chứa các mục nhật ký cụ thể cho các cuộc tấn công web đã ghi lại, chúng tôi có thể tìm thấy các chỉ báo của cuộc tấn công brute-force trong một vài mục nhật ký đầu tiên từ trên cùng. Trong thời gian thực, tuy nhiên, bạn có thể phải cuộn xuống cửa sổ ứng dụng và tìm kiếm thủ công những mục nhật ký tiết lộ sự xuất hiện của cuộc tấn công brute-force.
Chúng ta có thể tóm tắt các quan sát của mình từ các mục nhật ký ở trên như sau:

I. Ngày và giờ mà cuộc tấn công brute-force đã được cố gắng: Ngày 08 tháng 7 năm 2020, 2:00:55 PM, 2:01:00 PM và 2:01:05 PM (bạn sẽ tìm thấy nhiều nỗ lực brute-force hơn khi bạn cuộn xuống thêm)
II. Ngày và giờ mà kẻ tấn công truy cập thành công quyền quản trị: Ngày 08 tháng 7 năm 2020, 02:01:07 PM
III. Địa chỉ IP của Máy chủ: 192.168.198.142
IV. Trang web mà các lần đăng nhập lặp lại đã được thực hiện bằng yêu cầu POST: /forensics/wp-login.php
V. Địa chỉ IP của Kẻ tấn công: 192.168.198.1
VI. Mã trạng thái HTTP 200: Điều này cho thấy rằng yêu cầu được thực hiện tới máy chủ đã được xử lý
VII. Mã trạng thái HTTP 302: Điều này cho thấy chuyển hướng URL
VIII. Bộ nhận dạng trang web cho thấy rằng kẻ tấn công đã truy cập thành công quyền quản trị bằng yêu cầu GET: /forensics/wp-admin/ trong dòng đầu tiên của chuỗi truy vấn tại mục nhật ký trên cùng được đánh dấu bằng vùng được tô sáng 2 trong ảnh chụp màn hình ở trên.

Bằng cách này, bạn có thể kiểm tra các tệp nhật ký từ máy chủ Apache và IIS cũng như tường lửa ứng dụng web ModSecurity để tìm các chỉ báo liên quan đến các cuộc tấn công web khác nhau.
Đóng tất cả các cửa sổ đang mở.

Bài thực hành 2: Xác định và Điều tra Các Cuộc tấn công Ứng dụng Web bằng Python

Kịch bản thực hành:

Một cuộc tấn công mạng đã nhắm vào một tổ chức, gây nguy hiểm cho ứng dụng web của họ chuyên bán các sản phẩm đa dạng. Những kẻ tấn công độc hại không chỉ làm gián đoạn chức năng của trang web mà còn thu thập bất hợp pháp thông tin nhận dạng cá nhân từ người dùng. Để đối phó, công ty đã thuê đơn vị điều tra pháp y mạng của sở cảnh sát tiểu bang để điều tra, khôi phục dữ liệu khách hàng bị đánh cắp, củng cố hệ thống của họ và khôi phục niềm tin của khách hàng vào tính toàn vẹn của doanh nghiệp của họ.

John là một nhà điều tra pháp y, người được giao nhiệm vụ tận dụng các tập lệnh Python để đi sâu vào nhật ký máy chủ, phát hiện các mẫu tấn công và thu thập bằng chứng để hiểu bản chất của cuộc tấn công.

Mục tiêu thực hành:

Điều tra các cuộc tấn công ứng dụng web bao gồm kiểm tra và phân tích toàn diện các mối đe dọa mạng nhắm vào các ứng dụng web. Quá trình này sử dụng các kỹ thuật pháp y khác nhau để phát hiện các hoạt động độc hại, khám phá các mẫu tấn công và thu thập bằng chứng. Các nhà điều tra kỹ thuật số sử dụng các công cụ và phương pháp để xem xét kỹ lưỡng nhật ký, theo dõi các lỗ hổng và tái tạo các kịch bản tấn công.

Mục tiêu của bài thực hành này là giúp bạn hiểu cách kiểm tra các tệp nhật ký và tìm kiếm các hiện vật liên quan đến các cuộc tấn công ứng dụng web bằng tập lệnh Python.

Tổng quan về Bài thực hành:

Bài thực hành này giúp bạn làm quen với quá trình kiểm tra các tệp nhật ký được tạo bởi máy chủ web, nhật ký tiêm SQL, nhật ký tiêm lệnh và nhật ký duyệt thư mục để kiểm tra các chỉ báo về các cuộc tấn công web bằng các tập lệnh Python.

Nhiệm vụ thực hành:

Đầu tiên chúng ta sẽ viết một tập lệnh Python để phân tích nhật ký máy chủ web Apache, cung cấp cho các nhà điều tra một nguồn phong phú để hiểu các mẫu lưu lượng truy cập, hành vi của người dùng, v.v.
Nhấp vào Ubuntu Forensics để chuyển sang máy Ubuntu Forensics.
Theo mặc định, hồ sơ người dùng jason được chọn, hãy nhập mật khẩu toor vào trường Password và nhấn Enter để đăng nhập.
Chúng ta sẽ thực hiện phân tích tĩnh trên tệp nhật ký Tiêm SQL. Để làm như vậy, chúng ta cần sao chép SQL_Injection.log từ thư mục CHFI-Tools\Evidence Files\Log Files\Apache Logs và dán nó vào thư mục Home.
Nhấp vào biểu tượng Files trong bảng khởi chạy để khởi chạy Trình quản lý tệp.
Cửa sổ trình quản lý tệp sẽ xuất hiện trỏ đến thư mục Home. Nhấp vào thư mục chfi-tools on 10.10.1.22 được đánh dấu trang.
CHFI-Tools sẽ xuất hiện trong cửa sổ. Điều hướng đến thư mục Evidence Files\Log Files\Apache Logs và sao chép tệp SQL Injection.log và dán nó vào thư mục Home.
Bây giờ, chúng ta sẽ viết một tập lệnh Python để phân tích nhật ký máy chủ web Apache. Để làm như vậy, hãy nhấp vào biểu tượng Terminal từ bảng khởi chạy để khởi chạy thiết bị đầu cuối dòng lệnh.
Thiết bị đầu cuối dòng lệnh sẽ khởi chạy. Bạn cần quyền root trong thiết bị đầu cuối để cài đặt ứng dụng.
Bây giờ, hãy nhập sudo su và nhấn Enter. Bạn sẽ được nhắc nhập mật khẩu.
Nhập toor làm mật khẩu và nhấn Enter.
Bây giờ, bạn sẽ vào thiết bị đầu cuối root, như được hiển thị trong ảnh chụp màn hình sau:
Trong cửa sổ thiết bị đầu cuối, hãy nhập gedit SQL_Injection.py và nhấn Enter để mở cửa sổ Trình soạn thảo văn bản.
Trình soạn thảo văn bản SQL_Injection.py sẽ được mở. Bây giờ, hãy nhập mã được hiển thị trong ảnh chụp màn hình bên dưới vào tệp và lưu nó vào thư mục Home.
Để thuận tiện, chúng tôi đã đặt tập lệnh Python (SQL_Injection.py) cùng với log_filePath tại chfi-tools trên 10.10.1.22\CHFIv11 Module 10 Investigating Web Attacks\Python Scripts. Nếu bạn muốn sử dụng tệp này, hãy sao chép tệp SQL_Injection.py, dán nó vào thư mục Home và tiếp tục từ Bước #16.
Chúng ta cần cung cấp vị trí tệp nhật ký trong dòng 15 của tập lệnh Python để phân tích cú pháp nhật ký.
Trong dòng 15, hãy thay thế path_to_apache_log_file.log bằng /home/jason/SQL Injection.log như được hiển thị trong ảnh chụp màn hình. Lưu nó và đóng cửa sổ Trình soạn thảo văn bản.
Bây giờ, hãy chuyển về cửa sổ thiết bị đầu cuối và nhập python3 SQL_Injection.py và nhấn Enter để chạy tập lệnh Python.
Khi thực hiện tập lệnh thành công, bạn có thể xem nhật ký Tiêm SQL đã được phân tích cú pháp trong thiết bị đầu cuối.
Bây giờ hãy nhấp vào biểu tượng Find ở trên cùng của Màn hình nền.
Bây giờ, chúng ta sẽ áp dụng một biến thể được mã hóa của bộ lọc root’ Union Select để tìm kiếm các dấu hiệu của một cuộc tấn công Tiêm SQL. Để áp dụng bộ lọc được mã hóa, hãy nhập root%27%20%20union%20select vào ô Find và nhấn Enter.
Bộ lọc được mã hóa sẽ được tô sáng. Đóng cửa sổ Find.
Khi kiểm tra mục nhật ký trên cùng, chúng tôi thấy rằng nó chứa một yêu cầu GET với một truy vấn UniON SeLeCT. Hơn nữa, truy vấn UniON SeLeCT đang tham chiếu các tham số như 1,table_name,3,4,5 From Information_schema.tables where Table_Schema=DatabasE() limit 0,1– – v.v. Từ đây, chúng ta có thể suy ra rằng một kẻ tấn công đã cố gắng truy cập chi tiết của các bảng hiện diện trong cơ sở dữ liệu và nội dung được lưu trữ trong đó bằng cách sử dụng truy vấn UniON SeLeCT, là một chỉ báo của một cuộc tấn công Tiêm SQL.
Trước khi tiếp tục với nhiệm vụ tiếp theo, hãy làm theo các Bước từ 6 và 7 để điều hướng đến thư mục Evidence Files\Log Files\Apache Logs và sao chép tệp Command Injection.log và dán nó vào thư mục Home.
Bây giờ, chúng ta sẽ kiểm tra Nhật ký Máy chủ Web để tìm cuộc tấn công tiêm lệnh bằng Python. Để làm như vậy, trong cửa sổ Thiết bị đầu cuối, hãy nhập gedit Command_Injection.py và nhấn Enter.
Trình soạn thảo văn bản Command_Injection.py sẽ được mở. Bây giờ, hãy nhập mã được hiển thị trong ảnh chụp màn hình bên dưới vào tệp và lưu nó vào thư mục Home.
Để thuận tiện, chúng tôi đã đặt tập lệnh Python (Command_Injection.py) cùng với log_filePath tại chfi-tools trên 10.10.1.22\CHFIv11 Module 10 Investigating Web Attacks\Python Scripts. Nếu bạn muốn sử dụng tệp này, hãy sao chép tệp Command_Injection.py, dán nó vào thư mục Home, và tiếp tục từ Bước #27.
Chúng ta cần cung cấp vị trí tệp nhật ký trong dòng 12 của tập lệnh Python để phân tích cú pháp nhật ký.
Trong dòng 12, hãy thay thế path_to_webserver_log bằng /home/jason/Command Injection.log như được hiển thị trong ảnh chụp màn hình. Lưu nó và đóng cửa sổ Trình soạn thảo văn bản.
Bây giờ, hãy chuyển về cửa sổ thiết bị đầu cuối, nhập python3 Command_Injection.py và nhấn Enter để chạy tập lệnh Python.
Khi thực hiện tập lệnh thành công, bạn có thể xem nhật ký Tiêm lệnh đã được phân tích cú pháp trong thiết bị đầu cuối.
Cuộn xuống cuối các mục nhật ký và bạn sẽ thấy truy vấn độc hại được sử dụng trong cuộc tấn công: GET /commandexec/example1.php?ip=127.0.0.1|cat+/etc/passwd với mã trạng thái HTTP 200: Điều này biểu thị rằng yêu cầu được thực hiện tới máy chủ đã được xử lý.
Trước khi tiếp tục với nhiệm vụ tiếp theo, hãy làm theo các Bước từ 6 và 7 để điều hướng đến thư mục Evidence Files\Log Files\Apache Logs và sao chép tệp Directory Traversal và dán nó vào thư mục Home.
Bây giờ, chúng ta sẽ kiểm tra Nhật ký Máy chủ Web để tìm cuộc tấn công Duyệt Đường dẫn/Thư mục bằng Python. Để làm như vậy, trong cửa sổ Thiết bị đầu cuối, hãy nhập gedit Directory_Traversal.py và nhấn Enter.
Trình soạn thảo văn bản Directory_Traversal.py sẽ được mở ra; Bây giờ, hãy nhập mã được hiển thị trong ảnh chụp màn hình bên dưới vào tệp và lưu nó vào thư mục Home.
Để thuận tiện, chúng tôi đã đặt tập lệnh Python (Directory_Traversal.py) cùng với log_filePath tại chfi-tools trên 10.10.1.22\CHFIv11 Module 10 Investigating Web Attacks\Python Scripts. Nếu bạn muốn sử dụng tệp này, hãy sao chép tệp Directory_Traversal.py, dán nó vào thư mục Home và tiếp tục từ Bước #34.
Trong dòng 12, hãy thay thế path_to_log_file.log bằng /home/jason/Directory Traversal như được hiển thị trong ảnh chụp màn hình. Lưu và đóng cửa sổ Trình soạn thảo văn bản.
Bây giờ, hãy chuyển về cửa sổ thiết bị đầu cuối, nhập python3 Directory_Traversal.py và nhấn Enter để chạy tập lệnh Python.
Khi thực hiện tập lệnh thành công, bạn có thể xem nhật ký Duyệt Thư mục đã được phân tích cú pháp trong thiết bị đầu cuối.
Trước khi tiếp tục với nhiệm vụ tiếp theo, hãy làm theo các Bước từ 6 và 7 để điều hướng đến thư mục Evidence Files\Log Files\Apache Logs và sao chép tệp XSS và dán nó vào thư mục Home.
Bây giờ, chúng ta sẽ kiểm tra Nhật ký Máy chủ Web để tìm cuộc tấn công XSS bằng Python. Để làm như vậy, trong cửa sổ Thiết bị đầu cuối, hãy nhập gedit XSS.py và nhấn Enter.
Trình soạn thảo văn bản XSS.py sẽ được mở. Bây giờ, hãy nhập mã được hiển thị trong ảnh chụp màn hình bên dưới vào tệp và lưu nó vào thư mục Home.
Để thuận tiện, chúng tôi đã đặt tập lệnh Python (XSS.py) cùng với log_filePath tại chfi-tools trên 10.10.1.22\CHFIv11 Module 10 Investigating Web Attacks\Python Scripts. Nếu bạn muốn sử dụng tệp này, hãy sao chép tệp XSS.py, dán nó vào thư mục Home và tiếp tục từ Bước #40.
Trong dòng 12, thay thế path_to_webserver_log bằng /home/jason/XSS như được hiển thị trong ảnh chụp màn hình. Lưu và đóng cửa sổ Trình soạn thảo văn bản.
Bây giờ, hãy chuyển về cửa sổ thiết bị đầu cuối và nhập python3 XSS.py và nhấn Enter để chạy tập lệnh Python.
Khi thực hiện tập lệnh thành công, bạn có thể xem nhật ký XSS đã phân tích cú pháp trong thiết bị đầu cuối.
Bằng cách này, bạn có thể kiểm tra các tệp nhật ký từ Apache để tìm các chỉ báo liên quan đến các cuộc tấn công web khác nhau bằng Python.
Đóng tất cả các cửa sổ đang mở.