Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã Base64
Cách giải mã lệnh Base64 PowerShell đáng ngờ mà không cần chạy nó
· Tại sao nó quan trọng
base64 bảo vệ
Những kẻ tấn công sử dụng Base64 để ẩn các tập lệnh khỏi việc kiểm tra thông thường. Bài đăng này cho biết cách giải mã tải trọng -EncodedCommand mà không thực thi nó, tại sao đầu ra có thể trông kỳ lạ trong bộ giải mã UTF-8 và những điều cần tìm.
Tác vụ đã lên lịch với đối số gồm 2,000 ký tự — nơi các lệnh được mã hóa xuất hiện và tại sao chúng là cờ đỏ
Quản trị viên hệ thống phát hiện một tác vụ đã lên lịch có đối số 2,000 ký tự -EncodedCommand có vẻ đáng ngờ. Tác vụ chạy trong tài khoản dịch vụ với đặc quyền cao.
Việc dán lệnh vào PowerShell và chạy nó để xem nó làm gì là rất nguy hiểm; nếu lệnh độc hại thì việc thực thi nó sẽ làm tổn hại đến hệ thống. Cách tiếp cận an toàn hơn là giải mã Base64 cục bộ và đọc kết quả đầu ra dưới dạng văn bản trước khi quyết định có chạy bất cứ thứ gì hay không. Bài đăng này giải thích cách giải mã các lệnh PowerShell một cách an toàn mà không cần thực thi chúng, tại sao đầu ra có thể trông bị cắt xén trong bộ giải mã UTF-8 tiêu chuẩn và những điều cần tìm để đánh giá xem một lệnh có an toàn hay đáng ngờ hay không.
Giải mã, không bao giờ thực thi — quy tắc giúp phân tích an toàn và tại sao bộ giải mã chỉ dành cho trình duyệt lại phù hợp
Thông tin chi tiết quan trọng là PowerShell sử dụng mã hóa UTF-16LE cho -EncodedCommand chứ không phải UTF-8, vì vậy mọi byte khác đều là số 0 mà các công cụ tiêu chuẩn hiểu là dấu kết thúc rỗng. Quy tắc phân tích bất kỳ mã đáng ngờ nào rất đơn giản: giải mã, không bao giờ thực thi. Điều này áp dụng cho các lệnh được mã hóa Base64, tập lệnh nén, tập lệnh từ các nguồn không đáng tin cậy và bất kỳ thứ gì trong chuỗi mã hóa không quen thuộc. Việc thực thi một tập lệnh là không thể quay lại; khi nó chạy, các thay đổi đối với hệ thống đã xảy ra, quyền truy cập đã được cấp và dữ liệu đã được lọc.
Việc giải mã và đọc tập lệnh dưới dạng văn bản cho phép bạn đánh giá tập lệnh trước bước không thể hoàn tác. Quy tắc thứ hai là sử dụng một công cụ chạy cục bộ và không đưa ra yêu cầu mạng nào. Bộ giải mã dựa trên trình duyệt là lý tưởng vì nó có tính di động, không yêu cầu phần mềm bổ sung và giữ tải trọng đáng ngờ trên thiết bị của bạn mà không cần tải nó lên bất kỳ máy chủ nào. Nếu công cụ này thuộc loại đăng lên dịch vụ giải mã từ xa, thì đừng sử dụng nó; tải trọng sau đó được tiếp xúc với dịch vụ đó. Tham số PowerShell -EncodedCommand chấp nhận chuỗi Base64 mà khi được giải mã sẽ chứa tập lệnh PowerShell.
Tại sao các byte được giải mã trông không giống văn bản UTF-8 — hãy kiểm tra mẫu byte UTF-16LE ở dạng hex thay vì yêu cầu công cụ văn bản UTF-8 này diễn giải nó
Tuy nhiên, PowerShell không sử dụng mã hóa UTF-8 cho việc này; nó sử dụng UTF-16LE (endian nhỏ UTF-16). Trong UTF-16, mỗi ký tự ASCII được biểu diễn dưới dạng hai byte: mã ký tự theo sau là byte 0. Chữ A có 41 00 ở dạng hex. Chữ B là 42 00. Một chuỗi như Hello xuất hiện dưới dạng 48 00 65 00 6C 00 6C 00 6F 00 tính bằng UTF-16LE byte. Khi đây được mã hóa Base64, kết quả sẽ chứa dạng được mã hóa của tất cả các byte đó, bao gồm tất cả các số 0. Giải mã bằng bộ giải mã UTF-8 tiêu chuẩn sẽ tạo ra văn bản bị cắt xén hoặc bị cắt bớt ở byte 0 đầu tiên vì UTF-8 coi byte rỗng là dấu kết thúc chuỗi.
Kết quả đầu ra trông giống H e l o thay vì Hello, với các ký tự dường như ngẫu nhiên hoặc thiếu văn bản. Một ví dụ hoạt động cho thấy vấn đề và giải pháp. Giả sử lệnh PowerShell mã hóa chuỗi đơn giản Write-Host Hello. PowerShell UTF-16LE-mã hóa giá trị này thành byte bao gồm tất cả các số 0, Base64 mã hóa các byte và tạo ra một chuỗi dài như VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA. Sao chép chuỗi này vào bộ mã hóa & giải mã Base64 trong trình duyệt của bạn và nhấp vào Giải mã. Bộ giải mã mặc định sẽ cố gắng diễn giải kết quả dưới dạng văn bản UTF-8 và tạo ra kết quả bị hỏng hoặc bị cắt bớt do các số 0 được nhúng.
Ví dụ đã hoạt động: giải mã một lệnh được mã hóa mẫu vô hại - đọc văn bản qua các byte 0 được xen kẽ
Giải pháp là sử dụng chế độ xem hex để thay thế. Chuyển sang chế độ xem hex và bạn thấy các byte: 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00. Đọc các byte đó dưới dạng cặp UTF-16LE mang lại W-r-i-t-e---K-o-s-h---H-e-l-l-o-. Với kinh nghiệm, bạn có thể đọc trực tiếp UTF-16LE hex hoặc bạn có thể ghi byte vào một tệp và giải mã chúng bằng tập lệnh PowerShell hoặc Python chạy cục bộ.
Cách tiếp cận thực tế là lưu ý mẫu và nhớ rằng PowerShell sử dụng UTF-16LE. Khi bạn giải mã PowerShell -EncodedCommand trong trình duyệt và kết quả đầu ra có vẻ sai, hãy xem chế độ xem hex thay vì chế độ xem văn bản. Chế độ xem hex hiển thị từng byte riêng lẻ. Mỗi ký tự ASCII xuất hiện dưới dạng hai byte với số 0 ở giữa. Nếu các byte phát ra các lệnh độc hại như New-AdminAccount, đảo ngược tra cứu dns hoặc xuất thông tin xác thực bảo mật thì lệnh đó đáng ngờ. Nếu các byte đánh vần thứ gì đó vô hại như danh sách thư mục hoặc một tập lệnh đơn giản, thì lệnh đó có thể là vô hại.
Mã hóa và nén lồng nhau — Base64 bên trong Base64 và các luồng gzip mà bạn không thể đọc dưới dạng văn bản
Chế độ xem hex khó đọc hơn văn bản thuần túy nhưng an toàn hơn so với việc đoán từ đầu ra UTF-8 bị hỏng. Mã hóa và nén lồng nhau làm tăng thêm độ phức tạp cho việc phân tích phần mềm độc hại. Lệnh PowerShell có thể mã hóa Base64 một chuỗi Base64 khác hoặc nén tập lệnh bằng gzip rồi mã hóa Base64 kết quả. Trong kịch bản lồng nhau, bạn giải mã Base64 bên ngoài, đọc kết quả và phát hiện ra chính nó là base64. Giải mã nó và tiếp tục cho đến khi bạn tìm thấy văn bản có thể đọc được hoặc định dạng nhị phân mà bạn không thể diễn giải. Gzip và các định dạng nén khác bắt đầu bằng byte ma thuật (1F 8B cho gzip) hiển thị trong chế độ xem hex.
Nếu bạn giải mã Base64 và chế độ xem hex bắt đầu bằng 1F 8B thì byte là luồng nén yêu cầu giải nén. Bộ mã hóa và giải mã Base64 hiển thị cho bạn mã hex, giúp bạn xác định các mẫu này mà không cần thực hiện bất kỳ điều gì. Các tải trọng được nén hoặc mã hóa sâu hơn rất đáng ngờ vì chúng thêm các lớp làm rối mã nguồn.
Nội dung cần ghi lại cho báo cáo sự cố — văn bản được giải mã, nguồn và nội dung băm thay vì chính tải trọng
Các lệnh hợp pháp hiếm khi yêu cầu nhiều bước mã hóa. Việc ghi lại các phát hiện để báo cáo sự cố đòi hỏi tính kỷ luật và chính xác. Viết lại chuỗi Base64 chính xác mà bạn đã phân tích, bạn tìm thấy nó ở đâu và khi nào. Nếu bạn đã giải mã nó và tìm thấy các lệnh đáng ngờ, hãy mô tả các lệnh đó nhưng chưa đưa toàn bộ tập lệnh vào báo cáo; kịch bản có thể phức tạp hoặc dài.
Bao gồm hàm băm (SHA-256) của tập lệnh được giải mã để có thể xác minh và theo dõi phát hiện. Nếu lệnh rõ ràng là độc hại hoặc sử dụng các kỹ thuật khai thác đã biết, hãy liên hệ với các nhóm bảo mật và ứng phó sự cố trước khi thực hiện bất kỳ hành động nào. Đừng bao giờ tự mình thực hiện lệnh để xem nó làm gì. Nếu người ứng phó sự cố cần thực thi nó để thử nghiệm, họ sẽ thực hiện việc đó trong môi trường hộp cát nơi chứa mọi hư hỏng. Công việc của bạn là giải mã và đánh giá rủi ro ở khoảng cách an toàn. Bài viết này không đề cập đến toàn bộ phạm vi phân tích phần mềm độc hại, môi trường hộp cát hoặc phân bổ tấn công.
Điều này không bao gồm - thực thi hộp cát, công cụ phân tích phần mềm độc hại và phân bổ
Đó là những chủ đề dành cho các chuyên gia bảo mật và đội ứng phó sự cố. Phạm vi ở đây tập trung hẹp vào việc giải mã một cách an toàn lệnh PowerShell được mã hóa mà không cần thực thi lệnh đó, vì vậy bạn có thể đọc tập lệnh và đánh giá xem liệu lệnh đó có đáng để nghiên cứu thêm hay không. Mã hóa Base64 là làm xáo trộn chứ không phải bảo vệ. Bất kỳ ai có bộ mã hóa và bộ giải mã đều có thể trích xuất tập lệnh. Những kẻ tấn công sử dụng Base64 để tránh bị phát hiện cơ bản và ngăn chặn việc kiểm tra ngẫu nhiên, chứ không phải để che giấu ý định phân tích của chúng. Lệnh PowerShell được giải mã nhằm tìm nạp và thực thi tập lệnh từ xa là độc hại cho dù bạn tự giải mã tập lệnh đó hay sử dụng công cụ bảo mật.
Bước thực tế tiếp theo sau khi giải mã một lệnh đáng ngờ là báo cáo lệnh đó cho nhóm thích hợp. Nếu đó là hệ thống của riêng bạn, hãy xác định xem nhiệm vụ đó có được cố ý tạo ra hay không và bởi ai. Kiểm tra ngày tạo và tài khoản đã lên lịch cho nó. Nếu tác vụ không được ủy quyền, hãy vô hiệu hóa nó, lưu giữ thông tin chi tiết để điều tra và điều tra cách kẻ tấn công giành được đặc quyền để tạo tác vụ đó. Nếu lệnh chứa các yêu cầu mạng hoặc cơ chế lưu giữ lâu dài như thay đổi sổ đăng ký hoặc tạo tác vụ theo lịch trình thì gần như chắc chắn lệnh đó là độc hại.
Bài học rút ra: Base64 là chức năng che giấu chứ không phải bảo vệ - cách bộ mã hóa & giải mã Base64 giải mã tải trọng cục bộ mà không cần rời khỏi máy của bạn
Nếu nó thực hiện các chức năng quản trị hợp pháp và các chi tiết tạo là bình thường thì đó có thể là một tập lệnh quản trị hợp pháp được mã hóa vì những lý do liên quan đến chính sách bảo mật hoặc tích hợp với một công cụ tự động hóa lớn hơn. Đừng thực hiện nó theo một trong hai cách; hãy để đánh giá của bạn về văn bản được giải mã đưa ra quyết định của bạn. Việc giải mã an toàn các lệnh Base64 PowerShell đáng ngờ tuân theo một quy trình đơn giản. Sử dụng bộ mã hóa & giải mã Base64 để giải mã chuỗi mà không cần tải lên hoặc thực thi bất cứ điều gì. Nhìn vào chế độ xem hex để hiểu byte đại diện cho điều gì.
Nếu bạn thấy các mẫu UTF-16LE (các byte 0 xen kẽ), hãy nhớ rằng PowerShell sử dụng UTF-16LE và đọc tương ứng. Xác định bất kỳ mẫu đáng ngờ nào như yêu cầu mạng, cơ chế nâng cao đặc quyền hoặc duy trì. Ghi lại chi tiết chính xác cho báo cáo sự cố của bạn, bao gồm chuỗi Base64 ban đầu và hàm băm của nó. Đừng bao giờ tự mình thực hiện lệnh; hãy để việc đó cho những người ứng phó sự cố trong một môi trường được kiểm soát. Hãy tin tưởng vào khả năng giải mã cục bộ và đánh giá của bạn về bản rõ và để điều đó hướng dẫn hành động tiếp theo của bạn.