SOCLIFE
SOCLIFE

Evidence-led security analysis

Published knowledge

Search SOC//LIFE

HuntsHUNT-001

Hypothesis-led threat hunting

Hunt cloud activity after device-code sign-in

Search across the environment for other users and applications showing device-code sign-ins followed by suspicious cloud activity.

Question

Hunt goal

Find other users who completed device-code sign-ins and then showed cloud activity through the same or similarly unexpected applications.

Why this hunt

Searching across users, applications, network contexts, and follow-on cloud actions can reveal whether the behavior extends beyond the original account.

Data sources

Where to look

  • AuthenticationSuccessful sign-in records with account, application, grant, source, result, time, and any available session identifier.
  • SaaS AuditCloud-resource operations with actor, application, operation, resource, result, source, time, and any available session identifier.
  • IdentityReviewed account, application, device, workflow, owner, and review-validity context used to test legitimate explanations.

Search path

Hunt steps

Each search broadens the view from patient zero to related users, devices, infrastructure, and follow-on activity.
  1. Step 1First search

    Find other users with device-code sign-ins

    Finding

    The search identified device-code sign-ins across the scoped workforce accounts, including records without a usable session ID.

    These sign-ins establish the users, applications, networks, and times to carry into the wider cloud-activity search.

    View query
    Q-01First search

    Find other users with device-code sign-ins

    What this checks

    Find other workforce accounts that completed device-code sign-ins and preserve the application, network, and session context available for follow-up.

    KQL
    SigninLogs
| where TimeGenerated between (datetime(2026-08-19T09:00:00Z) .. datetime(2026-08-19T11:00:00Z))
| where AuthenticationProtocol == "device_code"
| where ResultType == 0
| where isempty(SessionId)
| project TimeGenerated, AccountObjectId, UserPrincipalName, ApplicationId, SourceIp, SessionId
    SPL
    | datamodel Authentication Authentication search
| search _time>=1787130000 _time<=1787137200 Authentication.authentication_method="device_code" Authentication.action="success"
| rename Authentication.* AS *
| where isnull(session_id) OR len(trim(session_id))=0
| table _time user user_id app src session_id
    What to look for

    A review set of users, applications, source contexts, and sign-in times that can be compared with follow-on cloud activity.

    Technical details
    Tested signal

    Successful device-code authentication with normalized account and application context but no usable cross-service session identifier.

    Assumptions
    • AuthenticationProtocol consistently identifies device-code sign-ins in the authored records.
    • An empty SessionId represents unavailable correlation data rather than a parsing failure.
    Data requirements and relevant fields
    authentication

    Successful device-code sign-ins with account, application, source, result, time, and session context.

    • TimeGenerated
    • AccountObjectId
    • UserPrincipalName
    • ApplicationId
    • AuthenticationProtocol
    • SourceIp
    • ResultType
    • SessionId
    KQL schema

    SigninLogs and its protocol, result, account, application, source, and session fields are illustrative mappings.

    SPL schema

    The epoch bounds preserve the authored UTC review window. Common authentication fields may use CIM aliases, but authentication_method, user_id, and session_id require validation against the selected source.

    Limitations
    • Missing SessionId prevents a strong event-level correlation.
    • Successful device-code authentication may be legitimate and cannot establish user intent.

    Both variants require source-specific device-code and session fields; CIM does not guarantee either field.

  2. Step 2Pivot

    Follow cloud activity after each sign-in

    Finding

    Cloud-resource operations followed some sign-ins for the same user and application, but no shared session identifier linked the events directly.

    The candidates deserve workflow review, while the missing session identifier prevents a high-confidence event-level link.

    View query
    Q-02Pivot

    Follow cloud activity after each sign-in

    What this checks

    Find mailbox and cloud operations after each candidate sign-in while preserving the limits of account, application, and time-based correlation.

    KQL
    let CandidateSignIns =
    SigninLogs
    | where TimeGenerated between (datetime(2026-08-19T09:00:00Z) .. datetime(2026-08-19T11:00:00Z))
    | where AuthenticationProtocol == "device_code" and ResultType == 0
    | where isempty(SessionId)
    | project SignInTime = TimeGenerated, AccountObjectId, UserPrincipalName, ApplicationId, SignInSourceIp = SourceIp;
CloudAppEvents
| join kind=inner CandidateSignIns on AccountObjectId, ApplicationId
| where TimeGenerated between (SignInTime .. SignInTime + 30m)
| project SignInTime, TimeGenerated, UserPrincipalName, ApplicationId, SignInSourceIp, SourceIp, Operation, Resource, Result
    SPL
    earliest=1787130000 latest=1787137200 ((index=authentication authentication_method="device_code" action="success") OR index=cloud_audit)
| eval account_id=coalesce(account_id, actor_id)
| eventstats earliest(eval(if(index="authentication" AND (isnull(session_id) OR len(trim(session_id))=0), _time, null()))) AS sign_in_time
    values(eval(if(index="authentication" AND (isnull(session_id) OR len(trim(session_id))=0), src, null()))) AS sign_in_sources
    by account_id app
| where index="cloud_audit" AND _time >= sign_in_time AND _time <= relative_time(sign_in_time, "+30m")
| table sign_in_time _time account_id user app sign_in_sources src action resource result
    What to look for

    A candidate sequence where a user and application perform cloud operations shortly after device-code authentication.

    Technical details
    Tested signal

    Cloud activity for the same normalized account and application within thirty minutes of the incomplete device-code sign-in context.

    Assumptions
    • AccountObjectId and ApplicationId have the same meaning in authentication and cloud audit telemetry.
    • The thirty-minute window is a bounded investigative choice, not an empirically validated production threshold.
    Data requirements and relevant fields
    authentication

    Candidate sign-ins with normalized account, application, source, time, result, and session context.

    • TimeGenerated
    • AccountObjectId
    • UserPrincipalName
    • ApplicationId
    • AuthenticationProtocol
    • SourceIp
    • ResultType
    • SessionId
    saas audit

    Cloud operations with matching account and application plus operation, resource, result, source, and time context.

    • TimeGenerated
    • AccountObjectId
    • UserPrincipalName
    • ApplicationId
    • Operation
    • Resource
    • Result
    • SourceIp
    KQL schema

    SigninLogs and CloudAppEvents require normalized account and application identifiers plus comparable timestamps.

    SPL schema

    The epoch bounds preserve the authored UTC review window. Index names and account_id, actor_id, app, session_id, action, and resource fields require source-specific normalization.

    Limitations
    • The join can associate unrelated activity performed by the same account and application.
    • A narrow time window reduces noise but does not create causality.
    • Cloud activity alone cannot show who initiated the device-code flow.

    Both variants use a deliberately weaker time-bounded account and application correlation because no shared session identifier exists.

  3. Step 3Hypothesis check

    Check whether each application and workflow is expected

    Finding

    The expected-workflow inventory did not explain the candidate application, but the available records could not attribute the cloud operations to the same session.

    The application mismatch keeps the candidates suspicious, while the missing session context prevents confirmation of wider compromise.

    View query
    Q-03Hypothesis check

    Check whether each application and workflow is expected

    What this checks

    Challenge the suspicious-use hypothesis with reviewed identity, application, device, and workflow context.

    KQL
    let CandidateAccount = "USER-LAB-042";
let CandidateApplication = "APP-LAB-042";
IdentityInfo
| where AccountObjectId == CandidateAccount
| project AccountObjectId, UserPrincipalName, ExpectedApplicationId, ExpectedDeviceId, ApprovedWorkflow, WorkflowOwner, ReviewValidUntil
| extend ApplicationMatches = ExpectedApplicationId == CandidateApplication
    SPL
    | inputlookup expected_identity_workflows.csv
| search account_id="USER-LAB-042"
| eval application_matches=if(expected_app="APP-LAB-042", "yes", "no")
| table account_id user expected_app expected_device approved_workflow workflow_owner review_valid_until application_matches
    What to look for

    Current documentation that explains the activity or identifies the user, application, device, or workflow that still requires investigation.

    Technical details
    Tested signal

    Whether a current approved workflow explains the candidate account, application, and expected device context.

    Assumptions
    • IdentityInfo is current through the recorded ReviewValidUntil date.
    • Absence of an approved workflow weakens a legitimate explanation but does not prove unauthorized activity.
    Data requirements and relevant fields
    identity

    Current expected application, device, workflow, owner, and review-validity context for the candidate account.

    • AccountObjectId
    • UserPrincipalName
    • ExpectedApplicationId
    • ExpectedDeviceId
    • ApprovedWorkflow
    • WorkflowOwner
    • ReviewValidUntil
    KQL schema

    IdentityInfo and its workflow ownership and review-validity fields are illustrative mappings.

    SPL schema

    The lookup and fields must map to a maintained CSV or KV Store collection with explicit workflow ownership and review validity.

    Limitations
    • Identity inventory can be incomplete or stale even when a review date is present.
    • Human confirmation would still be required in a real environment.

    Both variants depend on a locally governed identity/workflow inventory, not a universal SIEM data model.

Blast radius

Wider-compromise pivots

  • Search for the same application across other users and business units.
  • Compare requested permissions and cloud operations across similar applications.
  • Follow stable session identifiers wherever identity and cloud logs preserve them.
  • Compare source IPs and network context across candidate sign-ins.
  • Review mailbox and cloud-resource activity after each candidate sign-in.
  • Check whether the same publisher, workflow, or application appears elsewhere in the tenant.

Evidence threshold

What would increase confidence

  • A stable session identifier links authentication and cloud activity for another user.
  • Multiple users show the same application and post-sign-in cloud behavior.
  • Independent device or application records confirm that the activity was not approved.
  • The same source context or infrastructure appears across otherwise unrelated accounts.

Conclusion

Result and next action

Wider compromise was not confirmed. Preserve the candidate users and applications for follow-up, and improve session correlation before promoting the weaker pattern into detection logic.

  • Review the candidate users and applications with the workflow owner.
  • Preserve the sign-in and cloud-audit records needed for session-level correlation.
  • Scope the same application and consent pattern across the tenant.
  • Improve logging where session identifiers are absent from either telemetry source.

The wider search remained useful even though it did not confirm additional compromised sessions. It identified the users and applications that require follow-up and made the missing session join visible.

Account, application, and time can guide a hunt, but they cannot replace a stable session identifier for a higher-confidence conclusion. The next step is to review the candidates and improve the identity-to-cloud correlation boundary.

Context

ATT&CK and limits

Behavior mapping

MITRE ATT&CK

  • T1078 · Valid Accounts

    The hunt examines successful use of a valid account outside its documented application workflow without claiming credential or token theft.

This mapping describes the valid-account behavior examined by the Hunt. It does not prove token theft, attribution, or technique-wide coverage.

Review boundary

Sources and limits

The conclusion stays bounded to the stated scope and available logs.

Page navigation

Sections