Tiết lộ đầy đủ: Đã tìm thấy Log Bypass đăng nhập Azure lần thứ ba (và thứ tư)

Nyxgeek đây. Năm 2026 và tôi có thêm hai phương pháp bỏ qua nhật ký đăng nhập Azure Entra ID để chia sẻ với bạn. Đừng quá phấn khích…những bypass này gần đây đã được sửa nhưng tôi nghĩ điều quan trọng là mọi người phải biết.

Bằng cách gửi nỗ lực đăng nhập được tạo đặc biệt tới điểm cuối xác thực Azure, có thể truy xuất mã thông báo hợp lệ mà không cần hoạt động xuất hiện trong nhật ký đăng nhập Entra ID. Đây là tính năng ghi nhật ký quan trọng…ghi nhật ký mà quản trị viên trên toàn thế giới dựa vào để phát hiện hành vi xâm nhập…ghi nhật ký có thể được thực hiện tùy chọn.

Hôm nay, tôi sẽ hướng dẫn bạn cách bỏ qua nhật ký đăng nhập Azure thứ ba và thứ tư mà tôi đã tìm thấy trong ba năm qua. Tôi cũng sẽ xem xét cách có thể phát hiện việc bỏ qua nhật ký đăng nhập bằng truy vấn KQL. Khi biết về những sai lầm trong quá khứ của Microsoft, chúng tôi có thể cố gắng chuẩn bị cho những thất bại trong tương lai của họ.

Nền tảng

Kể từ năm 2023, tôi đã phát hiện ra bốn cách vượt qua nhật ký đăng nhập Azure Entra ID. Điều này có nghĩa là tôi đã tìm thấy bốn cách hoàn toàn khác nhau để xác thực mật khẩu của tài khoản Azure mà mật khẩu đó không hiển thị trong nhật ký đăng nhập Azure Entra ID. Mặc dù hai bước đầu tiên trong số này chỉ xác nhận xem mật khẩu có hợp lệ hay không mà không cần tạo nhật ký, nhưng các bước bỏ qua ghi nhật ký mới nhất của tôi đã trả lại các mã thông báo hoạt động đầy đủ.

Trước đây, tôi đã viết về GraphNinja và GraphGhost -- hai lần bỏ qua ghi nhật ký trong đó người dùng có thể xác định mật khẩu hợp lệ mà không tạo ra bất kỳ sự kiện 'thành công' nào trong nhật ký đăng nhập. Cả hai đều không quá phức tạp. Bạn có thể tìm thấy các bài đăng blog mô tả chi tiết về chúng tại đây và tại đây.

Thật nhanh -- một điểm cần làm rõ về các tên: mặc dù tôi đã sử dụng tiền tố Graph- để chỉ định các đường vòng khác nhau này, nhưng có lẽ sẽ thích hợp hơn nếu đặt tiền tố Entra- cho chúng, vì chúng không bị giới hạn chỉ ở các lần đăng nhập vào Graph.

Trong mỗi đường dẫn này, việc ghi nhật ký bị bỏ qua là dành cho nhật ký đăng nhập Azure Entra ID. Phương thức đăng nhập là thông qua HTTP POST tới điểm cuối mã thông báo Entra ID, login.microsoftonline.com, sử dụng luồng ROPC OAuth2, với API Đồ thị làm tài nguyên/phạm vi dự định của chúng tôi. Chúng tôi gửi tên người dùng và mật khẩu, ID ứng dụng cũng như tài nguyên/phạm vi mục tiêu và đổi lại chúng tôi sẽ nhận được mã thông báo mang hoặc mã thông báo làm mới cho API Đồ thị.

Bạn có thể xem ví dụ về lệnh curl thực hiện xác thực "thông thường" bên dưới:

 cuộn tròn -X BÀI ĐĂNG "https://login.microsoftonline.com/00000000-1234-1234-1234-0000000000000/oauth2/v2.0/token" \
  -H "Loại nội dung: application/x-www-form-urlencoded" \
  --data-urlencode "client_id=f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" \
  --data-urlencode "client_info=1" \
  --data-urlencode "grant_type=password" \
  --data-urlencode "[email được bảo vệ] " \
  --data-urlencode "password=secretpassword123" \
  --data-urlencode "scope=https://graph.microsoft.com/.default"

Khi tên người dùng và mật khẩu hợp lệ được cung cấp, mã thông báo sẽ được trả về để có thể sử dụng để truy cập API Đồ thị.

Bản tóm tắt GraphNinja

Trong bước bỏ qua GraphNinja, bạn chỉ cần nhắm mục tiêu một đối tượng thuê khác bằng nỗ lực xác thực (ví dụ: https://login.microsoftonline.com/00000000-1234-1234-1234-000000000000/oauth2/v2.0/token). Bất kỳ GUID đối tượng thuê hợp lệ nào khác cũng được, miễn là đó không phải của nạn nhân của bạn. Phản hồi xác thực vẫn sẽ cho biết liệu mật khẩu hợp lệ có được tìm thấy hay không, nhưng quá trình đăng nhập sẽ không thành công vì nó được thực hiện đối với người thuê nước ngoài nơi người dùng không tồn tại. Không có nhật ký xác thực thành công hoặc thất bại nào được tạo trong đối tượng thuê chính của người dùng thực tế vì xác thực đang nhắm mục tiêu đối tượng thuê nước ngoài. Không có nhật ký nào được tạo trên đối tượng thuê nước ngoài vì chỉ tạo nhật ký cho người dùng hợp lệ trong đối tượng thuê đó và người dùng mục tiêu không tồn tại trong đối tượng thuê nước ngoài. Mặc dù GraphNinja không trả lại mã thông báo nào, nhưng nó sẽ cho kẻ tấn công biết liệu mật khẩu có hợp lệ hay không khi nỗ lực xuất hiện trong nhật ký. Microsoft đã thêm tính năng ghi nhật ký bổ sung để khắc phục tình trạng giám sát này.

Bản tóm tắt GraphGhost

Với tính năng bỏ qua GraphGhost, việc cung cấp giá trị ID khách hàng không hợp lệ sẽ khiến quy trình xác thực tổng thể không thành công, nhưng phải đến sau khi quá trình xác thực thông tin xác thực đã diễn ra. Bằng cách cung cấp giá trị không hợp lệ cho ID khách hàng, bước xác thực sau mật khẩu sẽ không thành công, quy trình xác thực tổng thể sẽ không thành công và điều này sẽ hiển thị cho quản trị viên là thông tin đăng nhập không thành công, không có dấu hiệu nào trong nhật ký cho thấy mật khẩu đã được đoán thành công. Giống như GraphNinja, không có mã thông báo nào được trả lại nhưng mật khẩu đã được xác thực mà không có bất kỳ dấu hiệu nào cho quản trị viên. Sự cố này đã được Microsoft khắc phục bằng việc bổ sung các chi tiết trong nhật ký đăng nhập để cho biết mật khẩu có thành công hay không.

Bây giờ bạn đã nắm bắt được những gì đã được tìm thấy trong năm 2023 và 2024, hãy xem những phát hiện từ năm 2025.

Nhập GraphGoblin và Graph******

GraphGoblin Bypass

Hãy bắt đầu với những gì tôi đang gọi là GraphGoblin. Tôi tình cờ phát hiện ra đường vòng này khi xem xét các tham số trong POST xác thực của Microsoft. Khi kiểm tra tham số scope, lần đầu tiên tôi thử một số thao tác đơn giản như cung cấp các giá trị phạm vi không hợp lệ. Tuy nhiên, tôi nhận thấy rằng giá trị phạm vi sẽ bị từ chối nếu đó không phải là tên phạm vi hợp lệ hoặc không khớp với định dạng mong muốn.

Phạm vi không hợp lệ trả về lỗi:

AADSTS70011: Yêu cầu được cung cấp phải bao gồm tham số đầu vào 'phạm vi'. Giá trị được cung cấp cho tham số đầu vào 'scope' không hợp lệ. Phạm vi [phạm vi] không hợp lệ. Định dạng phạm vi không hợp lệ. Phạm vi phải ở dạng URI hợp lệ hoặc Hướng dẫn hợp lệ.

Thông báo lỗi này không trung thực 100%. Bạn cũng có thể chỉ định phạm vi cụ thể, chẳng hạn như openid hoặc Directory.Read.All. Nếu định dạng URL hoặc GUID được sử dụng, nó sẽ xác thực tài nguyên đang được nhắm mục tiêu và sau đó là phạm vi. Việc xác thực các giá trị phạm vi này đã ngăn việc đánh giá các chuỗi dài tùy ý.

Hay là vậy? Điều gì sẽ xảy ra nếu chuỗi chúng tôi gửi CÓ hợp lệ nhưng lặp lại? Ví dụ: thay vì chỉ định một giá trị như openid làm phạm vi, điều gì sẽ xảy ra nếu chúng ta gửi một loạt giá trị giống nhau, như openid openid openid?

Nó đã vượt qua! Nhưng nó có hiệu quả trong việc bỏ qua nhật ký không? Tôi đã đặt báo thức trong 15 phút, quay lại và kiểm tra nhật ký đăng nhập Azure Entra ID và không tìm thấy ĐĂNG NHẬP MỚI nào! Tệ quá! Tôi đợi thêm 15 phút nữa trước khi thực sự ăn mừng. Sau đó, tôi đã thử nghiệm nó với người thuê nhà của một người bạn để chắc chắn. Đó là một đường vòng vững chắc.

Để cho thấy việc này cực kỳ đơn giản, bạn có thể xem phần trình diễn về đường vòng này bằng cách sử dụng curl và mở rộng Bash bên dưới:

 xuất TENANT_ID="[tenant-guid-goes-here]"
cuộn tròn -X BÀI ĐĂNG "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \
  -H "Loại nội dung: application/x-www-form-urlencoded" \
  --data-urlencode "client_id=f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" \
  --data-urlencode "client_info=1" \
  --data-urlencode "grant_type=password" \
  --data-urlencode " [email được bảo vệ]" \
  --data-urlencode "password=secretpassword123" \
  --data-urlencode "scope=$(for num in {1..10000}; do echo -n 'openid ';done)"

Tại sao nó hoạt động (Có thể)

Không có cách nào để biết 100% lý do tại sao điều này hoạt động mà không cần Microsoft công bố thông tin về những vấn đề này, nhưng tôi có thể đoán.

Sau khi thực hiện khá nhiều thao tác ghi nhật ký vào cơ sở dữ liệu bằng nhiều tập lệnh khác nhau, tôi tin rằng đây chỉ là một vấn đề đơn giản khi vượt quá độ dài cột SQL cho một trường, khiến toàn bộ INSERT không thành công. Đây là một lỗi phổ biến dành cho người mới bắt đầu khi bạn mới bắt đầu làm việc với cơ sở dữ liệu.

Có thể trình phân tích cú pháp đã lặp lại danh sách các phạm vi được bao gồm, không tìm thấy bất kỳ phạm vi nào không hợp lệ và do đó đã cho phép mục nhập lặp lại vượt qua và cố gắng ghi lại danh sách thô của openid openid openid…, toàn bộ, vượt quá giới hạn của cột SQL đó. Trong thử nghiệm, độ dài tối đa hợp lý có thể được coi là tổng độ dài của tất cả các tên phạm vi có thể có. Có lẽ họ đã thử nghiệm kịch bản đó nhưng không bao giờ lường trước được việc lặp lại. Dù sao đi nữa, nếu đúng như vậy thì họ đã không thực hiện được các thử nghiệm đơn giản đối với dữ liệu do người dùng cung cấp.

Nếu Microsoft muốn nói công khai về vấn đề này, tôi rất muốn nghe thêm về nó và biết thêm về cách họ tiếp cận các đánh giá bảo mật nội bộ đối với các sản phẩm quan trọng nhất của họ.

Bản demo video GraphGoblin

Bạn không thường xuyên thấy bản demo về một lỗ hổng Azure thực tế vì chúng đã được vá và biến mất vĩnh viễn. Tuy nhiên, do Microsoft gặp sự cố khi sao chép đường vòng phức tạp này và đã yêu cầu cung cấp video nên tôi mang theo biên lai.

Để bạn hài lòng khi xem, tôi xin giới thiệu với bạn điều có lẽ là đường vòng vượt qua nhật ký đăng nhập Azure duy nhất mà bạn từng thấy:

Bản trình diễn GraphGoblin - Ảnh chụp màn hình và Nhật ký

Tôi cũng đã đưa vào hướng dẫn truyền thống bên dưới…

Trong bản demo sau, tôi sắp thực hiện một loạt ba lần đăng nhập nỗ lực.

1. Lần thử đầu tiên sẽ là lần đăng nhập thất bại và tạo ra nhật ký đăng nhập thất bại thông thường. Lần đăng nhập không thành công này cũng tạo ra một 'ID tương quan' mà chúng tôi có thể sử dụng làm điểm tham chiếu trong nhật ký của mình.
2. Trong lần thử thứ hai, tôi sẽ xác thực bằng cách sử dụng GraphGoblin kỹ thuật bỏ qua nhật ký đăng nhập.
3. Sau đó, tôi sẽ thực hiện một lần thử thất bại thông thường cuối cùng để chúng ta có một ID tương quan khác làm điểm đánh dấu.

Nếu tất cả các lần thử sau đây được ghi lại đúng cách, nhật ký đăng nhập sẽ hiển thị:

1. Đăng nhập thất bại
2. Đăng nhập thành công
3. Đăng nhập thất bại

Dưới đây là ảnh chụp màn hình nhật ký đăng nhập ID Entra. Lưu ý ID tương quan của nhật ký cuối cùng và thời gian. Nó đề ngày 20/9/2025, lúc 1:49:20 chiều, với ID tương quan bắt đầu bằng 1dfe62e9-.

Trong ảnh chụp màn hình bên dưới, bạn có thể thấy nguồn gốc của lần đăng nhập thất bại đó; lưu ý rằng thời gian và ID tương quan khớp nhau.

Trong hình ảnh trên, bên dưới lần đăng nhập thất bại, bạn có thể thấy thông tin đăng nhập hợp lệ và dấu thời gian. Đăng nhập hợp lệ xảy ra vào ngày 20/9/2025 lúc 13:52:38. Sự khác biệt là lần này tôi đang sử dụng đường vòng GraphGoblin để làm cho sự kiện đăng nhập này ẩn đi. Đăng nhập thành công và chúng ta có thể thấy mã thông báo mang được trả về.

Trong ảnh chụp màn hình sau, tôi xuất mã thông báo sang biến TOKEN để chúng ta có thể dễ dàng sử dụng nó với curl. Sau đó, tôi chứng minh rằng mã thông báo đó hợp lệ bằng cách thực hiện yêu cầu API Đồ thị với mã thông báo đó.

Bây giờ, để làm rõ khi xem lại nhật ký, tôi sẽ thực hiện một lần đăng nhập không hợp lệ mà không bỏ qua. Điều này sẽ cung cấp cho chúng tôi ID tương quan để sử dụng làm điểm đánh dấu khác.

Lưu ý rằng lần thử diễn ra từ ngày 20/9/2025 lúc 19:01:45 và có ID tương quan bắt đầu bằng 0d5ea4f0-. Xin nhắc lại, lần đăng nhập thất bại đầu tiên có ID tương quan bắt đầu bằng 1dfe62e9-.

Nếu chúng tôi đợi 10 phút để nhập nhật ký rồi xem lại nhật ký, chúng tôi sẽ thấy ID tương quan bắt đầu bằng 0d5ea4f0- ngay sau lần đăng nhập thất bại trước đó của chúng tôi bằng ID bắt đầu bằng 1dfe62e9-. Không hiển thị thông tin đăng nhập thành công.

Sau đó, tôi thực hiện đăng nhập hợp lệ BÌNH THƯỜNG mà không bỏ qua việc ghi nhật ký để cho thấy rằng nhật ký vẫn đang lưu chuyển.

Và, chúng ta có thể thấy quá trình xác thực thành công, thường xuyên xuất hiện, nhưng vẫn không có dấu hiệu của Phương pháp GraphGoblin.

Thông tin ghi nhật ký bổ sung

Sau khi đăng một video về đường vòng lên Twitter/X cách đây không lâu, mọi người tò mò liệu có phải nguyên nhân là do nhật ký đăng nhập không hiển thị chúng trong GUI cổng thông tin Azure hay nó thực sự đã bị loại bỏ.

Xem xét các phân tích nhật ký, tôi có thể tự tin nói rằng những thứ này đã bị loại bỏ hoàn toàn khỏi nhật ký đăng nhập. Trong video demo, tôi đã gửi một yêu cầu bình thường với tác nhân người dùng là MARKER 1 – TRƯỚC BỎ QUA. Sau khi thực hiện nhiều lần xác thực bằng cách sử dụng tính năng bỏ qua ghi nhật ký, tôi đã gửi một yêu cầu bình thường khác với tác nhân người dùng là MARKER 2 – SAU KHI BỎ QUA. Trong không gian làm việc Phân tích nhật ký của tôi, chúng tôi có thể thấy rằng không có nhật ký đăng nhập nào bị bỏ qua được đưa vào Phân tích nhật ký. Chỉ các mục MARKER 1 và MARKER 2 mới hiển thị trong các thử nghiệm của chúng tôi.

Biểu đồ****** Bỏ qua phần thưởng!

Được rồi, tôi đã đề cập rằng tôi đã tìm thấy đường tránh THỨ TƯ. Cái này cực kỳ đơn giản và nó liên quan đến GraphGoblin. Bạn có thể đoán tham số đăng nhập nào dễ bị tấn công không?

Tôi sẽ cho bạn một gợi ý: Trường này được tùy chỉnh thường xuyên.

Một gợi ý khác: Nếu bạn định thực hiện làm mờ một hệ thống xác thực dựa trên web quan trọng và ghi nhật ký của nó, bạn CHẮC CHẮN muốn đưa trường này vào thử nghiệm của mình.

Bạn có đoán được không? Nếu bạn đoán được trường USER-AGENT thì bạn ĐÚNG!

Bí quyết lạm dụng trường này để không tạo nhật ký xác thực? Bạn tạo chuỗi tác nhân người dùng thật dài. Tổng cộng 50.000 ký tự trong tác nhân người dùng hoạt động ổn định. Thế thôi. Không có thủ thuật đặc biệt nào, chỉ là một chuỗi dài.

Dưới đây là ảnh chụp màn hình hoạt động của đường vòng:

Một lần nữa, tôi đoán đây là kết quả của việc vượt quá giới hạn cột SQL.

Đây là ảnh chụp màn hình trong đó tôi đăng nhập không thành công để tạo ID tương quan bắt đầu bằng c542178e:

Và đây là ảnh chụp màn hình tìm kiếm trong nhật ký của tôi từ ngày 09 tháng 10 năm 2025, tìm kiếm ID tương quan đó trong nhật ký của tháng trước. Như bạn có thể thấy, không tìm thấy nhật ký nào có ID tương quan, cho biết việc bỏ qua đã thành công.

Tôi phát hiện ra điều này vào ngày 28/9/2025 và một tuần sau khi tôi quay lại viết báo cáo về nó thì Microsoft đã sửa nó rồi! Tôi không chắc bằng cách nào họ phát hiện và khắc phục vấn đề này mà không để ý và sửa GraphGoblin, nhưng họ đã làm vậy.

Dòng thời gian

• 20/9/2025          Phát hiện ban đầu về GraphGoblin
• 26/9/2025           Tiết lộ lần đầu về GraphGoblin cho MSRC
• 28/9/2025          Phát hiện ban đầu về Graph******
• 8/10/2025          Graph****** đã được Microsoft sửa trước khi báo cáo
• 17/1/2025          Microsoft không thể tái tạo lại điều này nên tôi tạo cho họ một video
• 21/11/2025       Cuối cùng, sao chép lại và bắt đầu triển khai bản sửa lỗi
• 1/12/2025          Đã được báo cáo lại trong MSRC về: tiền thưởng và mức độ nghiêm trọng, không thay đổi

Chuyện gì đang xảy ra ở đây vậy, Microsoft?

Để xem lại, đây là các phần của POST đăng nhập có sai sót đã cho phép bỏ qua nhật ký đăng nhập Azure Entra ID. Tôi đã tổng hợp chúng thành một ảnh chụp màn hình để bạn có thể biết có bao nhiêu thông số đăng nhập đã được xác định có vấn đề.

Đây là cánh cổng bảo vệ hàng trăm, thậm chí hàng nghìn tổ chức. Làm sao có thể có nhiều phần của tính năng quan trọng này lại chưa được kiểm tra một cách đáng tiếc đến vậy? Không có đường vòng nào mà tôi đã gửi trong vài năm qua là phức tạp. Tuy nhiên, bằng cách nào đó, quá trình đánh giá bảo mật của Microsoft đối với Entra ID đã bỏ sót tất cả chúng.

Có phải vấn đề xảy ra với mã hóa AI không? Bất kỳ ai đã từng làm việc với AI về mã hóa đều biết rằng nó 100% có thể (và thường sẽ) loại bỏ các phần mã của bạn khi sửa đổi nó. Hay những vấn đề này đã được đưa ra từ từ trong những năm qua? Hoặc, tất cả những vấn đề này đã tồn tại kể từ khi Azure ra đời hơn một thập kỷ trước? Thật không may, chúng tôi sẽ không bao giờ biết. Một lần nữa, tôi mời Microsoft phát biểu công khai về những lỗi lặp đi lặp lại này.

Phát hiện các lỗi bỏ qua nhật ký đăng nhập - Một giải pháp an toàn cho tương lai

Bốn lần vượt qua nhật ký đăng nhập trong ba năm qua, được cho là nhật ký quan trọng nhất của Azure. Điều này không tốt cho những quản trị viên dựa vào những nhật ký này như một nguồn thông tin chính xác. Vậy bạn có thể làm gì ngoài việc quay trở lại vị trí ban đầu? Chà, nếu bạn bỏ tiền ra mua giấy phép E5, bạn vẫn có thể phát hiện hoạt động độc hại, bất chấp những thất bại của Microsoft.

Phát hiện KQL

Sau khi tìm thấy hai đường vòng cuối cùng này, tôi bắt đầu xem liệu mình có thể xác định được lưu lượng truy cập từ các phiên bị bỏ qua này hay không. Tôi đã thu thập hoạt động Biểu đồ trong không gian làm việc Phân tích nhật ký cùng với nhật ký Đăng nhập. Trong khi xem lại nhật ký, tôi nhận thấy rằng cả nhật ký Đăng nhập và nhật ký Hoạt động đồ thị đều có trường ID phiên. Hoàn hảo! Có thể lấy danh sách tất cả ID phiên duy nhất từ ​​nhật ký Hoạt động đồ thị và tìm ID phiên tương ứng trong nhật ký đăng nhập. Bất kỳ ID phiên nào chỉ hiển thị trong nhật ký Hoạt động đồ thị và không tồn tại trong bất kỳ nhật ký đăng nhập nào đều phải bỏ qua nhật ký đăng nhập. Lưu ý dành cho người bảo vệ: bạn sẽ cần có giấy phép E5 để thu thập nhật ký Hoạt động đồ thị.

Tôi bắt đầu với một truy vấn đơn giản, chạy nó trên đối tượng thuê thử nghiệm nhỏ của mình và voilà! Tôi có danh sách hoạt động Đồ thị thuộc các phiên đã bỏ qua của mình.

Tuy nhiên, điều nhanh chóng trở nên rõ ràng là khi thử nghiệm khả năng phát hiện với một khách hàng tại một tổ chức lớn hơn, có rất nhiều 'tiếng ồn' có thể xảy ra. Những lần kiểm tra đơn giản của tôi không tính đến các thông tin đăng nhập không tương tác cũng như các thông tin đăng nhập chính của dịch vụ.

Trong một thời gian, tôi đã rơi vào tình trạng bế tắc. Tuy nhiên, tôi nhanh chóng phát hiện ra rằng đã có người khác nghĩ đến điều này và đã thực hiện nó! Fabian Bader có một bài đăng đề cập chính xác vấn đề này trong bài viết tuyệt vời của anh ấy, Phát hiện các mối đe dọa bằng nhật ký hoạt động của Microsoft Graph - Phần 2.

Có toàn bộ phần về cách tìm nhật ký đăng nhập bị thiếu!

Phương pháp này kết hợp các nguồn đăng nhập bổ sung mà tôi chưa có, bao gồm từ nguồn gốc dịch vụ, danh tính được quản lý và thông tin đăng nhập của người dùng không tương tác. Thay vì kết hợp trên các giá trị SessionId, KQL này thực hiện THAM GIA trên các thuộc tính chi tiết hơn – GraphActivity.SignInActivityId <-> SignInLogs.UniqueTokenIdentifier.

Tôi vẫn gặp một chút nhiễu loạn nhưng tôi đã thêm MicrosoftServicePrincipalSignInLogs vào danh sách các nguồn Đăng nhập và hầu như đã bị xóa.

 Nhật ký hoạt động của MicrosoftGraph
| nơi TimeGenerated> trước (8 ngày)
| tham gia kind=leftanti (union isfuzzy=true
        Đăng nhậpNhật ký,
        AADNonInteractiveUserSignInLogs,
        AADServicePrincipalSignInLogs,
        AADQuản lýIdentitySignInLogs,
        MicrosoftServicePrincipalSignInNhật ký
    | nơi TimeGenerated > trước (90d)
    | tóm tắt arg_max(TimeGenerated, *) bởi UniqueTokenIdentifier
    )
    trên $left.SignInActivityId == $right.UniqueTokenIdentifier 

Nếu truy vấn trên trả về kết quả dương tính giả, bạn có thể muốn thử nghiệm so khớp trên biến so khớp rộng hơn, SessionId thay thế:

 Nhật ký hoạt động của MicrosoftGraph
| nơi TimeGenerated> trước (8 ngày)
| tham gia kind=leftanti (union isfuzzy=true
        Đăng nhậpNhật ký,
        AADNonInteractiveUserSignInLogs,
        AADServicePrincipalSignInLogs,
        AADQuản lýIdentitySignInLogs,
        MicrosoftServicePrincipalSignInNhật ký
    | nơi TimeGenerated > trước (90d)
    | tóm tắt arg_max(TimeGenerated, *) bởi UniqueTokenIdentifier
    )
    trên $left.SessionId == $right.SessionId  

Nếu bạn điều chỉnh để không nhận được cảnh báo sai, bạn có thể tạo Quy tắc cảnh báo tìm kiếm nhật ký Azure để thông báo cho bạn nếu có cảnh báo xuất hiện.

Tôi khuyên bạn nên xem phần còn lại trong blog của Bader để biết thêm ý tưởng phát hiện vì bài đăng đó là một phần của một blog gồm ba người loạt phim.

Đã bị từ chối bởi MSRC

Trong một diễn biến hoàn toàn bất ngờ, Microsoft đã thông báo với tôi rằng họ không coi đây là vấn đề “Quan trọng” mà chỉ đơn thuần là vấn đề bảo mật “Trung bình”. Vì vậy, nó sẽ không đủ điều kiện để được ghi nhận hay khen thưởng.

Tôi đã bị sốc. Họ đã thưởng cho tôi hai lần trước đó khi tôi xác định được các lần bỏ qua nhật ký Đăng nhập Azure Entra và các lần bỏ qua ít chức năng hơn.

Ở đây, tôi đã bỏ qua nhật ký đăng nhập, ảnh hưởng đến nhật ký quan trọng nhất trong tất cả các nhật ký Azure, dẫn đến mã thông báo đầy đủ và Microsoft đang nói rằng điều đó không quan trọng. Hãy lưu ý điều đó, các quản trị viên và người quản lý CNTT. Đây là cách Microsoft xem nhật ký bảo mật quan trọng nhất trong tổ chức của bạn và là nguồn thông tin chính xác cho những người không có giấy phép E5 và tính năng ghi nhật ký nâng cao.

Nó được tính điểm như thế nào?

Khi gửi tới Microsoft, họ yêu cầu bạn đánh giá điểm CVSS của họ. Đây là đánh giá của tôi về việc chấm điểm và lý do cho việc đó. Nếu bạn muốn bỏ qua phần này, hãy chuyển sang phần phát hiện bên dưới.

Để chấm điểm, tôi đã sử dụng CVSS v3.1:

Xếp hạng Tính toàn vẹn là trọng tâm của việc này và đó là lý do tại sao điều này nên được đánh giá là 'Quan trọng' theo ngôn ngữ bản địa của Microsoft. Nếu tham khảo tài liệu CVSS v3.1, chúng ta có thể thấy rằng họ đưa ra ví dụ về những yếu tố cấu thành Thấp hay Cao đối với chỉ số Tính toàn vẹn.

Mô tả Giá trị cao cho Tính toàn vẹn số liệu, hướng dẫn lưu ý:
"Có sự mất hoàn toàn tính toàn vẹn hoặc mất hoàn toàn khả năng bảo vệ. Ví dụ: kẻ tấn công có thể sửa đổi bất kỳ/tất cả các tệp được bảo vệ bởi thành phần bị ảnh hưởng. Ngoài ra, chỉ có thể sửa đổi một số tệp nhưng việc sửa đổi có ác ý sẽ gây ra hậu quả trực tiếp, nghiêm trọng cho thành phần bị ảnh hưởng."

Ở đây, chúng tôi đang sửa đổi nhật ký đăng nhập Azure Entra ID bằng cách khiến nhật ký của chúng tôi bị bỏ qua. Việc sửa đổi các nhật ký đăng nhập này gây ra hậu quả trực tiếp, nghiêm trọng đối với thành phần bị ảnh hưởng.

Khi đưa tất cả thông tin đó vào công cụ tính toán, chúng tôi thấy kết quả là Cao, với điểm 7,5 CVSS v3.1.

Nếu áp dụng cho hầu hết các nhật ký khác, tôi có thể hiểu được xếp hạng Tính toàn vẹn thấp. Nhưng đây không chỉ là bất kỳ nhật ký nào. Đây là nhật ký đăng nhập Azure Entra ID, được cho là nhật ký quan trọng nhất trong Azure. Tiêu chuẩn CVSS đặc biệt trích dẫn điều này như một ví dụ về thời điểm nó sẽ xếp hạng Thấp thành Cao.

Nếu chúng tôi tính toán nó trong CVSS v4.0, vốn chứa cùng ngôn ngữ cho chỉ số Tính toàn vẹn , thì chúng tôi thậm chí còn đưa ra xếp hạng thậm chí còn cao hơn là 8,7.

Tính cấp bách của việc khắc phục

Mặc dù Microsoft khẳng định điều này không 'Quan trọng' ở mức độ nghiêm trọng nhưng họ đã sửa nó trong thời gian kỷ lục. Mặc dù ban đầu họ gặp khó khăn khi tái tạo cách khai thác nhưng sau khi cung cấp cho họ bản demo video và công cụ của tôi, họ đã khắc phục được sự cố trong vòng HAI TUẦN. Để tham khảo, GraphNinja mất bảy tháng và GraphGhost mất năm tháng.

Sự không nhất quán của MSRC

Có lẽ khía cạnh tồi tệ nhất là sự không nhất quán. Bạn hoàn toàn không biết họ sẽ làm gì, không biết họ sẽ nhìn nhận vấn đề của bạn như thế nào (hoặc họ hiểu vấn đề đó là gì) và không có gì đảm bảo liệu bạn có nhận được bất cứ điều gì cho rắc rối và cách khắc phục sự cố của mình hay không.

Bốn đường vòng

Dưới đây là bảng mô tả bốn đường vòng mà tôi đã xác định và cách MSRC xử lý chúng. Không có lần bỏ qua nhật ký đăng nhập nào được Microsoft thừa nhận công khai.

Mặc dù GraphGoblin truy xuất mã thông báo đầy đủ, giờ đây họ đã quyết định rằng đây không phải là 'Quan trọng'.

Tiến lên

Ban đầu, Microsoft đưa ra CVE và nó rất tốt. CVE > tiền thưởng vì CVE có giá trị trọn đời. Tôi đã nhận được một vài CVE cho Skype for Business và Lync cho Mac vào năm 2017 và 2018 nhưng không có tiền thưởng. Sau đó, Microsoft chậm lại việc cung cấp CVE nhưng bắt đầu trao tiền thưởng. Không có CVE cho nội dung đám mây và chỉ dành cho Mức độ nghiêm trọng cao hoặc nghiêm trọng. Điều này không tốt bằng nhưng tôi nhận ra rằng mình có những nhu cầu vật chất nhất định nên tiền mặt cũng được.

Nhưng hiện tại, Microsoft không cho tôi gì cả. Không có tiền thưởng. Không có điểm giả trên bảng điểm giả của họ. Thậm chí không có sự thừa nhận. Microsoft là CNA và họ có quyền quyết định đâu là lỗ hổng và đâu là không, đồng thời tôi không biết có biện pháp truy đòi thực sự nào. Đó là một sự sắp xếp thuận tiện, cho phép họ quyết định những sai sót nào của họ sẽ được công khai và những sai sót nào có thể bị che giấu.

Việc họ phản đối liệu vấn đề này có được phân loại là 'Quan trọng' hay không là điều đáng thất vọng. Tôi sẽ nói rằng nếu họ không trao tiền thưởng cho lần vượt qua GraphNinja ban đầu đó, tôi không biết rằng mình có dành thời gian và công sức như vậy để tìm kiếm những người khác không. Tất cả chúng ta đều có cuộc sống bận rộn, bao gồm cả tôi. Nếu họ không trả khoản tiền thưởng đầu tiên đó thì có khả năng thực sự là 3 đường vòng không được tìm thấy sẽ chờ đối thủ phát hiện.

Cuối cùng, tôi muốn bạn xem lại ảnh chụp màn hình này và lưu ý những lỗi đã được tìm thấy ảnh hưởng đến quá trình đăng nhập đăng nhập Entra trong vài năm qua.

Đây không phải là những đường vòng ghi nhật ký phức tạp. Tất cả đều là kết quả của việc làm mờ đơn giản. Hơn nữa, đây không chỉ là bất kỳ hoạt động ghi nhật ký nào bị bỏ qua mà còn là nhật ký quan trọng cần thiết cho sự bảo mật của toàn bộ đối tượng thuê Azure. Nhật ký được đưa vào SIEM và được sử dụng làm nguồn thông tin xác thực để phát hiện những kẻ xâm nhập. Làm thế nào mà những lỗi bảo mật nghiêm trọng này lại xuất hiện? Họ đã ở đó bao lâu? Tại sao họ không bị thu hút bởi những đánh giá của chính Microsoft? Gần như toàn bộ nước Mỹ đều sử dụng Azure. Nhiều nơi trên thế giới sử dụng Azure. Chúng tôi đã đặt niềm tin chung vào Microsoft và các biện pháp bảo mật của họ. Khi có một vấn đề ảnh hưởng đến nhiều người dùng như vậy, tôi tin rằng Microsoft có nghĩa vụ phải thông báo cho công chúng nói chung. Thật không may, chúng tôi không thấy điều đó.