Microsoft Sentinel UEBA for AWS CloudTrail: Behavior Analytics Without KQL Baselines

Microsoft is pushing Microsoft Sentinel UEBA deeper into the multi-cloud security arena, expanding behavior analytics for AWS CloudTrail and other non-Microsoft data sources so defenders can investigate suspicious cloud activity with less hand-built query logic. The key idea is deceptively simple: instead of forcing security teams to calculate every baseline themselves in KQL, Sentinel now enriches AWS activity with binary behavioral signals such as first-time geography, uncommon ISP, unusual action, and abnormal operation volume. For overwhelmed SOC teams, this marks a practical shift from raw log archaeology to behavior-led cloud defense.

Overview​

Microsoft Sentinel has long occupied an important place in Microsoft’s broader security stack, combining SIEM, SOAR, threat intelligence, hunting, and incident management across cloud and enterprise environments. Its biggest challenge, like every modern SIEM, has been the sheer volume and variety of telemetry it must turn into useful decisions. Cloud platforms made that problem worse because valid credentials, valid APIs, and valid automation can all be used for invalid purposes.
The latest expansion of User and Entity Behavior Analytics, or UEBA, is aimed directly at that problem. Microsoft is extending Sentinel’s behavior engine across AWS, GCP, Okta, Microsoft Defender for Endpoint device logons, Microsoft Entra managed identities, and service principal sign-ins. In practical terms, Sentinel is trying to give defenders a shared behavioral lens across hybrid identity, endpoint, and cloud activity.
AWS support is especially notable because CloudTrail is both indispensable and notoriously noisy. It records extremely valuable events, but defenders still need to decide whether a successful console login, IAM change, Secrets Manager access, KMS query, or S3 object read is normal, risky, or actively malicious. Microsoft’s answer is to enrich those events at ingestion and investigation time with machine-generated context that analysts can use immediately.
This is not a replacement for CloudTrail, KQL, least privilege, or cloud-native controls. It is more like a layer of behavioral compression that makes the most important deviations easier to see. For many WindowsForum readers who administer mixed Microsoft and AWS estates, the message is clear: Microsoft wants Sentinel to become the place where hybrid-cloud behavior is interpreted, not merely collected.

Why this matters now​

Cloud environments have become identity-driven, API-heavy, and automation-rich. Attackers increasingly operate inside that reality by stealing tokens, assuming roles, using trusted tools, and imitating administrative workflows. Static rules still matter, but they struggle when the malicious action looks exactly like a normal API call until behavior is considered.

---

The CloudTrail Visibility Problem​

AWS CloudTrail remains one of the most important sources of forensic and detection data in an AWS environment. It can show who called an API, when they called it, from where, and against which service or resource. That level of detail is essential, but it also creates a difficult operational burden because every event must be interpreted in context.
A ConsoleLogin event may be benign for a cloud engineer who signs in daily from a known location. The same event may be critical if it involves a rarely used administrator, a new country, an unusual ISP, and a user agent that has never appeared in the tenant. Raw logs provide the evidence, but they do not automatically provide the judgment.
Traditional detection engineering often tries to solve this by building historical baselines directly in KQL. A rule might compare the last hour of activity against the previous two weeks, enrich IP addresses with geography, summarize prior countries per user, and alert when something new appears. That works, but it becomes expensive to maintain as environments, identities, regions, and automation patterns change.

Why static thresholds age badly​

Static thresholds are particularly fragile in cloud environments because scale changes quickly. A deployment pipeline, incident response exercise, migration, or new engineering team can suddenly produce activity that looks strange but is expected. Conversely, a careful attacker can stay below a fixed threshold while still performing meaningful discovery or data collection.
Common pain points include:

• New locations created by remote work, travel, VPNs, and cloud egress points
• Automation accounts that perform rare actions on irregular schedules
• Federated sessions that hide attacker activity behind apparently valid identity flows
• Cloud APIs that are legitimate individually but suspicious in sequence
• S3 data events that can be high-volume and expensive to analyze naively
• Privilege changes that are normal during deployments but dangerous after compromise

The old approach asks every detection author to become a statistician, cloud engineer, identity analyst, and threat hunter at once. Microsoft’s UEBA expansion tries to reduce that burden by moving much of the baseline work into the platform.

---

Binary Feature Stacking Changes the Detection Model​

The phrase binary feature stacking is central to Microsoft’s new framing. Instead of asking analysts to calculate whether a country, ISP, browser, action, or operation volume is unusual, Sentinel exposes many of those findings as true-or-false enrichments. A single flag may not be enough to trigger an alert, but multiple aligned flags can form a much stronger behavioral signal.
For example, a console login from a new country might be routine if the user is traveling. A console login from a new country, through an uncommon ISP, using an unusual browser or SDK, followed by an uncommon IAM action is very different. The power comes from stacking signals that describe the same event from user-level, tenant-level, peer-level, and activity-level perspectives.
This approach also improves readability. A detection that once required multiple summarize operations, joins, geolocation lookups, and historical sets can become a shorter query against the BehaviorAnalytics table. That does not make detection engineering effortless, but it lets engineers express intent more directly.

From baseline math to intent​

The new model encourages teams to write rules around what they are trying to identify rather than how to calculate every deviation. A hunt can focus on “new geography plus uncommon action plus uncommon ISP” instead of manually reconstructing the user’s history every time. This is a major quality-of-life improvement for defenders who must maintain large rule libraries.
A practical detection sequence might look like this:

• Identify a high-value AWS activity such as console login, IAM modification, Secrets Manager access, KMS access, or S3 object retrieval.
• Filter for UEBA enrichments that show user-specific or tenant-specific deviation.
• Require multiple binary signals before escalating severity.
• Pivot into the Anomalies table when Microsoft’s machine learning models have already produced a related anomaly.
• Validate recurring patterns against known automation, change windows, and identity ownership.

This is not magic, and it should not be treated as a black box that automatically knows the business. It is a structured way to make behavioral context reusable, consistent, and easier to operationalize.

---

Inside the BehaviorAnalytics and Anomalies Tables​

Microsoft Sentinel surfaces AWS UEBA context primarily through two tables: BehaviorAnalytics and Anomalies. The distinction matters because one is a rich hunting and investigation surface, while the other represents model-driven anomaly outputs. Used together, they give analysts both raw behavioral features and higher-level prioritization.
The BehaviorAnalytics table stores enriched activity records. For AWS, fields such as EventSource, ActivityType, and ActionType help analysts scope activity by original source, AWS service, and API action. In simple terms, EventSource can identify AWSCloudTrail, ActivityType can map to a service-level source such as S3, IAM, KMS, or signin.amazonaws.com, and ActionType can identify the specific API call.
The most important enrichment fields are dynamic JSON-style property bags: UserInsights, DeviceInsights, and ActivityInsights. ActivityInsights is where many of the binary behavior features live, including first-time action, uncommon action, uncommon country, uncommon ISP, uncommon high volume of operations, and related signals. These enrichments use different baseline windows, ranging from short-term patterns to much longer historical comparisons.

What the Anomalies table adds​

The Anomalies table contains the output of Microsoft’s pre-trained anomaly detection models. For AWS, Microsoft now identifies several built-in anomaly categories, including anomalous logon, anomalous IAM privilege modification, anomalous federated or SAML identity activity, anomalous Secrets or KMS access, anomalous S3 data transfer, and anomalous STS AssumeRole behavior. These records include scores, reasons, and MITRE ATT&CK mappings that can accelerate triage.
Key investigation fields include:

• AnomalyScore, which helps rank the model’s confidence or severity
• AnomalyReasons, which explains contributing behavior signals
• MITRE ATT&CK mappings, which connect events to tactics and techniques
• InvestigationPriority, which helps analysts decide what to examine first
• ActivityInsights, which preserves useful behavioral context
• Entity details, which can connect anomalies to users, accounts, devices, and incidents

This split is healthy because not every enriched event should be an alert. BehaviorAnalytics gives hunters a broad workbench, while Anomalies gives analysts a narrower list of events that Microsoft’s models consider unusual. Mature SOCs will use both rather than relying exclusively on either.

---

AWS Attack Scenarios Gain More Context​

Microsoft’s examples focus on attack paths that defenders already know well: federated session hijacking, compromised access keys, IAM backdoors, Secrets Manager or KMS discovery, and low-and-slow S3 data movement. What changes is not the underlying attacker tradecraft. What changes is the amount of context available when those actions appear in Sentinel.
Consider federated or SAML identity abuse. A compromised identity provider session can produce legitimate AWS activity under an assumed role. CloudTrail may show valid authentication and valid API calls, but UEBA can highlight that the user connected from a first-time country, used an uncommon ISP, or performed an action that is rare for both the user and the tenant.
IAM backdoor creation is another strong example. Creating a user, login profile, access key, or policy attachment may be legitimate during administration. When paired with a rare user agent, first-time geography, and an action the identity does not normally perform, the same event becomes much more urgent.

Mapping behavior to the kill chain​

The most useful outcome is better continuity across the attack chain. A SOC can start with suspicious authentication, follow it through privilege modification, examine credential access, and then review data movement. That continuity matters because many breaches are not one dramatic event but a sequence of individually plausible actions.
Important AWS scenarios include:

• Initial access through stolen credentials or federated session compromise
• Persistence through IAM user creation, login profile creation, or policy manipulation
• Privilege escalation through unusual role assumption or permission attachment
• Credential access through Secrets Manager or KMS exploration
• Collection through repeated secret, key, or object access
• Exfiltration through abnormal S3 transfer patterns
• Defense evasion through use of trusted APIs and legitimate administrative tools

This is where UEBA can produce meaningful value. It does not simply say “CreateUser happened.” It can help answer whether this user usually creates users, whether the action is common in the tenant, whether the source is geographically expected, and whether the surrounding behavior resembles known attacker movement.

---

Practical Hunting with Sentinel UEBA​

For defenders, the practical starting point is not to immediately convert every binary feature into a high-severity alert. The smarter path is to explore the BehaviorAnalytics table, understand which features appear in the environment, and identify combinations that reliably separate suspicious behavior from expected operations. This is especially important in AWS estates with heavy automation.
A starter hunt should focus on enriched AWS activity where ActivityInsights is populated. Analysts can filter for first-time country, uncommon action, or uncommon high operation volume, then review the resulting identities, services, and API calls. Over time, those findings can become more precise rules that stack multiple signals and exclude known benign patterns.
Teams should also pivot from BehaviorAnalytics into the Anomalies table. If an enriched event has multiple suspicious indicators, there may already be a model-generated anomaly with supporting reasons and a score. That pivot helps analysts avoid duplicating work and gives detection engineers a way to compare handcrafted hunts against Microsoft’s machine learning outputs.

A disciplined rollout pattern​

A measured implementation plan should include both technical configuration and operational tuning. UEBA needs data, time, and feedback before it can become a trusted part of day-to-day triage. Teams that skip the learning phase risk creating noisy detections from signals they have not yet understood.
A sensible rollout includes:

• Enable supported AWS CloudTrail ingestion for management events and selected data events where appropriate
• Confirm UEBA is enabled for the relevant data source and workspace
• Allow baseline time before judging anomaly quality
• Review ActivityInsights manually before turning hunts into alerts
• Document known automation identities and expected service roles
• Use scoped exclusions rather than broad allowlists
• Tune by identity type, separating human administrators from CI/CD and service principals

The most important principle is restraint. A single “first time” flag may be useful for investigation, but it is often too weak for alerting. Multiple aligned signals, especially across identity, geography, ISP, action, and volume, make stronger candidates for production detections.

---

Enterprise Impact: Less Query Burden, More Behavioral Triage​

For enterprise SOCs, the most immediate benefit is reduced engineering overhead. Large organizations often have dozens or hundreds of KQL rules that attempt to recreate behavioral baselines for different platforms. Centralizing more of that logic inside Sentinel’s UEBA engine can reduce duplicated work and make detection logic easier to read.
This matters because detection maintenance is a real cost. Every rule with custom baselines must be reviewed when log schemas change, identity patterns shift, cloud regions expand, or automation moves to new infrastructure. If Sentinel can maintain common baselines automatically, detection teams can spend more time on threat modeling, validation, and response playbooks.
There is also an analyst experience benefit. Investigators need to understand why something is suspicious quickly. AnomalyReasons, binary enrichments, and incident graph context can shorten the time between alert opening and a confident decision.

What changes for SOC workflows​

The shift is subtle but meaningful. Analysts move from asking only “what event happened?” to asking “does this event fit the identity’s expected behavior?” That is closer to how human investigators already think, but now the supporting data is easier to retrieve.
Enterprise teams should expect changes in several workflows:

• Triage becomes more focused on behavioral combinations
• Threat hunting becomes less dependent on raw-table schema knowledge
• Detection engineering becomes more declarative and less baseline-heavy
• Incident review gains clearer explanations for suspicious AWS actions
• Cloud security teams can collaborate more easily with Microsoft-focused SOC analysts
• Executive reporting can describe behavioral risk rather than only event counts

The value will be highest in organizations with mature identity governance and consistent logging. UEBA is only as useful as the telemetry and entity context behind it.

---

Consumer and Small Business Relevance​

This update is clearly aimed at enterprise defenders, but it still has lessons for smaller organizations and advanced users. Many smaller businesses now run workloads in AWS while using Microsoft 365, Entra ID, Defender, or outsourced security monitoring. They face the same identity-driven attack patterns, just with fewer people to investigate them.
For smaller teams, the promise of pre-computed behavioral context is especially attractive. They may not have dedicated KQL engineers or cloud threat hunters, but they still need to know when an admin signs in from an unexpected country, assumes an unusual role, or starts accessing secrets at an abnormal rate. A platform that expresses those deviations directly can lower the barrier to useful monitoring.
There is a caveat: Microsoft Sentinel can be expensive or complex if deployed without planning. Ingestion volume, data retention, analytic rule design, and incident workflows all require cost control. Smaller businesses should be selective about which AWS data events they ingest and should avoid turning every anomaly-like signal into an alert.

Where smaller teams should focus​

The best starting point is narrow, high-impact monitoring. Small organizations should prioritize identity, privilege, and sensitive data access before attempting broad cloud telemetry collection. That gives them the best security return for the least operational complexity.
Useful priorities include:

• Root and administrator sign-ins
• New IAM users or access keys
• Policy attachment and privilege changes
• Secrets Manager and KMS access
• S3 access to sensitive buckets
• Unusual role assumption
• Sign-ins from new geography or unfamiliar ISPs

For managed service providers, Microsoft’s UEBA expansion also creates an opportunity to standardize multi-customer hunting patterns. The challenge will be building guardrails so each customer’s normal automation does not generate recurring noise.

---

Competitive Implications for Cloud Security​

Microsoft’s move should be read as part of a broader contest over who owns the security operations console in multi-cloud environments. AWS has its own security services, including CloudTrail, GuardDuty, Security Hub, Detective, IAM Access Analyzer, and other native tools. Microsoft is not replacing those controls, but it is arguing that hybrid enterprises need a broader behavioral layer that crosses cloud and identity boundaries.
The competitive logic is straightforward. Many large organizations use Microsoft for identity, endpoint, productivity, and security operations, while also running significant workloads in AWS. If Sentinel can interpret AWS activity alongside Entra ID, Defender XDR, Okta, GCP, and Windows telemetry, Microsoft strengthens its claim to be the unified SOC platform even outside Azure.
Rivals will not stand still. Cloud-native security platforms, CNAPP vendors, XDR providers, and SIEM competitors all emphasize behavior analytics, identity threat detection, and cloud posture correlation. The differentiator will not be whether a vendor says “AI” or “UEBA,” but whether it can produce accurate, explainable, low-noise signals across real enterprise data.

Why explainability matters​

Security teams are increasingly skeptical of opaque AI claims. They need to know why an alert fired, which signals contributed, and whether the logic can be tuned safely. Microsoft’s use of binary features and AnomalyReasons is important because it gives analysts a more inspectable path from raw event to suspicious finding.
Competitive success will depend on:

• Data coverage across cloud, identity, endpoint, and SaaS systems
• Signal quality that reduces false positives without hiding real attacks
• Explainability through reason fields, scores, and investigation context
• Cost predictability for high-volume cloud logs
• Workflow integration inside incident response and case management
• Open hunting access through queryable tables and transparent schemas

In other words, the winner is unlikely to be the platform with the most dashboards. It will be the platform that helps analysts make better decisions faster.

---

Limitations Microsoft Customers Must Understand​

Microsoft is explicit that UEBA coverage is selective, and that caveat matters. Not every AWS API call is modeled or enriched in the same way. CloudTrail is too broad and high-volume for every event to receive equal behavioral treatment, so Microsoft focuses on event sources and actions that are most useful for behavior modeling and attacker detection.
Not all enrichments apply to all event types. Location and ISP signals require useful source IP data, while device-related insights depend on user-agent parsing and related telemetry. A rare API may not produce the same volume-based features as a common service action, and some identity enrichments depend on Microsoft identity inventory that may be weaker for non-Microsoft identity providers.
Cross-cloud identity baselines also require careful interpretation. Microsoft profiles identities per data source, which means behavior in AWS, GCP, Okta, and Entra may not automatically merge into one universal behavioral identity. Analysts can correlate manually, but they should not assume the platform always understands every identity relationship perfectly.

Scores are guidance, not truth​

AnomalyScore and InvestigationPriority should be treated as prioritization aids. A high score is not always the most business-critical event, and a lower score can still matter if the identity, resource, or timing is sensitive. Security teams should combine scores with asset value, identity privilege, threat intelligence, and operational context.
Important constraints include:

• Selective API coverage across AWS services
• Different enrichment availability depending on event type
• Baseline maturity requirements before signals become stable
• Potential user-agent spoofing that can affect device insights
• Identity mapping gaps for IAM users without clean UPN relationships
• UI surfacing limits for some non-UPN entities
• Cost and volume tradeoffs when ingesting detailed AWS data events

These limitations do not undermine the feature. They define the boundaries within which it should be deployed responsibly.

---

Strengths and Opportunities​

Microsoft’s AWS UEBA expansion gives defenders a more practical way to interpret cloud activity by combining raw telemetry, behavioral baselines, and model-generated anomaly records. Its strongest value lies in reducing the repetitive baseline work that has historically made CloudTrail analytics difficult to scale.

Where Sentinel UEBA can help most​

• Simpler KQL that expresses detection intent without rebuilding every baseline manually
• Stronger triage context through first-time, uncommon, and abnormal-volume indicators
• Better hybrid visibility across Microsoft, AWS, GCP, Okta, endpoint, and identity signals
• Improved anomaly explanation through reason fields and MITRE ATT&CK mappings
• More resilient detections that rely on behavior rather than static thresholds alone
• Faster hunting workflows using BehaviorAnalytics as a consistent investigation surface
• Clearer SOC communication because analysts can explain why activity deviates from normal behavior

The opportunity is not merely technical. It is operational. If used well, UEBA can help SOC teams move from alert volume management to behavior-driven risk prioritization.

---

Risks and Concerns​

The main risk is overtrust. Behavioral analytics can improve detection quality, but it can also create a false sense of certainty if teams treat scores and binary features as final answers. A mature SOC should view UEBA as an accelerator for investigation, not as an autonomous judge.

What teams should guard against​

• Alerting on single features such as first-time country without additional context
• Blanket exclusions for automation accounts that could hide compromised pipelines
• Ignoring baseline warm-up and judging results before behavior has stabilized
• Underestimating ingestion cost for high-volume AWS telemetry such as S3 data events
• Assuming UI visibility equals total coverage when some anomalies may require table queries
• Overlooking identity fidelity for IAM users, service roles, and federated sessions
• Treating anomaly scores as business priority without considering asset sensitivity

The best deployments will pair UEBA with strong identity hygiene, AWS-native controls, least privilege, logging discipline, and incident response playbooks. The technology is powerful, but it cannot compensate for weak governance by itself.

---

Looking Ahead​

Microsoft’s direction is clear: Sentinel is becoming more behavior-centric, more multi-cloud, and more tightly aligned with the Defender portal experience. The retirement path for Sentinel in the Azure portal makes that direction even more important because future workflows will increasingly live inside Microsoft’s unified security operations interface. For defenders, that means UEBA signals are likely to become more visible in incident graphs, entity pages, hunting experiences, and automated response patterns.
The next question is how far Microsoft can push explainable behavioral analytics without overwhelming customers with another layer of data. The UEBA behaviors layer, the BehaviorAnalytics table, and the Anomalies table all offer useful perspectives, but SOC teams will need clear operating models for when to use each. Microsoft’s challenge is to make these layers complementary rather than confusing.

What to watch next​

• Expansion of AWS API coverage beyond the most security-relevant actions
• Improved identity correlation across AWS IAM, Entra ID, Okta, and service accounts
• More built-in detections that combine UEBA signals with Defender XDR context
• Better cost guidance for customers ingesting high-volume cloud data events
• More explainable AI workflows that show analysts why a model reached a conclusion

For WindowsForum readers, the broader trend is worth tracking even if AWS is only one part of the environment. Identity has become the control plane, APIs have become the attack surface, and behavioral context is becoming the language SOCs use to separate normal administration from intrusion.
Microsoft Sentinel UEBA’s expanded AWS support is not a silver bullet, but it is a meaningful step toward more intelligible cloud security operations. By turning raw CloudTrail events into queryable behavioral signals, Microsoft is helping defenders spend less time rebuilding baselines and more time asking the questions that matter: whether the identity should have done this, whether it has done it before, whether the environment has seen it elsewhere, and whether the pattern fits attacker tradecraft. In a world where valid credentials are often the attacker’s favorite tool, that shift from event collection to behavioral understanding may be one of the most important improvements a modern SOC can make.

---

Source: Microsoft Simplifying AWS defense with Microsoft Sentinel UEBA | Microsoft Security Blog