Cách Secure kho lưu trữ Server Secure

Khi người dùng và quản trị viên SharePoint tại chỗ tải lên một tệp, tệp đó sẽ được quét bằng phần mềm diệt virus của bên thứ ba hoặc các công cụ tương thích với AMSI (chẳng hạn như Microsoft Defender). Nếu tệp vượt qua đợt quét ban đầu đó, nó sẽ được coi là đã được xử lý. Quét sạch một lần, sạch mãi mãi. Chính giả định này chính là lý do khiến các tải trọng phần mềm độc hại và ransomware có thể tồn tại trong kho lưu trữ mà không bị phát hiện; đôi khi kéo dài hàng năm trời.

Microsoft đã khẳng định điều này một cách thẳng thắn: Tính năng bảo vệ chống phần mềm độc hại của SharePoint có thể hạn chế thiệt hại, nhưng không thể đóng vai trò là điểm phòng thủ duy nhất.

Đối với các lĩnh vực BFSI (Ngân hàng, Dịch vụ Tài chính và Bảo hiểm), y tế, chính phủ, cũng như OT (Công nghệ Vận hành) hoặc cơ sở hạ tầng trọng yếu , dữ liệu có nguy cơ bị rò rỉ bao gồm các hồ sơ tuân thủ, hồ sơ bệnh nhân, hồ sơ vụ việc và tài liệu kỹ thuật. Tất cả những dữ liệu này đều được lưu trữ trong một kho dữ liệu ngày càng mở rộng theo từng năm, trong khi không có bất kỳ hoạt động nào được thực hiện để rà soát lại những gì đã có sẵn bên trong.

Những nội dung sau đây tập trung vào ba vấn đề chính: cơ chế hoạt động thực tế của tính năng quét virus trên SharePoint, những gì tính năng này không bao quát, và mô hình bảo mật nhiều lớp, hiệu quả cho kho lưu trữ tệp trên SharePoint nên được thiết kế như thế nào.

Dữ liệu về việc áp dụng công nghệ của Enlyft theo dõi 256.295 doanh nghiệp hiện đang sử dụng Microsoft SharePoint, trải rộng trên các ngành từ dịch vụ CNTT đến ngân hàng, y tế, dầu khí và chính phủ. Các doanh nghiệp này thường có quy mô từ 50 đến 200 nhân viên, với doanh thu từ 1 triệu đến 10 triệu USD.

Chính quy mô này là lý do khiến các kẻ tấn công chú ý và coi các kho lưu trữ SharePoint là những mục tiêu có giá trị cao.

Những điều nêu trên không có nghĩa là SharePoint không bảo mật các máy chủ của mình hay lơ là Bảo mật tập tin. Theo tài liệu của Microsoft, SharePoint Server với hai giao diện quét khả dụng như sau:

• VSAPI (Virus Scanning API) là giao diện tích hợp phần mềm diệt virus cho SharePoint, cho phép các phần mềm diệt virus của bên thứ ba tương thích quét tài liệu trong các thao tác như tải lên và tải xuống.

• AMSI (Antimalware Scan Interface), một khung tích hợp phần mềm chống phần mềm độc hại của Microsoft, cho phép SharePoint Server các tệp đến các công cụ chống vi-rút tương thích với AMSI (chẳng hạn như Microsoft Defender) để quét phần mềm độc hại trong quá trình thực hiện các thao tác nội dung được hỗ trợ.

Server SharePointcó thể được cấu hình để sử dụng VSAPI, AMSI hoặc chế độ tự động. Bất kể tùy chọn nào được thiết lập, chỉ có một công cụ quét duy nhất thực hiện việc quét một tệp tại một thời điểm.

Quá trình quét dựa trên sự kiện và được kích hoạt khi người dùng tải lên hoặc tải xuống tài liệu, chứ không phải theo cách hồi tố hay định kỳ. Chỉ có một công cụ ( Microsoft Malware Protection Engine, thường được gọi là MpEngine.dll) thực hiện việc kiểm tra tệp.

Điểm chính cần lưu ý: Các tệp được quét bằng một công cụ duy nhất, tại thời điểm tải lên hoặc tải xuống, bằng cách sử dụng các bản dấu và khả năng phát hiện hiện tại của công cụ đó.

Phương pháp này không được thiết kế để phát hiện các mối đe dọa lây lan qua tệp tin được tạo ra với mục đích cụ thể là lách qua cơ chế phát hiện của công cụ đó. Đặc biệt, các mối đe dọa dai dẳng nâng cao (APT) thường khai thác chính hạn chế này, khiến chúng ẩn náu mà không bị phát hiện trong thời gian dài.

Sự kiên trì đó đã mở ra cơ hội cho những kẻ tấn công lợi dụng nội dung SharePoint đáng tin cậy để thực hiện các hành vi độc hại. Đã có những vụ tấn công được ghi nhận, trong đó các tác nhân đe dọa đã lạm dụng các trang SharePoint bị xâm nhập để đăng tải các tài liệu lừa đảo và các liên kết độc hại.

Một lỗ hổng zero-day sẽ vượt qua quá trình quét giống như một tệp an toàn, đơn giản vì chưa có công cụ quét nào phát hiện ra nó. Và do SharePoint không quét lại nội dung hiện có sau này, nên một tệp chứa lỗ hổng zero-day đã vượt qua kiểm tra vào ngày đầu tiên sẽ không bị kiểm tra lại vào ngày thứ hai trăm, ngay cả khi nhà cung cấp đã phát hành bản cập nhật chữ ký có thể phát hiện ra nó.

Các mối đe dọa chưa được xác định cũng tuân theo logic tương tự. Do không có chữ ký đi kèm, phương pháp phân tích tĩnh (cách thức hoạt động của các công cụ chống vi-rút) không thể phát hiện được mối đe dọa này.

Lưu ý: đây là những hạn chế về phạm vi chứ không phải là lỗi. Tính năng chống vi-rút tích hợp sẵn Server SharePoint Server được thiết kế để thực hiện các cuộc kiểm tra tại một thời điểm cụ thể ở các điểm tương tác nhất định, chứ không phải để liên tục xác thực lại một kho lưu trữ đang ngày càng mở rộng và có nhiều phiên bản trước bối cảnh các mối đe dọa không ngừng thay đổi.

Vào tháng 7 năm 2025, Microsoft đã công bố việc khai thác tích cực một chuỗi lỗ hổng cho phép thực thi mã từ xa mà không cần xác thực, ảnh hưởng đến Server SharePoint tại chỗ: CVE-2025-49706, CVE-2025-49704, sau đó được bổ sung bởi CVE-2025-53770 và CVE-2025-53771. Lỗ hổng này không yêu cầu thông tin đăng nhập hoặc tài khoản để khai thác.

Sau đó, Microsoft đã vá lỗ hổng này, và chuỗi khai thác này được đặt tên là: ToolShell.

Theo phân tích của Eye Security, được tạp chí Infosecurity Magazine trích dẫn, đã phát hiện 396 hệ thống bị xâm nhập tại 145 tổ chức ở 41 quốc gia. Khu vực chính phủ chịu ảnh hưởng nặng nề nhất, chiếm 30% số trường hợp nhiễm mã độc đã được xác nhận, và riêng Hoa Kỳ đã chiếm 31% tổng số. Bên cạnh đó, Shadowserver Foundation báo cáo rằng hơn 10.700 phiên bản SharePoint vẫn bị lộ, bất kỳ ai chạy cùng chuỗi khai thác lỗ hổng này đều có thể truy cập được, ngay cả sau khi lỗ hổng này – vốn đã khiến hàng trăm tổ chức bị xâm nhập – được công bố rộng rãi. Storm-2603, một trong những nhóm đứng sau vụ khai thác này, đã biến lỗ hổng đó thành một tải trọng ransomware Warlock.

Sau khi xâm nhập thành công, Storm-2603 đã sử dụng thông tin đăng nhập bị đánh cắp cùng các công cụ quản trị hợp pháp để di chuyển ngang qua các hệ thống. Hoạt động di chuyển này không gây ra bất kỳ cảnh báo nào, vì nó dựa vào các công cụ vốn được cho là phải có sẵn tại đó. Storm-2603 đã cài đặt các web shell và trích xuất dữ liệu quan trọng. Chúng vẫn duy trì quyền truy cập ngay cả sau khi lỗ hổng đã được vá, bởi vì những kẻ tấn công đã đánh cắp các khóa cần thiết để giả mạo các mã thông báo xác thực hợp lệ.

ToolShell được xây dựng dựa trên bốn lỗ hổng CVE được kết hợp với nhau, với các cơ chế vượt qua bản vá được tích hợp sẵn ngay từ đầu. Các lỗ hổng CVE-2025-53770 và -53771 xuất hiện chính xác là do các bản vá ban đầu cho CVE-2025-49704 và -49706 có thể bị vượt qua.

Điều thực sự quan trọng là kẻ tấn công đã thích ứng nhanh hơn chu kỳ vá lỗi tới hai lần, trên cùng một mục tiêu, chỉ trong vòng vài tuần.

Các biện pháp kiểm soát tĩnh như phần mềm chống vi-rút (AV) đơn lẻ chỉ quét tệp một lần dựa trên các chữ ký của một nhà cung cấp duy nhất vốn dĩ không bao giờ được thiết kế để phát hiện chuỗi khai thác lỗ hổng phía máy chủ ngay từ đầu. Hơn nữa, chúng cũng không thể bảo vệ hệ thống trước một kẻ tấn công quay lại sau khi bản vá được triển khai với phương thức vượt qua bản vá đó.

ToolShell cho thấy mức độ tinh vi hiện nay đang nhắm mục tiêu cụ thể vào các máy chủ SharePoint. Không có lý do gì để cho rằng đây là lần cuối cùng một lỗ hổng như vậy xảy ra. Liệu dữ liệu lưu trữ trên các máy chủ này có được bảo vệ bởi một giải pháp được thiết kế để luôn cập nhật kịp thời, hay chỉ bằng một cuộc quét kiểm tra một lần rồi coi như xong?

Nói công bằng, ToolShell không phải là một tài liệu độc hại lọt qua quá trình quét tệp tải lên. Nhưng web shell (spinstall0.aspx và các biến thể đã được đổi tên của nó) mà những kẻ tấn công cài đặt? Đó mới là một tệp. Tệp này tồn tại trên máy chủ và việc nó có bị phát hiện hay không phụ thuộc vào những hạn chế đã được đề cập trước đó: chỉ có một công cụ quét, kiểm tra một lần, tại một thời điểm duy nhất.

Đó chính là cơ chế liên kết sự cố này với luận điểm rộng hơn. Việc vá lỗi sẽ ngăn chặn cụ thể chuỗi khai thác lỗ hổng ToolShell. Tuy nhiên, nó không có tác dụng gì đối với tệp tiếp theo chưa được quét mà đã có sẵn trong kho lưu trữ.

Những điều nêu trên không có ý nghĩa gì nhiều đối với nội dung vẫn chưa được xử lý kể từ năm 2023, trừ khi nội dung đó thực sự được quét.

Đây là cấp độ mà phần mềm diệt virus tích hợp sẵn của SharePoint không thể hỗ trợ: việc kiểm tra lại nội dung đã lưu trữ — bao gồm cả các phiên bản cũ được lưu giữ qua lịch sử phiên bản — theo định kỳ hoặc liên tục, thay vì chỉ thực hiện khi tải lên hoặc tải xuống. Việc quét lại theo thời gian thực, theo lịch trình và theo yêu cầu sẽ khắc phục lỗ hổng này, bằng cách kiểm tra định kỳ các tệp khi cơ sở dữ liệu được cập nhật.

Xét riêng lẻ, mỗi biện pháp kiểm soát này đều khắc phục một lỗ hổng cụ thể đã được đề cập trước đó. Khi kết hợp lại, chúng tạo thành hệ thống phòng thủ nhiều lớp mà chính tài liệu của Microsoft đã nhấn mạnh khi khẳng định rằng phần mềm diệt virus tích hợp không được thiết kế để trở thành điểm phòng thủ duy nhất.

Storage Security MetaDefender có thể được triển khai thông qua nhiều mô hình khác nhau: máy chủ vật lý để cài đặt trực tiếp trên phần cứng, các nền tảng ảo hóa (tương thích với VMware, Hyper-V và XenServer), dịch vụ IaaS (Cơ sở hạ tầng như một dịch vụ) từ các nhà cung cấp đám mây hàng đầu, hoặc thông qua các triển khai dạng container trong các cụm Kubernetes.

Danh sách kiểm tra này được xây dựng dựa trên hướng dẫn của CISA về lỗ hổng ToolShell.

1. Xác nhận trạng thái bản vá.

Tất cả các lỗ hổng CVE bị khai thác đều đã có bản cập nhật bảo mật, nhưng các máy chủ chưa được vá lỗi vẫn có nguy cơ bị tấn công bởi ToolShell. Hãy cài đặt các bản cập nhật bảo mật của Microsoft cho tất cả Server SharePoint Server bị ảnh hưởng.

2. Kiểm tra xem AMSI đã được cấu hình chưa.

Việc triển khai AMSI nhưng cấu hình sai sẽ để lại lỗ hổng tương tự như việc hoàn toàn không có AMSI. Hãy xác nhận rằng tính năng tích hợp AMSI đã được bật và giải pháp chống vi-rút đã được triển khai trên mọi máy chủ SharePoint.

3. Xoay vòng các khóa máy ASP.NET

Các khóa máy bị đánh cắp cho phép kẻ tấn công tạo ra các mã thông báo xác thực hợp lệ ngay cả sau khi máy chủ đã được vá lỗi. Chỉ vá lỗi thôi không đủ để vô hiệu hóa các khóa đã bị đánh cắp. Hãy thay đổi khóa máy, áp dụng bản cập nhật bảo mật, sau đó thay đổi khóa máy một lần nữa. Khởi động lại IIS bằng lệnh iisreset.exe sau mỗi lần thay đổi khóa để xóa các mục độc hại khỏi các tệp applicationHost.config và web.config.

4. Kiểm tra thủ công để tìm các dấu hiệu cho thấy hệ thống đã từng bị xâm nhập trước đó.

CISA lưu ý rằng các tải trọng .dll được sử dụng trong chiến dịch này có thể được dùng để lấy cắp khóa hệ thống. Việc vá lỗ hổng không loại bỏ được tải trọng đã được cài đặt sẵn trên máy chủ. Cần kiểm tra các hệ thống và các tệp cụ thể để phát hiện các chỉ số xâm nhập ( IOCs ), chứ không chỉ tập trung vào chính lỗ hổng đó.

5. Kiểm tra xem có phiên bản đã hết vòng đời hoặc hết thời hạn hỗ trợ hay không.

Một số phiên bản SharePoint đã hết vòng đời (EOL) và sẽ không còn nhận được các bản cập nhật bảo mật nào nữa, bất kể có hoạt động khai thác lỗ hổng hay không. Hãy kiểm tra xem các phiên bản mà công ty bạn đang sử dụng có còn được hỗ trợ hay không. Nếu không, hãy thực hiện các biện pháp cần thiết.

6. Kiểm tra nhật ký để tìm các dấu hiệu đã biết

CISA đã xác định các mẫu yêu cầu cụ thể và các địa chỉ IP có liên quan đến chiến dịch này. Hãy tìm kiếm trong nhật ký các yêu cầu trùng khớp với các thông tin tham chiếu của CISA.

7. Kiểm tra các quyền quản trị và quyền thiết kế giao diện.

Để hạn chế mức độ thiệt hại, hãy rà soát xem ai đang nắm giữ quyền quản trị bố cục và quyền quản trị trên SharePoint, đồng thời thu hồi các quyền truy cập không thực sự cần thiết.

8. Đánh giá những gì đã được lưu trữ, chứ không chỉ những gì hiện đang được hiển thị

Tất cả những nội dung nêu trên đều liên quan đến chính chuỗi khai thác lỗ hổng. Không có nội dung nào trong số đó đánh giá nội dung hiện có trong các thư viện tài liệu, bao gồm cả các tệp được tạo ra trước khi các bản vá này được phát hành.

Xác định xem nội dung hiện có trong kho lưu trữ đã được quét lại hay chưa kể từ khi có các bản vá và bản cập nhật chữ ký liên quan, hay vẫn còn giữ kết quả quét ban đầu, có thể đã lỗi thời.