Microsoft on April 28 equipped its Sentinel SIEM with an expanded behavioral analytics engine that ingests AWS CloudTrail, GCP, and Okta logs—enriching them with machine-made baselines so defenders can skip the heavy KQL lifting. The headline for AWS security teams: raw CloudTrail events now arrive with pre-computed binary signals like “first-time geography,” “uncommon ISP,” and “abnormal operation volume,” making it far easier to spot compromised credentials and insider threats.

What’s New in the UEBA Expansion

The update extends Sentinel’s User and Entity Behavior Analytics (UEBA) to non-Microsoft data sources that matter in hybrid environments: AWS, GCP, Okta, Microsoft Defender for Endpoint device logons, Entra ID managed identities, and service principal sign-ins. For AWS specifically, the enrichment pipeline now surfaces behavioral context through two tables in the Sentinel workspace: BehaviorAnalytics and Anomalies.

The BehaviorAnalytics table stores every CloudTrail event alongside a JSON property bag called ActivityInsights. That bag contains true/false flags like FirstTimeUserConnectedFromCountry, ActionUncommonlyPerformedByUser, BrowserUncommonlyUsedInTenant, and UncommonHighVolumeOfOperations. These are computed across different baseline windows—anywhere from 7 to 180 days—at the user level, the tenant (AWS account) level, and the activity level. So an analyst can query for a console login that is simultaneously from a new country, through a rare ISP, and performing an action the user has never taken, all with a few lines of KQL that reference the pre-calculated flags.

The Anomalies table goes a step further. Microsoft’s pre-trained machine-learning models produce six built-in AWS anomaly types, each tagged with an AnomalyScore (0–1), MITRE ATT&CK mappings, and AnomalyReasons that explain why the event stood out. The anomalies cover federated session hijacking, IAM privilege modification, anomalous logons, secret/KMS key access, anomalous S3 data transfers, and more. When an enriched event in BehaviorAnalytics shows multiple red flags, an analyst can pivot to the Anomalies table to see if a model has already flagged it, often with a severity score and a human-readable reason.

Together, these two tables change the CloudTrail investigation from raw log archaeology to behavior-led triage.

Why This Matters for SOC Teams

For the security analyst staring at a flood of CloudTrail events, the practical impact is immediate: less time rewriting the same baseline KQL for the hundredth time, and more time asking whether the identity should have done that. Microsoft’s own example drives home the difference. A traditional KQL hunt for a first-time console login from a new country requires a 14-day baseline, geo-IP enrichment, set unions, and a left join against historical data—easily 15 lines of code that must be maintained. With UEBA binary features, the same hunt collapses to a three-line query that filters BehaviorAnalytics for the right ActionType and checks ActivityInsights.FirstTimeUserConnectedFromCountry == True and ActivityInsights.CountryUncommonlyConnectedFromInTenant == True. That’s not just shorter; it’s easier to read, tune, and explain to an auditor.

For detection engineers, the value lies in “binary feature stacking.” Single flags can be noisy—a user traveling to a new country is often benign. But when a console login triggers four or five flags simultaneously (new country, unusual ISP, first-time action, abnormal volume, a user agent never seen in the tenant), the combination becomes a high-fidelity detection. The engineer writes rules that express intent (“alert when a user does something they’ve never done, from somewhere they’ve never been, through an ISP the company has never used”) rather than manually calculating every baseline. This makes detection logic more resilient to changes in the environment; when automation schedules shift or new cloud regions come online, the UEBA engine automatically adapts its baselines.

For SOC managers, the benefit is a lighter maintenance burden. Many enterprises maintain dozens of KQL rules that duplicate baseline-building across different log sources. Centralizing those baselines inside Sentinel’s UEBA engine means less duplicated code, fewer false positives from stale thresholds, and faster onboarding of new cloud services.

And for cloud security architects running hybrid AWS/Azure shops, the expansion makes Sentinel a more compelling single-pane-of-glass. AWS-native tools like GuardDuty and Detective already provide intelligent threat detection, but they live in the AWS console. Sentinel UEBA ingests CloudTrail alongside Entra ID sign-ins, Defender XDR alerts, Okta events, and Windows telemetry, allowing correlation that spans the entire attack chain—from a suspicious Okta login to a new IAM user in AWS to a sensitive S3 data read.

How We Got Here: CloudTrail’s Detection Dilemma

CloudTrail has always been indispensable and, simultaneously, an analyst’s nightmare. It records every API call: ConsoleLogin, CreateUser, GetSecretValue, ListObjects. Each is valid in isolation, and the sheer volume—particularly when S3 data events are enabled—makes manual hunting impractical. Security teams traditionally responded by building static thresholds or crafting KQL queries that retroactively computed baselines. Those approaches broke quickly. A deployment pipeline creates 50 new IAM policies in an hour; a developer logs in from a coffee shop while traveling; a federated session from Okta suddenly uses a Java SDK the company has never seen. Every deviation could be an attack or just Tuesday.

The industry’s answer, from multiple vendors, has been behavioral analytics: learn what’s normal for each user, device, and tenant, and surface the exceptions. Microsoft Sentinel introduced UEBA years ago for Microsoft 365 and Entra ID data. Now the company is extending that same paradigm to the multi-cloud world. This AWS expansion isn’t a fork; it uses the same behavior engine, the same schema (BehaviorAnalytics, Anomalies), and the same hunting surface. For organizations already using Sentinel for Microsoft-centric security, AWS context plugs in with minimal additional learning curve.

Getting Started: A Practical Guide

Microsoft advises a measured rollout, and the evidence from the field supports that. UEBA needs time to baseline—typically 7 to 14 days of steady telemetry—before its signals become reliable. Jumping straight to alerting on the first day will generate noise.

Here’s a step-by-step plan:

  1. Enable CloudTrail ingestion. Ingest management events at minimum; selectively enable data events (S3 object-level logs) for the most sensitive buckets, because volume and cost can spiral quickly.
  2. Onboard AWS to Sentinel UEBA. Confirm that the UEBA data connector for AWS is enabled in your Sentinel workspace and that CloudTrail data is flowing into the AWSCloudTrail table.
  3. Let baselines mature. Allow at least a week of normal production activity before drawing conclusions. During this time, run the starter query provided by Microsoft (reproduced below) to familiarize yourself with the shape of the data.
  4. Hunt before you alert. Explore the BehaviorAnalytics table manually. Look for events where multiple binary features align. Start with identities that matter most: root user, admin roles, service accounts with broad permissions.
  5. Correlate with the Anomalies table. When an enriched event looks suspicious, pivot to Anomalies to see if a corresponding machine-made anomaly already exists. The AnomalyReasons field will tell you which signals contributed. Use the AnomalyScore and InvestigationPriority (0–10) to prioritize, but don’t treat them as gospel—a medium-scoring anomaly on a crown-jewel bucket may be more urgent than a high-scoring anomaly on a test account.
  6. Tune with exclusions, not blanket allowlists. Legitimate CI/CD pipelines often trigger “first-time” flags. Exclude specific role ARNs for specific activity types, but avoid creating broad exceptions that blind you to a pipeline compromise.
  7. Promote proven hunts to alerts. Once a combination of binary features reliably catches interesting activity without false positives in your environment, wrap it in an analytics rule. Because UEBA maintains the baselines, your rule will automatically adapt when a new engineer joins or a new region goes live.

Here’s the starter query Microsoft recommends for initial exploration:

BehaviorAnalytics
| where EventSource == "AWSCloudTrail" or ActivityType endswith "amazonaws.com"
| where isnotempty(ActivityInsights)
| where ActivityInsights.FirstTimeUserConnectedFromCountry == true
   or ActivityInsights.ActionUncommonlyPerformedByUser == true
   or ActivityInsights.UncommonHighVolumeOfOperations == true
| project TimeGenerated, UserName, ActionType, EventSource, ActivityType, ActivityInsights
| order by TimeGenerated desc

Expect to see legitimate automation in the results. Use this phase to build an internal list of expected anomalies—the service role that fetches secrets every Monday, the admin who always logs in from a co-working space. That list will later feed your exclusion logic.

The Fine Print: Limits and Costs

UEBA for AWS is powerful, but it isn’t a magic box. Microsoft is explicit about several boundaries:

  • Not every API is covered. CloudTrail can record hundreds of API actions; UEBA focuses on the ones most relevant to security: authentication, IAM changes, secrets access, S3 data operations, and a few others. A rarely used AWS service may not generate any enrichments.
  • Enrichments depend on event content. Location and ISP signals require a valid SourceIpAddress; device insights rely on UserAgent parsing (which can be spoofed); volume-based signals only apply to actions that occur with enough frequency to establish a baseline.
  • Cross-cloud identity is not yet unified. UEBA profiles each identity per data source. A user’s behavior in AWS is baselined separately from the same user’s behavior in Entra ID or Okta. Analysts must manually correlate identiies across tables if needed.
  • Anomaly surface is limited for non–UPN entities. The Sentinel UI currently shows anomalies only on entities that map to a User Principal Name. AWS IAM users without a clean UPN mapping still generate anomalies—you can query them in the Anomalies table—but they won’t appear in the portal’s entity pages or incident graphs.
  • Cost must be managed. Ingesting CloudTrail management events is relatively low-cost, but turning on S3 data events for all buckets can multiply ingestion volume. Microsoft recommends selecting only the most sensitive buckets. Similarly, the BehaviorAnalytics table retains enriched data according to your log analytics retention settings; ensure that retention and storage costs align with your detection needs.

None of these limitations are deal-breakers, but they underscore a critical rule: UEBA is a decision-support tool, not an autonomous SOC. Treat anomaly scores as prioritization hints, not as truth, and always validate findings against asset criticality and operational context.

The Road Ahead

Microsoft’s trajectory is clear: Sentinel is evolving into a behavior-centric, multi-cloud SIEM that surfaces insights through the unified Defender portal. The recent retirement announcement for Sentinel in the Azure portal reinforces that future. AWS UEBA is just one piece of a larger vision where every log—AWS, GCP, Okta, Windows, Entra—feeds into a common behavioral model, and analysts interact with it through incident graphs, entity pages, and automated responses.

Expect Microsoft to expand the list of modeled AWS APIs, tighten identity correlation across cloud providers, and offer more built-in detections that fuse UEBA signals with Defender XDR telemetry. For security teams managing both Windows and AWS, the convergence is welcome: it means fewer consoles, less context switching, and a detection engineering practice that can be applied consistently across environments.

In the near term, the pragmatic path is to treat AWS UEBA as a high-productivity hunting companion, not as a replacement for existing cloud-native controls like GuardDuty or IAM Access Analyzer. The best deployments will layer Sentinel’s behavioral context on top of AWS’s native security policies, least-privilege rules, and strong identity hygiene. Together, they turn CloudTrail from a firehose of undifferentiated API calls into a map of what’s normal—and what’s not.