SOCLIFE
SOCLIFE

Evidence-led security analysis

Published knowledge

Search SOC//LIFE

CasesCASE-001

SOC investigation

Trace device-code access into cloud activity

A device-code sign-in was followed by use of the same session from another network and unauthorized mailbox activity.

Sanitized SOC case study based on real-world attack behavior. Names, hosts and identifiers use safe example data.

User
riley.chen@example.com
Device
WS-EX-2123
Initial alert
Device-code authentication from an unrecognized context
Severity
Medium

Case story

What happened

Riley Chen completed a device-code sign-in from a network outside the expected managed-device context.

  1. Device-code authentication completed

    Riley Chen completed a device-code sign-in for an unfamiliar application.

  2. Expected identity context reviewed

    The approved-workflow inventory did not explain the sign-in.

  3. Session context used from a second address

    The same session appeared from another network three minutes later.

  4. Cloud resource activity recorded

    Four minutes later, the correlated application and session began listing mailbox messages.

  5. Session revoked

    The affected session was revoked and later access attempts were denied.

Investigation

What was checked

Follow how the analyst tested and revised explanations. This is discovery order, not event chronology.

  1. Check the sign-in

    No approved device-code workflow matched the sign-in.

    Next pivot

    Determine whether the same session context was subsequently used and from which context.

    View query
    Q-01

    Compare device-code authentication with expected identity context

    What this checks

    Establish the authentication context before deciding whether a successful device-code grant was routine or unauthorized.

    KQL
    AuthenticationLogs
| where Account == "riley.chen@example.com"
| where GrantType == "device_code"
| project Timestamp, Account, SourceIp, ApplicationId, SessionContextId
    SPL
    | datamodel Authentication Authentication search
| search Authentication.user="riley.chen@example.com" Authentication.authentication_method="device_code"
| rename Authentication.* AS *
| table _time user src app session_id
    What to look for

    A matching grant with enough identity and session context to support a controlled follow-on correlation.

    Technical details
    Tested signal

    A device-code authentication that differs from the user's approved workflow and managed-device context.

    Assumptions
    • Authentication records are complete for the bounded scenario window.
    • Account and session-context fields are normalized consistently in this source.
    Data requirements and relevant fields
    authentication

    Device-code authentication events with identity, application, source, and session context.

    • Timestamp
    • Account
    • SourceIp
    • GrantType
    • ApplicationId
    • SessionContextId
    KQL schema

    AuthenticationLogs and its grant, application, and session fields are illustrative mappings.

    SPL schema

    The Authentication data model can normalize common identity fields, but device-code and session_id require source-specific field aliases.

    Limitations
    • A missing approved workflow record does not prove that the user did not intentionally authenticate.
    • Authentication telemetry alone cannot establish what a session later accessed.

    Both variants test the same authentication context. Device-code and session fields require source-specific normalization.

    More reasoning

    Observation

    A successful device-code authentication originated outside the user's expected managed-device context.

    Working explanation

    The user may have intentionally completed a legitimate command-line or limited-input authentication workflow.

    What was checked

    Compare the authentication event with the identity inventory and approved workflow context.

    Interpretation

    The mismatch justified further review, but a successful authentication and context difference did not prove token theft or unauthorized use.

    Supporting evidence
    Confidence changedLowtoModerate

    The expected workflow review weakened the routine-authentication explanation while leaving legitimate but undocumented activity plausible.

  2. Follow the session

    The same session appeared from another network three minutes later.

    Next pivot

    Seek an independent cloud-audit event that shows what the correlated session actually did.

    View query
    Q-02

    Correlate subsequent use of the session context

    What this checks

    Test whether the same bounded session appears after the initial grant and whether its use differs from the initial authentication context.

    KQL
    AuthenticationLogs
| where SessionContextId == "SESSION-LAB-042"
| project Timestamp, Account, SourceIp, ApplicationId, Operation, Result
    SPL
    | datamodel Authentication Authentication search
| search Authentication.session_id="SESSION-LAB-042"
| rename Authentication.* AS *
| table _time user src app action result
    What to look for

    A session-context match that can support a pivot into independent cloud audit telemetry.

    Technical details
    Tested signal

    Reuse of SESSION-LAB-042 across temporally related authentication records.

    Assumptions
    • The session-context identifier remains stable across authentication records.
    • Records use comparable timestamps within the bounded scenario window.
    Data requirements and relevant fields
    authentication

    Session audit events with stable session, identity, application, source, operation, and result fields.

    • Timestamp
    • Account
    • SourceIp
    • ApplicationId
    • SessionContextId
    • Operation
    • Result
    KQL schema

    AuthenticationLogs and SessionContextId are illustrative normalized names.

    SPL schema

    session_id is a source-specific extension to the common Authentication model and must remain stable across the selected records.

    Limitations
    • Address changes may have legitimate routing or mobility explanations.
    • Session correlation does not independently establish the user's intent.

    Both variants require a stable vendor-provided session identifier across authentication records.

    More reasoning

    Observation

    The same session context appeared from a second TEST-NET address shortly after the grant.

    Working explanation

    The address change could reflect normal network movement, or it could indicate that the granted session was being used from an unauthorized context.

    What was checked

    Correlate the session context, application, account, addresses, and timestamps across authentication records.

    Interpretation

    Session reuse made the benign explanation less comfortable, but address variation alone remained insufficient because routing and mobility can change network context.

    Supporting evidence

    Decision at this point

    What should the analyst do next without treating the address change as proof of account takeover?

    DECISION-01

    The same session context appeared from a second source address, but independent cloud-audit corroboration had not yet been reviewed.

    Evidence available at this point
    Confidence at this point
    Moderate

    All next-step reasoning is shown in this non-interactive view.

    Reasonable next step

    Correlate the session with independent cloud activity.

    A defensible decision with the evidence available now.

    Why this assessment

    This is proportionate to the current evidence, tests the higher-value competing explanation, and seeks independent corroboration without overstating compromise.

    What this would change

    Preserves competing explanations while using a separate telemetry source to narrow the ambiguity.

    Evidence considered

    Weakly supported step

    Keep expanding source-address history first.

    A plausible but less discriminating or less useful decision.

    Why this assessment

    The pivot is plausible, but it continues to overweight network context and delays a more discriminating cross-telemetry check.

    What this would change

    Consumes effort on a signal with legitimate variability while delaying the higher-value cloud-audit pivot.

    Evidence considered

    Not supported by the available evidence

    Treat the address change alone as proof of account takeover.

    The inference contradicts the analytical contract or depends on facts not available yet.

    Why this assessment

    The available evidence does not support that inference; legitimate egress, proxy, VPN, mobile, and infrastructure changes remain plausible.

    What this would change

    Overstates confidence and discards alternative explanations that the current evidence cannot eliminate.

    Evidence considered

    Too early to conclude

    Escalate to confirmed account compromise now.

    The decision could later become defensible but is not justified at this evidence threshold.

    Why this assessment

    The conclusion may later become justified, but independent corroboration is not yet available at this decision point.

    What this would change

    Raises the assessment beyond the available evidence before a higher-value corroborating check is completed.

    Evidence considered
    Evidence needed before raising confidence

    Independent cloud-audit evidence that tests whether the same account, application, and session context performed resource activity inconsistent with the expected workflow.

  3. Check cloud activity

    The same session then accessed cloud mail from the second network context.

    Next pivot

    Revoke the session and verify whether the control prevents further activity without overstating what containment proves.

    View query
    Q-03

    Correlate the session with cloud-resource activity

    What this checks

    Use an independent telemetry source to determine what the correlated session did after authentication.

    KQL
    CloudAuditLogs
| where Actor == "riley.chen@example.com"
| where ApplicationId == "APP-LAB-042"
| where SessionContextId == "SESSION-LAB-042"
| project Timestamp, Actor, SourceIp, Operation, Resource, Result
    SPL
    index=cloud_audit actor="riley.chen@example.com" app="APP-LAB-042" session_id="SESSION-LAB-042"
| table _time actor src action resource result
    What to look for

    A corroborating operation within the scenario window that can strengthen or weaken the unauthorized-session hypothesis.

    Technical details
    Tested signal

    Cloud-resource activity sharing the account, application, and session context observed in authentication telemetry.

    Assumptions
    • Cloud audit records preserve the application and session context used for the operation.
    • The cloud audit time range covers the full bounded scenario window.
    Data requirements and relevant fields
    saas audit

    Cloud resource audit events with actor, application, session, source, operation, resource, and result context.

    • Timestamp
    • Actor
    • SourceIp
    • ApplicationId
    • SessionContextId
    • Operation
    • Resource
    • Result
    KQL schema

    CloudAuditLogs and its actor, application, session, operation, and resource fields are illustrative mappings.

    SPL schema

    index, actor, app, session_id, action, and resource must be mapped to the selected SaaS audit source.

    Limitations
    • Correlation supports an assessment but does not reveal how a user was persuaded to complete the device-code flow.
    • The available audit sequence does not measure control efficacy in another environment.

    Both variants depend on vendor cloud-audit fields that are not guaranteed by a common Splunk data model.

    More reasoning

    Observation

    Independent cloud audit records showed resource access by the same account, application, and session context.

    Working explanation

    If the cloud operation aligns with the correlated session and conflicts with the approved workflow, unauthorized session use becomes the stronger explanation.

    What was checked

    Search cloud audit telemetry for the account, application, and session context during the bounded scenario window.

    Interpretation

    Cross-telemetry agreement linked the device-code grant, subsequent session use, and mailbox activity. Unauthorized session use became the strongest explanation.

    Supporting evidence
    Confidence changedModeratetoHigh

    Independent cloud audit evidence corroborated the same account, application, session context, address, and resource activity, weakening the remaining benign explanations.

  4. Bound the response

    The session was revoked and later access attempts were blocked.

    More reasoning

    Observation

    The correlated session was still eligible for cloud-resource access when the assessment was made.

    Working explanation

    Revoking the bounded session context should stop subsequent activity associated with that context, while not proving the original authentication cause.

    What was checked

    Revoke SESSION-LAB-042 in the test control plane and review subsequent access results.

    Interpretation

    The evidence supports high confidence that the session was used without authorization. Revocation stopped the activity associated with that session.

    Supporting evidence

Response

Actions to take

Contain affected systems, preserve evidence, and scope the same behavior elsewhere.
  • Revoke the affected session and refresh tokens.
  • Review mailbox and cloud activity performed through the correlated application and session.
  • Confirm whether the user intentionally completed the device-code flow and revoke unapproved application consent.
  • Search for the same application, session pattern, and post-authentication activity across the tenant.
  • Reset the user's credentials only if the investigation supports credential exposure.

Conclusion

What was concluded

The device-code sign-in alone did not prove malicious activity. The conclusion became defensible when authentication and cloud audit records showed the same account, application, and session moving to another network before accessing mailbox data.

The approved-workflow review did not explain the activity, and session revocation stopped subsequent access. The evidence therefore supports unauthorized session use with high confidence, while leaving the original social-engineering path outside the available evidence.

Technical detail

Technical evidence

Stable evidence anchors preserve the fields behind the investigation story.
E-01

E-01 — Authentication event

Source
IDENTITY-LAB-01
Telemetry class
Authentication
Timestamp

A successful device-code grant was recorded for the user and application.

Account
riley.chen@example.com
Tenant
tenant-lab-001
Source IP
198.51.100.24
Grant type
device_code
Application ID
APP-LAB-042
Session context ID
SESSION-LAB-042
Result
success
Referenced by
E-02

E-02 — Identity telemetry

Source
IDENTITY-INVENTORY-LAB
Telemetry class
Identity
Timestamp

The expected managed-device record showed no approved device-code workflow during the scenario window.

Account
riley.chen@example.com
Expected device
WS-EX-2123
Expected source IP
192.0.2.18
Approved device code workflow
false
Inventory review ID
REVIEW-LAB-042
Referenced by
E-03

E-03 — Authentication event

Source
SESSION-AUDIT-LAB
Telemetry class
Authentication
Timestamp

The same session context was used from a second TEST-NET address shortly after the device-code grant.

Account
riley.chen@example.com
Source IP
203.0.113.77
Application ID
APP-LAB-042
Session context ID
SESSION-LAB-042
Operation
session_use
Result
success
Referenced by
E-04

E-04 — Cloud audit event

Source
CLOUD-AUDIT-LAB
Telemetry class
Saas Audit
Timestamp

Independent cloud audit records associated the same application and session context with mailbox-resource access.

Actor
riley.chen@example.com
Source IP
203.0.113.77
Application ID
APP-LAB-042
Session context ID
SESSION-LAB-042
Operation
list_messages
Resource
mailbox-riley-lab
Result
success
Referenced by
E-05

E-05 — Cloud control-plane event

Source
CLOUD-CONTROL-LAB
Telemetry class
Cloud Control Plane
Timestamp

The session context was revoked, and subsequent access attempts were denied in the scenario.

Account
riley.chen@example.com
Session context ID
SESSION-LAB-042
Operation
revoke_session
Control event ID
CONTROL-LAB-042
Subsequent access
denied
Referenced by

Detection engineering

Would your SOC catch this behavior?

See the detection built for this investigation.
View detection

Behavior context

ATT&CK and sources

Behavior mapping

MITRE ATT&CK

  • T1078 · Valid AccountsEnterprise ATT&CK 19.2

    The scenario examines successful sign-in activity where authentication alone does not establish authorization.

  • The scenario examines behavior consistent with unauthorized use of an application session without reproducing token material.

These mappings describe the behavior examined here. They do not establish attribution.

Review boundary

Sources and limits

Last reviewed

This case documents the available evidence and analytical limits; control effectiveness is environment-specific.

Page navigation

Sections