Đây là loạt bài chai sẽ cho 1 học viên lớp Comptia Pentest +, có vẽ hơi sai sai vì mãng này phải là dforensic mới đúng nhưng các em ấy đang làm bài tập lớn của trường về antiforensic và linux forensic. Cũng không biết là trường gì, mà bài tập lớn là lớn thế nào, có khi các thầy cô thích chơi chữ cho nó ra vẽ phức tạp.

Về case study Windows Forensic có rất nhiều, như các bài Banking Trouble của Honeynet hay CHFI v10, hoặc các bài mở rộng mà chúng tôi hay trình bày cho các bạn lớp CHFI là Hacking Case với lại Data Leak Case của NIST rất tuyệt , hoặc mẫu Donal Bờ La Ke (tôi hay đọc vậy) trên SANS FOR 504 cũng very hay, nhất là khi ta dùng SANS WINFORENSIC để mà “chém” nó.

Quay trở lại với yêu cầu của bài tập lớn tôi tìm thấy có vài chủ đề khá thú vị, ví dụ như tình huống mới của NIST có tên là Linxu Forensic dùng chính con TryHackMe https://tryhackme.com/room/lookingforevidencesrr (khôn rõ room free hay trả phí, nếu trả phí thì các em student cũng nên trả mà làm). Hoặc chơi cái bài OverPass2 cho nó “ảo”, (các bạn xem video chia sẽ trên kênh Tele CHFI v10 về Overpass 2) kiểu như bị hack rồi phải hack ngược lại để dành quyền kiểm soát, đây là kiểu dforensic hackback chứ tôi thấy nên báo công an hay an ninh mạng cho nhanh.

Trên TryHackMe có nhiều bài về DForensic hay lắm, các anh em cứ vào đó mà mần vừa khỏe và sẵn mẫu như bài Advent of Cyber 4 , ngoài ra thì có root-me và rất nhiều trang khác cũng hay mà tôi không có tìm hiểu nên cũng không rành lắm.

Tuy nhiên, muốn dễ làm Bài Tập BIG hơn nữa thì lấy Mod 7 Lab của CHFI v10 , Linux & Mac Forensic (cái này tôi mới phải hỏi lại các hoc viên vì không nhớ Module Lab nào nói về Forensic cho Linux), bên CHFI v10 nó còn còn DeepWeb Forensic nữa, nghe tên là thấy đã rồi.

Trong mod 7 lab Digital Forensic cho Linux và MAC nó hướng dẫn các thao tác dforensic cũng như trên Widnows như là chạy lệnh xem logfile, xem các lệnh cuối, và nhiều thứ khác, dĩ nhiên lệnh cũng khác trên Windows, ai học thi chứng chỉ quốc tế CHFI v10 cần nhớ kỹ mấy lệnh này.

Sau đó là dùng Autopsy phân tích 1 image của hệ thống Linux, ngày nay con Autopsy nó mạnh lắm, làm được đủ thứ hơn cả tool xịn trả phí. Đôi khi chạy trên image lớn quá nó cũng có sự cố như treo hay chậm chạp do tổn thất tài nguyên nhưng đây là tình hình chung, chúng ta cần lập kế hoạch chia nhỏ evidence chứ cứ imaging nguyên cả đống ổ đĩa thì tool nào chả thế, chạy miết cũng phải treo cả. Sau khi lab cái autopsy đã đời các bạn sẽ được hướng dẫn phân tích bộ nhớ 1 máy linux, rồi trích xuất thông tin từ nó, đây toàn là những thao tác đỉnh cao , có lẽ là dùng Volatility rồi mấy con carve trên Linux chứ hàng Windows đụng tới mãng này khá kém, ngày cả tool ngàn đô, hoặc do mình dốt làm chưa tới cứ đổ thừa do tool tiếc, nhưng mà cái nào dễ chơi cứ dùng.

OK, nói lan man thế để các bạn hình dùng về D Forensic với máy Linux (chứ không phải dùng tool trên linux), còn bài này tôi lấy 1 bài của tụi nước ngoài nó làm sẵn, dịch lại cho nhanh nhé. Bài gốc đây !

Một nghiên cứu điển hình về Linux Forensics Starter (đang biên soạn, chưa hiệu chỉnh gì cả)

Linux là hệ điều hành chiếm ưu thế được sử dụng cho hàng triệu máy chủ web mà Internet được xây dựng trên đó. ZDNet báo cáo rằng trên thực tế, 96,3% máy chủ web chạy Linux. Do đó, một số lượng lớn các sự cố liên quan đến máy chủ web sẽ liên quan đến việc phân tích các hệ thống dựa trên Linux. 

Tuy nhiên, tài liệu miễn phí để tìm hiểu và hiểu pháp y Linux còn thiếu. Sự thiếu sót đó đã dẫn đến việc tạo ra trường hợp này và tài liệu đào tạo đi kèm với nó. 

Do sự thống trị của các máy chủ web Linux, trường hợp này bao gồm một máy chủ web bị xâm nhập đang chạy Ubuntu Server. Bài viết này không chỉ đề cập đến cách điều tra máy chủ web Linux bị xâm phạm mà còn cả các vị trí khác nhau nơi có thể tìm thấy các tạo phẩm lạ cũng như cách trích xuất và phân tích chúng. Trường hợp này sử dụng các phương pháp cơ bản và giả sử không yêu cầu điều tra về Linux hoặc nền tảng sử dụng Linux.

Trường hợp này đã được trình bày tại OSDFCon 2019 và được trình bày dưới dạng một hội thảo tại cùng một hội nghị, cùng với DFRWS 2020.

Gắn kết và xác minh

Để bắt đầu phân tích trường hợp của mình, chúng ta cần thiết lập môi trường phân tích. Đầu tiên chúng ta sẽ tạo một thư mục để mount case image để phân tích. Tiếp theo, vì chúng tôi đang sử dụng hình ảnh .E01, chúng tôi có thể sử dụng ewfverify từ libewf để xác minh tính toàn vẹn của hình ảnh. Sau đó, sử dụng mmls từ The Sleuth Kit (TSK) , chúng ta có thể thấy các ổ đĩa có trên ảnh đĩa. 

Nhận tin tức DFIR mới nhất

Tham gia bản tin Forensic Focus để có các bài viết hay nhất về DFIR trong hộp thư đến của bạn hàng tháng.Hủy đăng ký bất cứ lúc nào. Chúng tôi tôn trọng quyền riêng tư của bạn – hãy đọc 

chính sách quyền riêng tư của chúng tôi .

Trong trường hợp này, chúng tôi quan tâm đến ổ đĩa ở chỉ mục 6, được gắn nhãn là ổ đĩa Trình quản lý khối lượng hợp lý Linux (LVM) (xem Hình 1.1). LVM cho phép bạn tạo các Khối logic có thể trải rộng trên nhiều đĩa hoặc Khối vật lý. Các khối Logical và Vật lý này được liên kết với nhau thông qua một Nhóm Khối. 

Khi chúng tôi đã gắn hình ảnh vào môi trường phân tích của mình, chúng tôi sẽ cần ánh xạ các ổ đĩa Logical và Vật lý này để truy cập hệ thống tệp bên trong ổ đĩa LVM.

Hình 1.1 – đầu ra mmls hiển thị âm lượng LVM

Tiếp theo, chúng tôi sẽ sử dụng ewfmount từ libewf để có được bản trình bày thô về nội dung của hình ảnh .E01 mà chúng tôi có thể gắn kết để phân tích. Nếu bạn thấy một tệp có tên ewf1 xuất hiện trong thư mục mà bạn đã chạy ewfmount, bạn có thể tiếp tục.

Hình 1.2 – Chạy ewfmount

Bây giờ, chúng tôi muốn tạo ánh xạ của ổ đĩa LVM trên ổ đĩa để chúng tôi có thể phân tích nội dung của nó. Để làm điều này, chúng tôi sẽ sử dụng kpartx để tự động phát hiện và tạo các ánh xạ này cho chúng tôi (xem trong Hình 1.3). 

Tùy chọn -a được sử dụng để phát hiện và thêm tất cả ánh xạ phân vùng mà công cụ tìm thấy. Bạn có thể sử dụng -l để hiển thị những ánh xạ mà kpartx sẽ có thể tìm và thêm. Và -v có thể được sử dụng để tăng mức độ chi tiết. 

Đảm bảo rằng bạn chạy kpartx mà không có tùy chọn -l để tạo ánh xạ phân vùng, vì tùy chọn này chỉ hiển thị những phân vùng nào sẽ được ánh xạ và sau đó loại bỏ các thiết bị như đã thấy trong hộp màu vàng trong Hình 1.3.

Nhân vật. 1.3 – Kiểm tra ánh xạ và tạo ánh xạ cho LVM volume với kpartx

Sau khi ánh xạ phân vùng được tạo, chúng ta có thể xem thông tin về các Ổ đĩa Hợp lý bằng lvs hoặc lvdisplay, thông tin về các ổ đĩa vật lý bằng cách sử dụng pvs hoặc pvdisplay và thông tin về các nhóm âm lượng bằng cách sử dụng vgs hoặc vgdisplay. 

Sử dụng lvdisplay, chúng ta có thể thấy tên của từng Khối hợp lý cũng như Nhóm khối mà chúng là một phần của. Chúng ta cũng có thể đảm bảo chúng ở chế độ chỉ đọc và đang hoạt động (xem Hình 1.4). Nếu bạn thấy “KHÔNG khả dụng” trong dòng “Trạng thái LV”, bạn có thể sử dụng vgchange -ay vg_name để kích hoạt tất cả các Tập hợp lý trong Nhóm Tập đĩa. Âm lượng đang hoạt động cho phép chúng tôi gắn kết và phân tích nội dung của nó bằng các công cụ của chúng tôi.

Nhân vật. 1.4 – Đầu ra của lvdisplay. Lưu ý trạng thái LV

Bạn cũng có thể sử dụng thông tin dmsetup để lấy UUID của mỗi ổ đĩa logic (xem Hình 1.5). Lưu ý rằng âm lượng phải được kích hoạt để được hiển thị bằng lệnh này.

Nhân vật. 1.5 – Đầu ra của dmsetup

Bây giờ chúng ta có thể gắn ổ đĩa gốc chứa dữ liệu. Âm lượng “hoán đổi” chỉ là phần bổ sung cho bộ nhớ hệ thống. Tuy nhiên, chạy lệnh mount bình thường sẽ báo lỗi cho chúng tôi. Điều này là do hệ thống tệp đã được ngắt kết nối không đúng cách và cần được kiểm tra bằng cách sử dụng nhật ký hệ thống tệp trước khi có thể gắn lại. 

Để giải quyết vấn đề này, chúng ta có thể thêm tùy chọn noload vào lệnh mount để ngăn việc kiểm tra nhật ký trong khi mount (xem Hình 1.6).

Nhân vật. 1.6 – Gắn ổ đĩa gốc thành công

Giờ đây, tất cả các tệp trên ổ đĩa gốc có thể được xem và xử lý bằng cách trỏ đến thư mục “case1/”. 

Chúng tôi khuyên bạn nên tự làm quen với Phân cấp hệ thống tệp Linux trước khi tiếp tục, vì nó sẽ giúp bạn điều hướng qua các hệ thống Linux một cách dễ dàng và thông báo cho bạn về nơi các tệp sẽ được lưu trữ trên bất kỳ hệ thống Linux nào. Bạn cũng nên kiểm tra múi giờ của hình ảnh bằng cách xem tệp tại “case1/etc/timezone”.

Nhìn vào nhật ký đăng nhập

Để bắt đầu phân tích, chúng ta có thể xem các tệp nhật ký. Bạn có thể tìm thấy hầu hết các tệp nhật ký hệ thống và ứng dụng bằng cách tìm trong “/var/log” trên hệ thống Linux. Trong trường hợp này, chúng tôi quan tâm nhất đến “wtmp”, “btmp”, “auth.log” và “lastlog” để bắt đầu điều tra vì tất cả các tệp này đều lưu trữ các lần đăng nhập. 

Mặc dù tệp “btmp” chỉ lưu trữ các lần đăng nhập không thành công, nhưng tệp “wtmp” lưu trữ tất cả các thông tin đăng nhập vào hệ thống và là tệp mặc định được sử dụng bởi lệnh cuối cùng để hiển thị những người dùng cuối cùng đã đăng nhập. Chúng ta có thể xem cả hai tệp này bằng cách sử dụng lệnh cuối cùng trên máy phân tích của chúng tôi, trỏ nó tới các tệp trong hình ảnh của chúng tôi bằng tùy chọn -f.

Nhân vật. 2.1 – Nội dung của btmp

Nhân vật. 2.2 – Nội dung của wtmp

Từ Hình 2.1, chúng ta có thể thấy có rất nhiều lần đăng nhập thất bại đến từ địa chỉ IP 192.168.210.131. Chúng ta cũng thấy “mail” của người dùng đã được đăng nhập từ cùng một địa chỉ IP và chúng ta có thể thấy họ đã đăng nhập bốn lần riêng biệt trong Hình 2.2. 

Tiếp theo, chúng tôi có thể phân tích “auth.log” để xác nhận mọi phát hiện từ nhật ký “wtmp” và “btmp”. Chúng tôi cũng có thể xem thêm thông tin về các loại thông tin đăng nhập, mọi cách sử dụng sudo và các sự kiện liên quan đến xác thực khác.

Nhân vật. 2.3 – Phần của auth.log

Từ việc tìm kiếm nhanh tệp “auth.log” để tìm địa chỉ IP và tên người dùng “mail”, chúng ta có thể thấy một số hoạt động đáng ngờ đã có trong Hình 2.3. Chúng ta có thể thấy nhiều lần thử mật khẩu không thành công đối với root, có thể là do một cuộc tấn công vũ phu. Khoảng một giờ sau khi kết thúc nỗ lực brute force thất bại, chúng tôi thấy người dùng php được tạo và thêm vào nhóm “sudo” cũng như thư của người dùng được cung cấp trình bao đăng nhập, mật khẩu và được thêm vào nhóm sudo. Từ đó, chúng tôi có thể xác định kẻ tấn công đã tìm được cách khác vào hệ thống của chúng tôi.

Cuối cùng, chúng ta có thể xem tệp “lastlog”, tệp này hiển thị lần đăng nhập cuối cùng của mỗi người dùng trên hệ thống và thông tin đó đến từ đâu. Trong trường hợp của chúng tôi, tệp “lastlog” đã bị hỏng, nhưng chúng tôi vẫn có thể tìm thấy một số thông tin từ tệp đó bằng lệnh chuỗi. Như bạn có thể thấy trong Hình 2.4, có thể thấy cùng một IP từ tệp “wtmp”, “btmp” và “auth.log”.

Nhân vật. 2.4 – Kết quả chuỗi trên tập tin lastlog

Sử dụng The Sleuth Kit (TSK)

Tiếp theo, chúng tôi muốn tìm hiểu điều gì đã xảy ra với tệp “lastlog”. TSK là một bộ công cụ tuyệt vời để thực hiện phân tích ở cấp hệ thống tệp. Vì nó hoạt động ở cấp độ hệ thống tệp, bạn cần trỏ nó trực tiếp tới một hệ thống tệp. 

Khi chúng tôi đang thực hiện quá trình gắn kết, chúng tôi đã ánh xạ các hệ thống tệp trong ổ đĩa LVM tới các thiết bị của riêng chúng bằng cách sử dụng kpartx. Để truy cập hệ thống tệp mà chúng tôi quan tâm, chúng tôi có thể xem trong thư mục “/dev/mapper” trên máy phân tích của mình.

Nhân vật. 3.1 – Các điểm gắn kết được ánh xạ

Trong trường hợp này, hệ thống tệp của chúng tôi là “/dev/mapper/VulnOSv2–vg-root” (Xem Hình 3.1). Chúng tôi có thể sử dụng đường dẫn này để chạy các công cụ TSK trên hệ thống tệp để tìm hiểu điều gì đã xảy ra với tệp “lastlog”. Đầu tiên chúng ta có thể chạy fls với tùy chọn -l để tìm inode cho thư mục “/var”. Lệnh fls sẽ liệt kê tất cả các tệp trên thư mục gốc của hệ thống tệp ở chế độ liệt kê dài.

Từ đó, chúng ta có thể tìm thấy số inode của thư mục /var. Sử dụng lệnh fls -l tương tự như chạy lệnh ls -l thông thường của Linux. Đầu ra cung cấp một danh sách dài các chi tiết, bao gồm số indoe, chủ sở hữu tệp, chủ sở hữu nhóm của tệp, quyền, dấu thời gian, v.v.

Hình 3.2 cho thấy đầu ra mà chúng ta nhận được với inode của thư mục “/var”. Lưu ý rằng đầu ra đã bị cắt bớt bằng cách sử dụng grep để tìm dòng tham chiếu đến thư mục “/var”.

Nhân vật. 3.2 – Tìm thư mục “/var” bằng fls

Tiếp theo, chúng ta có thể liệt kê nội dung của thư mục “/var” bằng cách nối thêm inode mà chúng ta đã tìm thấy vào lệnh trước đó (ví dụ: sudo fls -l VulnOSv2–vg-root 523266) để tìm inode của thư mục “/var/log” . Sau đó, chúng ta có thể sử dụng inode mà chúng ta tìm thấy cho thư mục “/var/log” để liệt kê nội dung của nó và tìm hiểu điều gì đã xảy ra với tệp “lastlog”.

Nhân vật. 3.3 – inodes nhật ký cuối cùng được hiển thị

Trong Hình 3.3, chúng ta có thể thấy rằng tệp “lastlog” có phiên bản “.swp” và “.swpx”. Thật không may, như thường lệ, các nút này đã được phân bổ lại, vì vậy chúng tôi không thể trích xuất dữ liệu từ chúng. Tuy nhiên, chúng tôi có thể xác định rằng tệp này đã được sửa đổi dựa trên thực tế là các tệp “.swp” và “.swpx” này đã tồn tại, vì chúng được tạo khi tệp được chỉnh sửa trong trình chỉnh sửa vi dưới dạng tệp tạm thời có thể khôi phục được nếu vi sự cố.

Người dùng và Nhóm, v.v.

Tiếp theo, chúng tôi có thể thu thập thông tin về những người dùng và nhóm nào trên hệ thống. Để làm điều này, chúng tôi bắt đầu bằng cách xem xét ba tệp trong thư mục “/etc”: “passwd”, “shadow” và “group”. 

• Tệp passwd sẽ chứa danh sách tất cả người dùng trên hệ thống, thư mục chính, trình bao đăng nhập và số UID và GID của họ. 
• Tệp bóng chứa mật khẩu người dùng được băm. 
• Cuối cùng, tệp nhóm lưu giữ danh sách tất cả các thành viên của mỗi nhóm trên hệ thống. 

Chúng tôi đã tìm thấy hai người dùng đáng ngờ trước đó, “mail” và “php”. Chúng tôi có thể sử dụng các tệp này để điều tra chúng.

Đầu tiên, chúng ta có thể kiểm tra tệp “passwd” để xem liệu “mail” và “php” có sử dụng các mục nhập hay không. Chúng ta có thể thấy rằng cả hai người dùng đang sử dụng bash làm shell đăng nhập của họ và chúng ta có thể thấy các thư mục chính của mỗi người dùng trong Hình 4.1. 

Tiếp theo, chúng ta có thể kiểm tra các tệp “shadow” và “group” cho những người dùng này. Lệnh được thấy trong Hình 4.2 in nội dung của từng tệp ra thiết bị xuất chuẩn, sau đó tìm kiếm các mục có “mail” hoặc “php” bằng cách sử dụng “grep” và hiển thị chúng cho chúng tôi. 

Chúng ta có thể thấy rằng cả “mail” và “php” đều có mật khẩu từ tệp bóng và mật khẩu của “mail” đó sẽ không bao giờ hết hạn. Từ tệp “group”, chúng ta có thể thấy rằng cả “mail” và “php” đều là một phần của nhóm “sudo”, cho phép chúng truy cập vào lệnh sudo.

Hình 4.1 – nội dung tập tin passwd

Hình 4.2 – Kết quả tìm kiếm nội dung tập tin bóng và tập tin nhóm

Tiếp theo, trong Hình 4.1, chúng ta có thể thấy các thư mục chính của người dùng “mail” và “php”. Kiểm tra nội dung của các thư mục này trong Hình 4.2, chúng ta có thể thấy người dùng “php” chỉ có các tệp được tạo từ khung được sử dụng để tạo người dùng. 

Tuy nhiên, người dùng “mail” có tệp “.bash_history” mà chúng tôi có thể phân tích. Đây là một tập tin ẩn, ký hiệu là “.” tiền tố, ghi nhật ký các lệnh được chạy trong bash shell.

Hình 4.3 – Thư mục chính của người dùng php và mail

Trong Hình 4.3, chúng ta có thể thấy người dùng “mail” chủ yếu sử dụng “sudo su -” để giành quyền truy cập vào quyền root. Với kiến ​​thức này, chúng ta có thể kiểm tra “.bash_history” của người dùng “root” trong hình 4.4, xác nhận rằng tệp “lastlog” đã được sửa đổi và cung cấp cho chúng ta hai tệp mới để kiểm tra, “update.php” và một “.c” tập tin với một tên đáng ngờ.

Nhân vật. 4.4 – .bash_history của người dùng thư

Nhân vật. 4.5 – .bash_history của người dùng root

Khắc / Phục hồi tệp trên ext4

Dựa trên nội dung của .bash_history, chúng tôi nhận thấy rằng có một số tệp đã bị xóa mà chúng tôi muốn khôi phục. Bây giờ, vì chúng ta đang xử lý hệ thống tệp EXT4, điều này có nghĩa là nếu tệp đã bị xóa, thì tất cả siêu dữ liệu trỏ đến vị trí thực của tệp sẽ biến mất. 

Nói cách khác, các con trỏ không còn trỏ đến tệp bên trong ổ đĩa. Do đó, chúng tôi cần một phương pháp khác để khôi phục các tệp đã xóa. Có hai cách tiếp cận để khôi phục dữ liệu, chỉ có một cách được đề cập trong bài viết này còn cách kia vẫn đang được nghiên cứu.

Phương pháp khôi phục của chúng tôi phụ thuộc vào tệp nhật ký EXT4 của hệ thống tệp. Để trích xuất tạp chí, chúng tôi sẽ sử dụng công cụ gỡ lỗi. Tất cả những gì chúng ta cần làm là yêu cầu trình gỡ lỗi thực thi lệnh kết xuất và kết xuất tệp có inode số 8, là inode của nhật ký. Điều này có thể được thực hiện bằng cách sử dụng lệnh sau:

$ Sudo debugfs -R ‘dump <8> ./journal’ /dev/VulnOSv2-vg/root 

Kết quả sẽ được lưu trong một tệp có tên là “tạp chí” và có kích thước 128MB.

Chúng tôi cũng cần xác định cửa sổ tìm kiếm của mình trước khi bắt đầu quá trình khôi phục. Để làm điều đó, chúng ta sẽ tạo hai biến. Dựa trên chi tiết vụ án về thời điểm hoạt động đáng ngờ xảy ra. Một biến được đặt tên là AFTER chứa ngày 5 tháng 10 năm 2019 và một biến được đặt tên TRƯỚC chứa ngày 8 tháng 10 năm 2019, như trong Hình 5.1. 

Hình 5.1 – Xác định thời lượng Tìm kiếm

Bước tiếp theo của chúng tôi là khôi phục các tệp đã xóa. Đối với điều này, chúng tôi sẽ sử dụng công cụ Ext4magic. Sử dụng các biến đã xác định trước đó, chúng tôi sẽ định cấu hình Ext4magic để tìm kiếm các tệp đã bị xóa sau ngày 5 tháng 10 và trước ngày 8 tháng 10, đồng thời sử dụng tệp nhật ký để hỗ trợ việc đó. 

Chúng tôi đã chỉ định nơi chúng tôi muốn lưu trữ kết quả khôi phục của mình (“đầu ra1”) và để tìm kiếm các tệp đã bị xóa khỏi thư mục “tmp”, vì đó là nơi chúng tôi nhận thấy các tệp đã bị xóa khỏi đó. Lệnh được sử dụng có thể được tìm thấy trong Hình 5.2. 

Hình 5.2 – Nỗ lực phục hồi bằng Ext4magic

Chúng ta có thể thấy rằng chỉ có năm tệp được khôi phục từ ổ đĩa bằng lệnh này. Tuy nhiên, chúng ta có thể thử một cách khác. Lần này, chúng ta sẽ sử dụng lại công cụ đó, nhưng cố gắng khôi phục tất cả các tệp đã bị xóa bằng tùy chọn -m thay vì -r và lưu trữ kết quả trong thư mục “output2” như trong Hình 6.3.

Hình 5.3 – Sử dụng Ext4magic để khôi phục tất cả các tệp đã xóa

Như bạn có thể thấy, nhiều tệp đã được khôi phục hơn và giờ đây chúng tôi có thể lướt qua các tệp và phân tích chúng. Chúng ta cũng có thể thấy hệ thống phân cấp gốc cấp cao nhất của hệ thống tệp được phục hồi và lưu trữ trong thư mục đầu ra2 như trong Hình 5.4.

Hình 5.4 – Phân cấp hệ thống tệp của các tệp được khôi phục trong Output2

Bằng cách tìm kiếm thông qua các tệp đã khôi phục trong thư mục “output2”, chúng tôi sẽ có thể xác định vị trí khai thác hạt nhân đã được sử dụng để khai thác hệ thống nhằm giành quyền root.

Tìm hiểu làm thế nào

Từ việc kiểm tra nhật ký, chúng tôi biết rằng tác nhân đe dọa đã không giành được quyền truy cập vào hệ thống bằng cách sử dụng cuộc tấn công vũ phu, điều đó có nghĩa là có một cách khác để chúng có được quyền truy cập vào máy chủ. 

Bây giờ, vì chúng ta biết đây là một máy chủ web, điều quan trọng là phải kiểm tra những ứng dụng web nào đang được sử dụng và liệu có bất kỳ ứng dụng nào dễ bị tấn công hay không. Bằng cách kiểm tra các tệp trong thư mục “/var/www/html”, chúng tôi thấy rằng có một ứng dụng web Drupal đang được sử dụng từ tệp index.php như trong Hình 6.1.

Hình 6.1 – Tên của Ứng dụng Web được sử dụng như đã thấy trong Tệp Chỉ mục

Bây giờ chúng ta cần tìm số phiên bản ứng dụng web Drupal để xem ứng dụng web này có lỗ hổng hay không. Điều này đã được thực hiện bằng cách sử dụng lệnh find với grep như bên dưới:

$ find -type f -exec grep -il version {} \;

Bạn có thể tìm thấy số phiên bản trong tệp có tên bootstrap.inc trong thư mục “./jabc/includes”. Và như chúng ta thấy trong Hình 6.2, máy chủ web đang sử dụng phiên bản Drupal 7.26, phiên bản này dễ bị tấn công bởi CVE-2014-3704 .

Hình 6.2 – Số Phiên bản Drupal được tìm thấy trong Tệp bootstrap.inc

Bây giờ từ CVE, chúng tôi thấy rằng lỗ hổng này đang bị khai thác bằng cách sử dụng yêu cầu POST, điều đó có nghĩa là giờ đây chúng tôi có thể thu hẹp tìm kiếm của mình trong nhật ký Apache để chỉ tìm kiếm các yêu cầu POST và trong một khung thời gian nhất định. 

Bằng cách đó, chúng tôi đã tìm thấy ba yêu cầu POST, như trong Hình 6.3. Chúng tôi nhận thấy rằng có một khối dữ liệu được gửi từ địa chỉ IP đáng ngờ 192.168.210.131 mà chúng tôi đã tìm thấy trước đó.

Hình 6.2 – Yêu cầu POST được tìm thấy trong tệp access.log của Apache

Bây giờ, hãy tập trung vào một trong những yêu cầu POST đó, như trong Hình 6.3, bằng cách sao chép blob vào một tệp và đặt tên là blob.txt.

Hình 6.3 – Khối dữ liệu trong yêu cầu POST

Nếu chúng ta xem xét kỹ dữ liệu, chúng ta có thể thấy rằng nó trông giống như dữ liệu được mã hóa Base64. Điều tốt là chúng ta có thể dễ dàng giải mã nó bằng cách sử dụng lệnh base64 trên Linux, có thể thấy trong Hình 6.4.

Hình 6.4 – Giải mã yêu cầu POST Base64

INếu chúng ta kiểm tra dữ liệu được giải mã một cách cẩn thận, trước tiên chúng ta có thể thấy rằng đó là một tập lệnh php đang thực hiện một số loại hoạt động mạng. Nếu kiểm tra kỹ hơn mã này, chúng ta có thể hiểu rằng đó thực sự là một trình bao đảo ngược được viết bằng PHP và được sử dụng để tạo một ổ cắm TCP nhằm kết nối trở lại địa chỉ IP đáng ngờ của tác nhân đe dọa của chúng ta trên cổng 4444. 

Nếu chúng tôi so sánh dấu thời gian khi tệp này được tải lên máy chủ và khi người dùng được thêm vào máy chủ, chúng tôi có thể xác nhận rằng đây là phương pháp được tác nhân đe dọa sử dụng để có quyền truy cập vào hệ thống.

Một phương pháp khác có thể được sử dụng để xác thực điều này là chạy phân tích dòng thời gian mà chúng tôi sẽ để lại như một bài tập cho người đọc. Tất cả những gì bạn cần làm là chạy hai lệnh bên dưới và sàng lọc dữ liệu.

Tạo dòng thời gian:

$ sudo log2timeline.py -z timezoneValue -t / –parse linux,apache_access,apt_history case1.timeline case1

Sắp xếp và lọc dòng thời gian:

$ sudo psort.py -z timezoneValue -o L2tcsv -w webserver.csv case1.timeline “ngày > ‘2019-10-05 00:00:00’ VÀ ngày < ‘2019-10-08 00:00:00’” 

Điều tra Linux không cần phải quá đáng sợ, ngay cả khi bạn không có kiến ​​thức vững chắc về hệ điều hành. Trong bài viết này, chúng tôi đã hướng dẫn bạn từng bước về cách gắn hình ảnh trường hợp và ánh xạ các ổ của nó trước khi gắn ổ gốc có liên quan. Chúng tôi đã xem qua nhật ký đăng nhập để nhận ra hoạt động đáng ngờ và sử dụng TSK để tìm hiểu điều gì đã xảy ra với tệp nhật ký cuối cùng bị hỏng.

Từ đó, chúng tôi thu thập thông tin về người dùng và các nhóm trong hệ thống. Cuộc điều tra này đã cung cấp cho chúng tôi hai tệp mới để kiểm tra và các tệp đã xóa để khắc và khôi phục, cuối cùng cho thấy cách kẻ tấn công đã khai thác hệ thống.