Microsoft Sentinel UEBA data source fails with InternalServerError (HTTP 500)

Question

Microsoft Sentinel UEBA data source fails with InternalServerError (HTTP 500)

Aditya Beniwal 26

Hi,

I am trying to enable an additional AWS CloudTrail data source under Microsoft Sentinel UEBA in the Microsoft Defender portal.

The AWSCloudTrail table is already receiving data normally in Sentinel. I also checked the CloudTrail data and confirmed that ConsoleLogin events are available, including the required EventSource (signin.amazonaws.com) and UserIdentityPrincipalId values.

The user account has the required permissions to manage UEBA settings. Resource locks were also checked and no lock is present on the Sentinel workspace. The Anomalies setting is also enabled.

When I try to enable AWS CloudTrail from the UEBA data sources page, the operation fails with:

InternalServerError – HTTP 500

User's image

I also tested the UEBA settings API directly. A GET request works successfully and returns the current UEBA configuration. However, when I PUT the same existing configuration without adding AWS CloudTrail, the request also fails with the same HTTP 500 error.

So far, this seems to rule out AWS CloudTrail data, AWS permissions, and the specific AWS data source as the cause.

Has anyone experienced a similar UEBA settings update failure recently? Could this be a Microsoft Sentinel backend issue with the UEBA settings API?

Any guidance on additional checks would be appreciated.

0 comments

1 answer

Your answer

Answer 1

Hi @Aditya Beniwal

AWS CloudTrail is currently a supported UEBA data source in Preview in the Defender portal. Microsoft requires AWSCloudTrail events with EventName == "ConsoleLogin", EventSource == "signin.amazonaws.com" and a valid UserIdentityPrincipalId, which you have already validated.

The important diagnostic here is that GET succeeds but PUT of the existing unchanged UEBA configuration returns HTTP 500. That strongly suggests the failure is in the Microsoft.SecurityInsights UEBA settings update/backend path, rather than AWS ingestion or CloudTrail data.

One additional point: the public Sentinel Product Settings REST schema currently lists only the traditional UEBA data sources (AuditLogs, AzureActivity, SecurityEvent, SigninLogs), while AWS CloudTrail is exposed through the newer Defender portal UEBA experience. Therefore, I would avoid trying to force AWS CloudTrail through that REST API.

I would capture the request/correlation ID, UTC timestamp, workspace ID and region from the failed operation and open a Microsoft support case if the PUT continues returning 500. This appears to warrant backend investigation.

If this helps resolve your issue, please don’t forget to mark the answer as Accepted / Resolved.