ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Sentinel • UEBA • BehaviorAnalytics • UserPeerAnalytics • IdentityInfo • KQL

The Account Behaved Normally — Compared With Everyone Except Its Peers

The account did not look compromised.

It signed in successfully.
It used familiar applications.
Its activity was not obviously destructive.

Compared with the user's own recent history, very little looked dramatic.

Then Agent Foskett changed the comparison.

He stopped asking whether the account looked unusual for itself — and asked whether it looked unusual for people who did the same kind of work.

That was when the behaviour changed meaning.

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating peer-based user behavior analytics in Microsoft Sentinel
Normal for the User. Unusual for the Peer Group.

Behavioral context changes with the baseline. UEBA can compare activity with the entity's history, its peers and the wider organisation.

✓ Inspect the behavioral insight
✓ Validate the peer context
✓ Return to the raw evidence

Normal is always relative to something

A user can perform an action they have performed before and still deserve investigation.

Microsoft Sentinel UEBA can enrich activity with context including whether an action is uncommon for the user, uncommon among peers or uncommon across the tenant.

“The user has done this before” is not the same thing as “this behaviour makes sense here.”

Start with the UEBA event

Microsoft Sentinel stores enriched UEBA events in BehaviorAnalytics. Agent Foskett reviewed the account's recent behavioral events and investigation priority without treating the score as a verdict.
ueba-account-behavior.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let TargetUser = "alex.wilson@contoso.com";
BehaviorAnalytics
| where TimeGenerated > ago(14d)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          ActivityType,
          ActionType,
          SourceIPAddress,
          SourceIPLocation,
          SourceDevice,
          InvestigationPriority,
          ActivityInsights,
          UsersInsights
| order by TimeGenerated desc

The event was not extraordinary by itself

There was no dramatic command line.
No impossible-travel headline.
No destructive administrative action.

But the UEBA enrichment indicated that the action was uncommon among the user's peers.

The anomaly was contextual, not spectacular.

Inspect the peer-based insight

The ActivityInsights field can contain enrichments such as ActionUncommonlyPerformedByUser and ActionUncommonlyPerformedAmongPeers. Agent Foskett extracted them so the reason for the difference was explicit.
ueba-peer-insight.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
let TargetUser = "alex.wilson@contoso.com";
BehaviorAnalytics
| where TimeGenerated > ago(14d)
| where UserPrincipalName =~ TargetUser
| extend UncommonForUser =
    tostring(ActivityInsights.ActionUncommonlyPerformedByUser),
         UncommonAmongPeers =
    tostring(ActivityInsights.ActionUncommonlyPerformedAmongPeers),
         FirstTimeForUser =
    tostring(ActivityInsights.FirstTimeUserPerformedAction)
| project TimeGenerated,
          ActionType,
          InvestigationPriority,
          UncommonForUser,
          UncommonAmongPeers,
          FirstTimeForUser,
          SourceIPAddress,
          SourceDevice
| order by TimeGenerated desc

The interesting combination

The activity was not necessarily new for the user.

If an action has happened before, a first-time detector may never care about it.

But peer analysis adds another baseline.

History can say “seen before” while peer context says “still unusual here.”

Who are the user's peers?

Microsoft Sentinel dynamically calculates peer relationships using organisational associations such as security-group membership, mailing lists and other relationships, ranking the strongest peers.

Agent Foskett inspected the peer data rather than treating “uncommon among peers” as a black-box conclusion.

Inspect the calculated peer group

Where peer analytics data was available, Agent Foskett queried UserPeerAnalytics to inspect the records associated with the target user and then reviewed the returned peer information and ranking context.
user-peer-analytics.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
let TargetUser = "alex.wilson@contoso.com";
UserPeerAnalytics
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          PeerInfo
| order by TimeGenerated desc

Peer groups are context — not an org chart

A calculated peer relationship can be useful, but Agent Foskett still validated it against the business.

Did the user have a special project?
Had their role recently changed?
Was there a legitimate reason for activity their peers rarely performed?

Behavioral analytics narrows the question. The analyst still has to understand the business.

Add identity context

When UEBA is configured, IdentityInfo provides identity context that can be correlated with hunting and investigation data. Agent Foskett used the latest record for the account.
identity-context.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let TargetUser = "alex.wilson@contoso.com";
IdentityInfo
| where AccountUPN =~ TargetUser
| summarize arg_max(TimeGenerated, *) by AccountObjectId
| project TimeGenerated,
          AccountUPN,
          AccountDisplayName,
          Department,
          JobTitle,
          Manager,
          GroupMembership,
          AssignedRoles,
          IsAccountEnabled

The business role made the anomaly stronger

The action was technically possible for the user, but it did not align well with the activity normally associated with the surrounding peer context.

That still did not prove compromise.

It raised the priority of the question.

Permission explains capability. Peer context helps explain whether the capability is normally exercised.

Return to the underlying security evidence

Agent Foskett did not stop at UEBA.

Behavioral analytics explained why the event deserved attention. The source telemetry still had to explain what happened.

UEBA prioritises the investigation. The source logs prove the actions.

Correlate the behavioral clue with sign-in evidence

For this identity case, Agent Foskett used the user and time window from the behavioral event to inspect nearby Microsoft Entra sign-ins. The actual source table depends on the behavior being investigated.
ueba-to-signinlogs.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
let TargetUser = "alex.wilson@contoso.com";
let StartTime = datetime(2026-10-05 01:00:00);
let EndTime   = datetime(2026-10-05 06:00:00);
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          AppDisplayName,
          Location,
          ResultType,
          AuthenticationRequirement,
          ConditionalAccessStatus,
          DeviceDetail,
          CorrelationId
| order by TimeGenerated asc

One behavioral signal was not enough

An action being uncommon among peers does not automatically make it malicious.

A legitimate project, new responsibility or organisational change can create the same pattern.

Agent Foskett looked for corroboration in source context, targets, timing and surrounding actions.

Behavioral difference is a reason to investigate — not a conviction.

Build the behavioral timeline

Activity appears ordinaryThe account performs a technically valid action that is not obviously malicious.
UEBA adds contextBehaviorAnalytics shows that the event deserves more attention.
Peer difference identifiedThe action is unusual when compared with the user's peer context.
Peer context validatedUserPeerAnalytics and business context are reviewed.
Identity context addedIdentityInfo helps explain role, group and privilege context.
Raw evidence investigatedThe original telemetry determines what the account actually did.

What Agent Foskett checked

User baselineWas the action unusual for the account itself?
Peer baselineWas the action uncommon among the user's peers?
Tenant baselineWas the action unusual across the wider organisation?
Identity contextWhat role, groups and privileges explain expected behaviour?
Investigation priorityHow strongly did the event deviate from expected patterns?
Source evidenceWhat do the underlying logs actually prove?

What the evidence can and cannot prove

BehaviorAnalytics stores enriched UEBA events and an InvestigationPriority value. ActivityInsights can describe whether actions are uncommon for the user, among peers or across the tenant. UserPeerAnalytics provides calculated peer context when available, while IdentityInfo adds identity information.

None of those fields independently prove compromise.

UEBA tells the analyst where behaviour differs from expectations. The investigation still has to establish why.

The lesson

Nothing about the account screamed attacker.

That was exactly why the case was interesting.

The account's activity could be explained when compared only with itself.

Its peers provided another baseline.

Normal behaviour depends on who — and what — you compare it with.

Agent Foskett used the behavioral difference as the starting point, then returned to the raw evidence.
Investigation principle: Use behavioral analytics to challenge assumptions about what “normal” means, but validate peer context and return to source telemetry before deciding activity is malicious.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingUse KQL to investigate identity, endpoint, cloud and behavioural evidence.SOC Analyst AcademyBuild practical investigation and threat-hunting skills across Microsoft security platforms.
Normal for the user. Unusual for the peer group.
Change the baseline. Validate the peers. Return to the evidence.
Continue the Investigation

Final thought

Attackers do not always make accounts behave wildly.

Sometimes activity remains just close enough to normal to avoid attention.

The user's own history is one baseline.
Their peers are another.
The organisation is another.

Agent Foskett changed the comparison — and the ordinary account stopped looking quite so ordinary.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Account Behaved Normally — Compared With Everyone Except Its Peers

This Agent Foskett investigation uses Microsoft Sentinel User and Entity Behavior Analytics to examine an account whose activity becomes unusual when compared with its peers.

Microsoft Sentinel UEBA and Peer Analysis

Use BehaviorAnalytics, ActivityInsights, UserPeerAnalytics, IdentityInfo and KQL to compare user behaviour with personal, peer and organisational baselines.

Investigating Behavioural Anomalies

Learn why peer-based behavioural differences are investigation leads rather than proof of compromise and why UEBA context should be validated against identity information and source telemetry.