{“lastseen”:”2026-04-30T16:28:39″,”description”:”In this article\\n\\n 1. Under the hood: The tables\\n 2. Traditional vs. new approach\\n 3. Real-world attack scenarios: Microsoft Sentinel UEBA in action\\n 4. Practical implementation: Getting started\\n 5. Limitations and constraints\\n 6. From raw logs to behavioral context\\n\\n\\n\\nWith the expansion of Microsoft Sentinel UEBA (User and Entity Behavior Analytics) into new data sources, spanning multi-cloud (AWS, GCP), identity providers (Okta), and authentication logs (Microsoft Defender for Endpoint DeviceLogon, Microsoft Entra ID Managed Identity, Service Principal sign-ins), defenders can now detect behavioral anomalies across hybrid environments from a single place.\\n\\nWe\u2019ve also expanded AWS coverage with more anomalies, enrichments and insights, so CloudTrail events now arrive with more built-in context at ingestion time. This lets defenders triage suspicious activity faster without building and maintaining large baselines in KQL.\\n\\nMany defenders analyze CloudTrail activity using thresholds or historical patterns to identify unusual behavior. In dynamic cloud environments, interpreting this activity can be challenging without additional behavioral context.\\n\\nMicrosoft Sentinel UEBA shifts the burden away from query authors by enriching raw AWS logs with simple binary insights (true\/false) derived from user, activity, and device behavior patterns \u2013 such as first-time geography, uncommon ISP, unusual action, and abnormal operation volume. Detection authors can stack these binary signals or combine them with built-in UEBA anomalies to surface attacker behavior that would otherwise blend into routine CloudTrail activity.\\n\\nIn this post, you\u2019ll learn how binary feature stacking works, how UEBA baselines AWS identities (human and non-human), and how to use UEBA enrichments and built-in anomalies to strengthen AWS detections and triage.\\n\\nDefenders investigating AWS activity often rely on raw CloudTrail logs, static thresholds, or manually-engineered baselines to differentiate between normal operational patterns and adversary behavior. While CloudTrail captures rich activity data, defenders often need behavioral context \u2013 such as historical usage patterns, geography, and device signals \u2013 to distinguish routine operations from suspicious behavior. This is where Microsoft Sentinel UEBA adds value.\\n\\nMicrosoft Sentinel UEBA enriches raw AWS logs with simple, binary behavioral insights (true\/false) derived from baseline user, peer, and device behavior patterns \u2013 such as first-time geography, uncommon ISP, unusual action, and abnormal operation volume. These clear binary signals help establish behavioral context and inform investigation and detection decisions. This post refers to this approach as binary feature stacking.\\n\\n## Under the hood: The tables\\n\\nMicrosoft Sentinel UEBA surfaces AWS behavioral context in two tables: BehaviorAnalytics and Anomalies.\\n\\n### BehaviorAnalytics table\\n\\nThe BehaviorAnalytics table is the primary investigation surface for UEBA-enriched AWS activity. EventSource field identifies the log source (for example, AWSCloudTrail), ActivityType maps to service level AWS _EventSource_ (for example, S3, KMS, or IAM), and ActionType captures the AWS API name (for example, ConsoleLogin or CreateUser). Use these fields to filter and scope specific categories of AWS activity.\\n\\nFigure 1: BehaviorAnalytics table schema.\\n\\nUEBA provides enrichments in three dynamic fields (UserInsights, DeviceInsights and ActivityInsights)\u2013 most importantly ActivityInsights, a JSON property bag that contains the binary behavioral features used for baseline-driven profiling. These enrichments are calculated at the user and tenant (AWS AccountId) level, as well as the activity level (for example, uncommon high volume of operations). Each enrichment uses a different baseline window, ranging from 7 days to 180 days.\\n\\nThis data is always available for hunting, even if no alert is fired. Each record includes key fields from the original CloudTrail event alongside enrichments derived from user, activity, and device behavior. The full list of available enrichments and their baseline lookback periods is documented in **Entity enrichments \u2013 dynamic fields**.\\n\\n### **Anomalies table**\\n\\nThe Anomalies table contains outputs from Microsoft\u2019s pre-trained anomaly detection machine learning models. Six built-in anomalies are currently available for AWS. For more information about these anomalies, see: Anomalies detected by the Microsoft Sentinel machine learning engine.\\n\\nFigure 2: Anomalies table schema.\\n\\nEach anomaly record includes MITRE ATT\\u0026CK mappings, behavioral enrichments, an AnomalyScore, and AnomalyReasons _,_ which explains why an event was flagged as an anomaly.\\n\\nHere\u2019s an example of an AWS IAM Privilege Modification anomaly. In this case, the _CreateLoginProfile_ API was invoked from a previously unseen user agent in a new country. The annotated screenshot illustrates how the anomaly is displayed and how the AnomalyReasons dynamic field provides binary insights that help investigation. In addition to FirstTimeUserPerformedAction and FirstTimeUserConnectedFromCountry, the BrowserUncommonlyUsedInTenant feature indicates a new user agent _(Apache-HttpClient\/UNAVAILABLE (Java\/21.0.9))_ not commonly seen in the tenant.\\n\\nFigure 3: AWS IAM Privilege Modification anomaly.\\n\\nThe Defender portal also surfaces UEBA anomalies on user entity pages and incident graphs.\\n\\nThis example highlights the Top UEBA anomalies section in an incident graph, where an _Anomalous Logon_ event is displayed with an anomaly score of _0.8_ for the account entity _cloudinfra-admin._\\n\\nFigure 4: Top UEBA anomalies on an incident graph in the Defender portal,\\n\\nYou can run built-in queries directly from incident graphs by selecting Go Hunt \uf0e0 All User anomalies queries for immediate context-driven hunting based on UEBA outcomes. For more details, see UEBA integration with Microsoft Sentinel workflows.\\n\\nFigure 5: Hunt for all user anomalies from an incident graph in the Defender portal.\\n\\n## Traditional vs. new approach\\n\\nLet\u2019s look at a classic AWS scenario: Unusual anomalous AWS logons. You want to detect a user’s sign in from an unknown location compared to its historical sign-in patterns.\\n\\n### The hard way: Raw log analytics\\n\\nCloudTrail telemetry can be analyzed using historical baselines and enrichment logic to understand behavioral patterns such as first\u2011time sign\u2011ins from new locations. UEBA complements this approach by providing pre\u2011computed behavioral indicators that can accelerate investigation workflows.\\n\\nHere is the KQL example on raw log showing necessary operations to add behavioral context.\\n\\nKQL Code Snippet:\\n \\n \\n \/\/ The \\”Hard Way\\” – baseline-heavy console sign-in analytics\\n let baselineStart = ago(14d);\\n let baselineEnd = ago(1h);\\n let userBaseline = AWSCloudTrail\\n | where TimeGenerated between (baselineStart .. baselineEnd)\\n | where EventName == \\”ConsoleLogin\\” and isempty(ErrorCode)\\n | where isnotempty(SourceIpAddress)\\n | extend geo = geo_info_from_ip_address(SourceIpAddress)\\n | extend Country = tostring(geo[\\”country\\”])\\n | where isnotempty(Country)\\n | summarize HistoricalCountries = make_set(Country) by UserIdentityPrincipalid;\\n AWSCloudTrail\\n | where TimeGenerated \\u003e ago(1h)\\n | where EventName == \\”ConsoleLogin\\” and isempty(ErrorCode)\\n | where isnotempty(SourceIpAddress)\\n | extend geo = geo_info_from_ip_address(SourceIpAddress)\\n | extend Country = tostring(geo[\\”country\\”])\\n | where isnotempty(Country)\\n | join kind=leftouter (userBaseline) on UserIdentityPrincipalid\\n | extend FirstTimeUserConnectedFromCountry = iif(isempty(HistoricalCountries) or not(set_has_element(HistoricalCountries, Country)), true, false)\\n | where FirstTimeUserConnectedFromCountry == true\\n \\n\\nThe problem: This query is computationally expensive, hard to read, and requires you to manually enrich IP addresses with location data. Accurately mapping IP addresses to ASN and ISP often requires additional enrichments and up to date lookup databases. Because different user behaviors have different levels of variability, static thresholds and manually engineered baselines can still produce false positives or low-value alerts, especially in dynamic environments.\\n\\n### The smart way: Binary feature stacking\\n\\nWith Microsoft Sentinel UEBA, the profiling engine has already done the heavy lifting. It learns the user’s sign-in patterns, peer commonality, and tenant-wide behavioral patterns, and outputs the result to the BehaviorAnalytics table as a set of pre-calculated binary features (true\/false flags).\\n\\nKQL Code Snippet:\\n \\n \\n \/\/ The \\”Smart Way\\” – leveraging binary features\\n BehaviorAnalytics\\n | where ActionType == \\”ConsoleLogin\\” and ActivityType == \\”signin.amazonaws.com\\” \\n \/\/ The Binary Features\\n | where ActivityInsights.FirstTimeUserConnectedFromCountry == True\\n and ActivityInsights.CountryUncommonlyConnectedFromInTenant == True and ActivityInsights.FirstTimeConnectionViaISPInTenant == True\\n \\n\\n**The advantages:**\\n\\n 1. **Readability:** It takes just three lines of code to express a complex idea with UEBA features.\\n 2. **Context:** You\u2019re not just looking at uncommon **sign ins**. You\u2019re stacking user-level and tenant-level indicators \u2013 such as location data (FirstTimeUserConnectedFromCountry) and uncommon ISP usage (FirstTimeConnectionViaISPInTenant) \u2013 to get a more accurate representation of suspicious behaviors relative to historical patterns.\\n 3. **Stability:** You don’t manage the baseline, lookback, and thresholds in your query. The Microsoft Sentinel UEBA ML engine maintains these automatically with baseline windows that vary by enrichment (ranging from 7 to 180 days).\\n\\n\\n\\nBy relying on these binary features, detection authors stop writing code to _discover_ behavioral signals and instead use UEBA features to express detection intent and how to _respond_ based on severity.\\n\\nNow let\u2019s look at how these same signals appear during investigation and triage.\\n\\n## Real-world attack scenarios: Microsoft Sentinel UEBA in action\\n\\nThe table below summarizes four attack scenarios using a consistent set of fields:\\n\\n * **Scenario** : The threat pattern and where it fits in the kill chain.\\n * **The attack** : What the adversary is attempting to do (high-level behavior).\\n * **Common log view** : How the activity appears in raw CloudTrail when reviewed event-by-event.\\n * **UEBA signals (binary features)** : BehaviorAnalytics binary features that provide behavioral context, along with the InvestigationPriority score (0-10) used to tune the severity of deviations.\\n * **Built-in anomaly surfaced** : Names of built-in Microsoft Sentinel UEBA anomalies you can pivot to during triage, including AnomalyScore (0\u20131) and AnomalyReasons in the Anomalies table.\\n\\n\\n\\nTogether, these scenarios illustrate how raw CloudTrail events provide foundational visibility into AWS activity. Combining this telemetry with behavioral enrichment from Sentinel UEBA can improve the interpretability of events during investigation. The same building blocks\u2014successful sign-ins, IAM changes, Secrets or KMS access, and S3 reads\u2014can represent either normal administration or active intrusion.\\n\\nBy combining CloudTrail activity with Sentinel UEBA enrichments in BehaviorAnalytics, defenders can stack multiple high-value signals to hunt for activity patterns that match attacker tradecraft.\\n\\nThis context accelerates investigations by making it easier to explain _why_ an action is suspicious and to pivot directly to correlated entries in the Anomalies table, including risk scores and reasons. For detection engineers, UEBA signals also act as stable building blocks\u2014simplifying KQL, reducing alert noise, and hardening detections over time.\\n\\nNote: The UEBA signals column lists examples of relevant binary features, not the exact logic that triggers an anomaly. Anomalies are generated by ML models and don\u2019t map one-to-one to individual features. Use AnomalyReasons in the Anomalies table to understand why a specific anomaly was flagged.\\n\\n### Attack scenarios\\n\\n**Scenario**| **The attack**| **Common log view**| **UEBA signals (binary features)**| **Built-in anomaly surfaced** \\n—|—|—|—|— \\n**Initial Access (Federated \/ SAML Session Hijack)**| An attacker gains access to a federated identity session \u2013 for example, through a compromised identity provider (IdP) \u2013 and uses a SAML or EXTERNAL_IDP flow to perform actions the user rarely performs, from a new location and at an unusual pace.| CloudTrail shows federated authentication activity (UserAuthentication \/ EXTERNAL_IDP, for example, Okta) followed by successful API calls under an assumed role session; each event is valid in isolation.| FirstTimeUserConnectedFromCountry = **True** \\n \\nISPUncommonlyUsedInTenant = **True** \\n \\nActionUncommonlyPerformedByUser = **True** \\n \\nActionUncommonlyPerformedInTenant = **True**| UEBA Anomalous Federated or SAML Identity Activity in AwsCloudTrail \\n**Initial Access and Persistence**| An attacker compromises a developer\u2019s access keys and logs in (for example, through uncommon user agent) to create a backdoor user.| CloudTrail shows a successful ConsoleLogin via SDK or CLI user agent and subsequent IAM action, such as CreateUser, all of which are valid API calls without behavioral context.| FirstTimeUserConnectedFromCountry = **True** \\n \\nBrowserUncommonlyUsedInTenant**= True** \\n \\nActionUncommonlyPerformedByUser = **True** (CreateUser) \\n \\nActionUncommonlyPerformedInTenant = **True**| Examples: UEBA Anomalous Logon in AwsCloudTrail; UEBA Anomalous IAM Privilege Modification in AwsCloudTrail \\n**Credential Access \\u0026 Collection (Secrets \/ KMS Key Discovery)**| After establishing a foothold with valid credentials, an attacker queries Secrets Manager and KMS to list keys and retrieve secret values, often starting with discovery (ListSecrets\/ListKeys) then access (GetSecretValue), sometimes at unusually high frequency.| CloudTrail shows a GetSecretValue, ListSecrets, or ListKeys activity which can look like legitimate automation and make static allowlists and thresholds brittle.| FirstTimeUserPerformedAction = **True** \\n \\nActionUncommonlyPerformedInTenant = **True** \\n \\nUncommonHighVolumeOfOperations = **True** \\n \\nISPUncommonlyUsedInTenant = **True**| UEBA Anomalous Secret or KMS Key Access in AwsCloudTrail \\n**Data Exfiltration (the \u201clow-and-slow\u201d S3 drain)**| A compromised admin account performs a burst of repeated **S3 GetObject** operations\u2014representing a high volume of similar operations within the same service\u2014often targeting multiple objects or prefixes in quick succession to stage data for exfiltration while staying below traditional volume thresholds.| If S3 data events are enabled, CloudTrail shows a high frequency of **GetObject** API calls across multiple objects or buckets in a short time window. Each request appears legitimate in isolation, and overall data transfer may remain below static thresholds, making the activity difficult to detect using traditional methods.| UncommonHighVolumeOfOperations = **True** \\n \\nCountryUncommonlyPerformedInTenant = **True** \\n \\nActionUncommonlyPerformedByUser = **True** (S3 GetObject) \\n \\nISPUncommonlyUsedInTenant = **True**| UEBA Anomalous Data Transfer from Amazon S3 \\n \\n_Table 1: Examples of Microsoft Sentinel UEBA enrichments in real-world attack scenarios_\\n\\n### Built-in Microsoft Sentinel UEBA anomaly MITRE ATT\\u0026CK coverage\\n\\nThe visual below illustrates how Microsoft Sentinel UEBA\u2019s AWS anomaly coverage maps across multiple stages of the kill chain:\\n\\n * Initial access: UEBA Anomalous Federated or SAML Identity Activity in AwsCloudTrail\\n * Initial access\/privilege escalation: UEBA Anomalous STS AssumeRole Behavior in AwsCloudTrail\\n * Persistence\/privilege escalation: UEBA Anomalous IAM Privilege Modification in AwsCloudTrail\\n * Credential access\/collection: UEBA Anomalous Secret or KMS Key Access in AwsCloudTrail\\n * Collection\/data exfiltration: UEBA Anomalous Data Transfer from Amazon S3\\n\\n\\n\\nTogether, these anomaly detections provide defenders with end-to-end visibility \u2013 from suspicious authentication through sensitive access and data movement \u2013 with binary feature enrichments that add high-value behavioral context during investigations.\\n\\nFigure 6: Microsoft Sentinel UEBA’s AWS anomaly coverage across the attack chain.\\n\\n## Practical implementation: Getting started\\n\\n**Before you begin**\\n\\nBefore you run the queries, ensure the following are in place:\\n\\n**Baseline establishment period completed** \\nAllow sufficient time for UEBA to establish user, activity, and device baselines. In most environments, this typically requires 7\u201314 days of steady telemetry.\\n\\n**AWS environment onboarded to Microsoft Sentinel UEBA** \\nEnsure that AWS CloudTrail (management events and, where applicable, object-level data) is connected, and UEBA is enabled for the AWS data source.\\n\\n**CloudTrail data is flowing consistently** \\nConfirm that AWS CloudTrail events are being ingested into Microsoft Sentinel and visible in Advanced Hunting.\\n\\n#### **Starter query**\\n\\nReady to start hunting? Open Advanced Hunting in Microsoft Sentinel and run the following query to explore the BehaviorAnalytics table and inspect enriched AWS behavioral signals. This query intentionally keeps the logic lightweight. The goal is not to \u201cdetect\u201d anomalous activity immediately, but to understand how binary behavioral features surface in your environment.\\n \\n \\n \/\/ Starter query \u2013 explore UEBA-enriched AWS behavioral signals\\n BehaviorAnalytics\\n | where EventSource == \\”AWSCloudTrail\\” or ActivityType endswith \\”amazonaws.com\\”\\n | where isnotempty(ActivityInsights)\\n | where ActivityInsights.FirstTimeUserConnectedFromCountry == true\\n or ActivityInsights.ActionUncommonlyPerformedByUser == true\\n or ActivityInsights.UncommonHighVolumeOfOperations == true\\n | project\\n TimeGenerated,\\n UserName,\\n ActionType,\\n EventSource,\\n ActivityType,\\n ActivityInsights\\n | order by TimeGenerated desc\\n \\n\\n#### **What to look for**\\n\\nWhen reviewing the results, focus on:\\n\\n * **Binary feature combinations** \\nIndividual binary indicators may be benign. Risk emerges when multiple features align (for example: first-time geography _and_ uncommon action).\\n * **User-centric deviations** \\nPay attention to activity that is unusual _for that specific identity_ , even if the action itself is common across the **tenant**.\\n * **Low-volume but persistent activity** \\nUEBA often highlights slow, methodical behavior (for example, repeated S3 reads or Secrets\/KMS access) that **stays below static thresholds but persists over time**.\\n * **Candidates for anomaly pivoting** \\nEvents that exhibit multiple binary features warrant further investigation by pivoting to the **Anomalies** table, where UEBA may have already produced a correlated anomaly record with supporting context and reasoning.\\n\\n\\n\\n#### **Common false positives (and how to filter them)**\\n\\n * **Legitimate automation or CI\/CD pipelines** \\n _Why it happens:_ Service roles or automation accounts may perform actions infrequently or from new infrastructure locations. \\n_How to filter:_ Exclude known accounts or IAM roles used exclusively for automation once validated. Be sure to filter only specific types of activities, rather than applying blanket exclusions.\\n * **New administrators or role changes** \\n _Why it happens:_ First\u2011time admin activity naturally triggers \u201cfirst\u2011time\u201d and \u201cuncommon\u201d indicators depending on the baseline. \\n_How to filter:_ Correlate with recent user creation or role assignment changes before suppressing.\\n * **Planned operational changes** \\n _Why it happens:_ Migrations, incident response, or large\u2011scale maintenance can temporarily skew baselines. \\n_How to filter:_ Use time\u2011bounded filters or change\u2011window context rather than permanently suppressing signals.\\n\\n\\n\\n#### **Next steps**\\n\\nOnce you are comfortable interpreting enriched behavior:\\n\\n 1. Stack binary features intentionally (especially User and Tenant level) in detection logic rather than alerting on single indicators.\\n 2. Pivot to UEBA anomalies to leverage Microsoft\u2019s pre-trained models across MITRE ATT\\u0026CK tactics.\\n 3. Promote successful hunts into detections with minimal additional KQL, relying on UEBA to maintain baselines over time.\\n\\n\\n\\nThis approach lets detection authors focus on behavioral intent, not baseline math \u2013 turning raw AWS telemetry into actionable security signals.\\n\\n## Limitations and constraints\\n\\nMicrosoft Sentinel UEBA can substantially reduce detection complexity, but it\u2019s important to account for coverage boundaries and the conditions under which enrichments and scores are most reliable:\\n\\n**Coverage is selective (not \u201cevery API\u201d).**\\n\\n * UEBA does not ingest or model every API call for every AWS service. CloudTrail can be extremely high-volume, so the Microsoft Sentinel UEBA pipeline focuses on the event sources and API actions that are most useful for behavior modeling and that are most commonly correlated with anomalous activity (for example, authentication, identity and permission changes, sensitive data access, and high-impact operations). You can always check the up-to-date list of in-scope event sources, APIs, and data sources in the **UEBA data sources** reference document (GCPAuditLogs, Okta log sources are also supported). We\u2019re continually adding APIs and event sources.\\n\\n\\n\\n**Enrichments vary by event type.**\\n\\n * Not all enrichments are populated for all actions. For example, UncommonHighVolumeOfOperations is unlikely to apply to specific types of rare APIs, and location\/ISP-related enrichments typically require the original source event to include a valid IP address.\\n\\n\\n\\n**Cross-cloud identity baselines are calculated independently**.\\n\\n * UEBA profiles identities per data source, which means behavior across cloud platforms is baselined separately. Correlation across environments can be performed manually using the BehaviorAnalytics table when required.\\n\\n\\n\\n**Use scores for prioritization, not direct alerting without retroactive lookup.**\\n\\n * Treat the AnomalyScore (0-1) and InvestigationPriority (0-10) values as investigation signals to help rank what to look at first \u2013 not as sole triggers for alerts. The highest score may not always be the highest priority investigation for your organization. Validate patterns in your environment and use a combination of enrichments, scores, and repeat behavior over time before finalizing alert logic.\\n\\n\\n\\n**Anomaly support in the UI is currently for UPN-based entities.**\\n\\n * AWS UEBA anomalies are currently surfaced in the UI only on the Account entity, which assumes an identity mapped to a UPN. This works well for environments that use Microsoft Entra ID (or another IdP) with UPN identifiers, but it might not apply to AWS IAM users or AWS resource entities that do not map cleanly to a UPN. To be clear \u2013 anomalies are triggered and available for all identity types (with UPN and without UPN), but are only shown in the UI for entities with a UPN.\\n\\n\\n\\n**Some insights depend on identity and user agent fidelity.**\\n\\n * DeviceInsights rely on parsing UserAgent strings and may be unreliable if user agents are spoofed or manipulated in the original log. Some UserInsights enrichments also depend on identity inventory and metadata snapshots being available. Microsoft identity data from Microsoft Entra is synchronized automatically to the IdentityInfo table \u2013 other identity providers are not currently supported, so they might have more limited enrichment coverage.\\n\\n\\n\\n## From raw logs to behavioral context\\n\\nCloudTrail provides detailed activity data. Sentinel UEBA enhances this telemetry with behavioral context, such as first\u2011time geography or uncommon ISP usage, to support investigation and detection workflows. A single _failed console login_ is often low signal on its own. That same event becomes far more meaningful when it\u2019s paired with behavioral context, such as a first-time country, an unusual ISP, or activity on a rarely used admin account.\\n\\nBy shifting our focus from writing complex queries to leveraging Microsoft Sentinel UEBA\u2019s binary feature stacking, we gain three practical advantages:\\n\\n 1. **Efficiency:** We replace baseline-heavy, maintenance-prone queries with simpler, more readable logic.\\n 2. **Accuracy:** We reduce false positives and better tune severity by requiring multiple binary features to align before alerting.\\n 3. **Visibility:** We uncover the _low-and-slow_ attacks that static thresholds often miss.\\n\\n\\n\\nFor the modern SOC, the goal is not only to collect logs\u2014it\u2019s to understand behavior. Use the BehaviorAnalytics table as your starting point to understand what \u201cnormal\u201d looks like in your environment, then pivot to related Anomalies when you need model-driven prioritization. In practice, this shifts investigations from \u201c _What happened?_ \u201d to \u201c _Is this consistent with expected behavior?_ \u201d\\n\\nReady to start hunting? Onboard your AWS environment to Microsoft Sentinel UEBA, open Advanced Hunting, and run the starter query in the _Practical implementation_ section to explore the BehaviorAnalytics and Anomalies tables in your environment.\\n\\n### References\\n\\n * UEBA onboarding and setting documentation\\n * Identify threats using UEBA\\n * UEBA enrichments and insights reference\\n * Anomalies detected by the Microsoft Sentinel machine learning engine\\n\\n\\n\\n### **Learn more**\\n\\nLearn about the UEBA Behaviors Layer for AWS CloudTrail and other data sources.\\n\\nThe Microsoft Sentinel UEBA Essentials solution provides additional built-in queries.\\n\\nThe post Simplifying AWS defense with Microsoft Sentinel UEBA appeared first on Microsoft Security Blog.”,”published”:”2026-04-28T13:00:00″,”modified”:”2026-04-28T13:00:00″,”type”:”mssecure”,”title”:”Simplifying AWS defense with Microsoft Sentinel UEBA”,”source”:””,”references”:””,”id”:”MSSECURE:331B49720D26584CBFC8DA8EB7C151FC”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.microsoft.com\/en-us\/security\/blog\/2026\/04\/28\/simplifying-aws-defense-microsoft-sentinel-ueba\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-04-30T16:28:39″,”description”:”In this article\\n\\n 1. Under the hood: The tables\\n 2. Traditional vs. new approach\\n 3. Real-world attack scenarios: Microsoft Sentinel UEBA in action\\n 4. Practical…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,110,13,33,7,11,5],"class_list":["post-50476","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-mssecure","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n