DetectionsDET-001

Behavior-based detection engineering

Detect cross-context sessions followed by cloud activity

Detect a stable session moving between network contexts before accessing cloud resources.

Behavior

What it detects

Detects a stable account, application, and session moving between network contexts before accessing a cloud resource within thirty minutes.

Engineering decision

Why this detection

A device-code sign-in or network change alone is weak. The stronger signal is a stable session and application moving between network contexts before an independent audit source records cloud-resource activity.

This logic preserves the context an analyst needs to decide whether the activity was expected. A match is a high-value investigation lead, not proof of how the session was obtained.

Signal chain

Detection logic

Successful authentication
Same application and session from another network
Cloud-resource activity
Activity occurs within thirty minutes

Primary analytic

Query

KQL and SPL express the same analytical intent using source-specific schemas.

What this checks

Produce a candidate only when a stable account, application, and session crosses source contexts and is followed by independently recorded cloud activity.

KQL

let SessionTransitions =
    AuthenticationLogs
    | where Result == "success"
    | summarize FirstSeen = min(Timestamp), SourceCount = dcount(SourceIp), Sources = make_set(SourceIp)
        by Account, ApplicationId, SessionContextId
    | where SourceCount > 1;
SessionTransitions
| join kind=inner (
    CloudAuditLogs
    | where Result == "success"
    | project ResourceTimestamp = Timestamp, Actor, ApplicationId, SessionContextId, Operation, Resource
) on ApplicationId, SessionContextId
| where Actor == Account
| where ResourceTimestamp between (FirstSeen .. FirstSeen + 30m)
| project FirstSeen, ResourceTimestamp, Account, ApplicationId, SessionContextId, Sources, Operation, Resource

SPL

(index=authentication result="success") OR (index=cloud_audit result="success")
| eval account=coalesce(account, actor)
| stats earliest(eval(if(index="authentication", _time, null()))) AS first_seen
    dc(eval(if(index="authentication", src, null()))) AS source_count
    values(eval(if(index="authentication", src, null()))) AS sources
    earliest(eval(if(index="cloud_audit", _time, null()))) AS resource_time
    values(eval(if(index="cloud_audit", action, null()))) AS operation
    values(eval(if(index="cloud_audit", resource, null()))) AS resource
    by account app session_id
| where source_count > 1 AND resource_time >= first_seen AND resource_time <= relative_time(first_seen, "+30m")

What to look for

A strong match shows one stable session moving between network contexts and then performing cloud-resource activity within thirty minutes.

Technical details

Tested signal

Cross-context use of one stable session followed by a correlated cloud-resource operation within thirty minutes.

Assumptions

Authentication and cloud audit sources preserve the same stable session and application identifiers.
Source values are normalized before aggregation and the two telemetry sources use comparable timestamps.
A source-context change is supporting context, not proof of malicious activity by itself.

Data requirements and relevant fields

authentication: Successful authentication and session-use events needed to identify one stable context across distinct sources.
Timestamp
Account
SourceIp
ApplicationId
SessionContextId
Result
saas audit: Successful resource operations joined to the stable application and session context.
Timestamp
Actor
ApplicationId
SessionContextId
Operation
Resource
Result

KQL schema

AuthenticationLogs, CloudAuditLogs, and the shared identifiers are illustrative normalized mappings.

SPL schema

Authentication fields may use CIM aliases, but the cloud audit index, shared app/session_id fields, action, and resource require source-specific normalization.

Limitations

A stable session identifier must be available in both authentication and cloud audit telemetry.
Normal mobility, proxying, and shared egress can change source context legitimately.
The query does not prove how the session was obtained or whether the user intended the activity.

Both variants require stable account, application, and session identifiers across authentication and cloud audit sources.

Analyst workflow

What the analyst should look for

Who completed the original sign-in, and was the device-code workflow expected?
Is the application approved for this user and purpose?
Did the same session move between network contexts?
Which cloud resources and operations followed the sign-in?
Did other users or applications show the same pattern?

Expected result

A strong match shows one stable session moving between network contexts and then performing cloud-resource activity within thirty minutes.

Investigation pivots

Drilldowns

Use the candidate context to reconstruct what executed, what changed, and what communicated next.

View query — Review approved workflow and expected identity context

What this checks

Gather expected identity, application, device, and workflow context after the primary analytic produces a candidate.

KQL

let CandidateAccount = "riley.chen@example.com";
IdentityInventory
| where Account == CandidateAccount
| project Account, ExpectedApplicationId, ExpectedDeviceId, ApprovedWorkflow, ReviewValidUntil

SPL

| inputlookup expected_identity_workflows.csv
| search account="riley.chen@example.com"
| table account expected_app expected_device approved_workflow review_valid_until

What to look for

A current approved-workflow record that either explains the candidate or identifies the specific context that remains inconsistent.

Technical details

Tested signal

Whether the candidate aligns with a documented and currently reviewed authentication workflow.

Assumptions

The identity inventory records approved workflows with an explicit review-validity field.
Absence of an inventory record weakens an expected-workflow explanation but does not prove unauthorized activity.

Data requirements and relevant fields

identity: Reviewed identity inventory with application, device, workflow, and validity context.
Account
ExpectedApplicationId
ExpectedDeviceId
ApprovedWorkflow
ReviewValidUntil

KQL schema

IdentityInventory is an illustrative governed lookup with locally defined workflow fields.

SPL schema

The lookup name and fields must map to a maintained CSV or KV Store collection with an explicit review-validity contract.

Limitations

Inventory can be incomplete or stale.
Undocumented legitimate activity remains possible and requires human confirmation.

Both variants depend on a locally governed identity and workflow inventory rather than an event data model.

View query — Reconstruct resource operations for one candidate session

What this checks

Reconstruct operations, resources, chronology, and source context for one candidate without broadening the primary detection condition.

KQL

let CandidateSession = "SESSION-LAB-042";
CloudAuditLogs
| where SessionContextId == CandidateSession
| project Timestamp, Actor, SourceIp, ApplicationId, SessionContextId, Operation, Resource, Result
| order by Timestamp asc

SPL

index=cloud_audit session_id="SESSION-LAB-042"
| table _time actor src app session_id action resource result
| sort 0 _time

What to look for

An ordered resource-access sequence that lets an analyst compare the operation and resource with the approved purpose.

Technical details

Tested signal

The sequence of cloud-resource operations associated with the stable candidate session.

Assumptions

Cloud audit telemetry is complete for the bounded review interval.
Session identifiers are not reused across unrelated test sessions.

Data requirements and relevant fields

saas audit: Resource operations for the selected candidate session with chronological and actor context.
Timestamp
Actor
SourceIp
ApplicationId
SessionContextId
Operation
Resource
Result

KQL schema

CloudAuditLogs and its session, actor, operation, and resource fields are illustrative normalized names.

SPL schema

The cloud audit index and session_id, actor, app, action, and resource fields require vendor-specific aliases.

Limitations

Missing audit events can make the reconstructed sequence incomplete.
Resource activity does not reveal how the session was obtained.

Both variants require a cloud audit source that exposes the selected session identifier and resource-operation context.

Legitimate resemblance

What the analyst should confirm

Similar activity can be legitimate. Confirm the approved purpose and expected context before escalating.

A user completes an approved device-code or limited-input authentication workflow for a documented application.
The account, application, expected device, approved workflow, purpose, and current review period all agree with the candidate context.
A proxy, VPN, mobile network, or shared-egress service changes the visible source address during a legitimate session.
The stable device and application context remains expected, the resource operation matches the approved purpose, and independent records explain the network transition.
An expected broker or application accesses cloud resources on behalf of the user.
The broker identity, application identifier, resource operation, authorization record, and reviewed workflow are consistent across independent telemetry.
Documented administrative activity uses an approved application and session workflow during a bounded change period.
A reviewed purpose, named owner, exact account and application context, expected operations, and an unexpired change window corroborate the activity.

Confirmed match

Action after a confirmed match

Revoke the affected session and refresh tokens.
Review and revoke unapproved application consent.
Scope cloud activity performed through the session and application.
Hunt for the same application and activity pattern across other users.
Reset credentials only when the investigation supports credential exposure.

Threat hunt

Could this be happening elsewhere?

Hunt for this behavior across the environment.

View threat hunt

Technical boundary

Telemetry and limitations

Authentication: Successful authentication and session-use events with stable identity, application, session, source, grant, result, and time context.
Required fields
Timestamp
Account
SourceIp
ApplicationId
SessionContextId
GrantType
Result
Saas Audit: Cloud-resource audit events that preserve the actor, application, session, source, operation, resource, result, and timestamp.
Required fields
Timestamp
Actor
SourceIp
ApplicationId
SessionContextId
Operation
Resource
Result
Identity: Reviewed identity and workflow context used after a candidate exists to distinguish approved activity from suspicious use.
Required fields
Account
ExpectedApplicationId
ExpectedDeviceId
ApprovedWorkflow
ReviewValidUntil

Behavior mapping

MITRE ATT&CK

T1078 · Valid Accounts
The analytic examines suspicious use of a valid authentication context without claiming that the account or token was stolen.

Mappings describe the behavior examined by this analytic. They do not prove attribution, deployment, or technique-wide coverage.

Review boundary

Sources and limits

Exact fields, retention, and operational thresholds remain environment-specific.

Sections

What it detects
Why this detection
Detection logic
Query
Review
Drilldowns
Confirm
Response
Hunt
Coverage

What it detects

Why this detection

Detection logic

Query

What this checks

KQL

SPL

What to look for

Tested signal

Assumptions

Data requirements and relevant fields

KQL schema

SPL schema

Limitations

What the analyst should look for

Expected result

Drilldowns

What this checks

KQL

SPL

What to look for

Tested signal

Assumptions

Data requirements and relevant fields

KQL schema

SPL schema

Limitations

What this checks

KQL

SPL

What to look for

Tested signal

Assumptions

Data requirements and relevant fields

KQL schema

SPL schema

Limitations

What the analyst should confirm

Action after a confirmed match

Could this be happening elsewhere?

Telemetry and limitations

Blind spots

MITRE ATT&CK

Sources and limits