Investigate Suspicious Sign-ins

Know which evidence is available

Microsoft 365 Business Standard can investigate recent sign-ins in the portal, but retention and advanced risk features depend on Entra licensing. Never treat a missing premium signal as proof that the activity is safe.

Least-privilege action map

Know which signal you are checking

Start with the original signal. A suspicious sign-in is a question to answer, not an automatic finding of compromise.

What to do

• Preserve the original alert or reportSave the alert ID, reporter, time, affected UPN and exact question that must be answered.
• Set a narrow UTC windowBegin with 30 minutes before and after the event. Expand only when the evidence requires it.
• Identify sensitivityNote administrator roles, finance or executive duties, privileged applications and regulated data access.

Classify the event before acting

Answer who, how and what. Then decide whether the event is safe, a technical problem, suspicious, or part of a broader attack.

What to do

• Identify the sign-in typeUser interactive, user non-interactive, service principal or managed identity. Do not interpret them as the same event.
• Read Status and error codeSuccess can mean a token was issued. Failure means that attempt failed. Interrupted often means another control or user step was required.
• WhoConfirm User ID, UPN, tenant, identity type, roles and whether the account was disabled or recently changed.
• Establish the tenant boundaryFor a guest or external identity, record user type, Cross-tenant access type, Home tenant ID and Resource tenant ID.
• HowReview authentication requirement, methods and sequence, client app, browser or user agent, Conditional Access and token protection details.
• WhatReview application, resource, IP, device, location, risk, Request ID and Correlation ID.
• Confirm with the user safelyAsk about the UTC time, application and action through a known separate channel. Do not reveal the expected answer.

Contain only when the decision supports it

This child SOP decides whether containment is needed. The Compromised Account SOP owns the disable, session revocation, password, MFA and persistence actions.

What to preserve before containment

• Event identifiersRequest ID, Correlation ID, UTC time and the source alert or risk-detection ID.
• Original exportsInteractive and non-interactive CSV or JSON files with the exact filters recorded.
• Current stateRisk status, account status, roles, authentication methods and relevant Conditional Access result.

Analyse the sign-in step by step

Use the portal first. It exposes the event in a form that is quick to compare and easy to export. Use Graph only when the tenant is licensed and the query materially helps.

1. Export interactive and non-interactive logs

• User sign-ins, interactiveOpen this tab, keep the user and UTC filters, select Download, then export CSV or JSON.
• User sign-ins, non-interactiveOpen this tab and export it separately. Expand grouped rows because one row can represent several attempts.
• Record the export contextSave the UTC range, filters, export time, operator and tenant. Keep the original files read-only.

2. Read one event in a fixed order

3. Compare, do not judge one field alone

• Compare the user's normal patternReview earlier successful sign-ins for the same applications, devices, locations, IP ranges and authentication methods.
• Search the tenant for related activityFilter the same IP, application, browser, device or UTC window across users. Look for spray, shared infrastructure or coordinated activity.
• Open risk details when licensedReview detection type, timing, risk history and linked user risk. Treat the Microsoft signal as evidence, not the entire verdict.
• Use Sign-in diagnostic for failuresOpen a failed event → Basic info → Launch the Sign-in diagnostic. Use its explanation for troubleshooting, not as a security clearance.

# Read-only example. Requires Entra ID P1/P2 and an authorized reader role.
$ErrorActionPreference = 'Stop'
Import-Module Microsoft.Graph.Reports
$tenantId = [guid](Read-Host 'Tenant ID (GUID)')
if ($tenantId -eq [guid]::Empty) { throw 'A tenant ID is required.' }
$upn = (Read-Host 'Exact user principal name').Trim()
if (-not $upn -or $upn.Contains("'")) { throw 'Enter a valid user principal name.' }
$startInput = Read-Host 'Start, with UTC offset (e.g. 2026-09-15T08:00:00Z)'
$endInput = Read-Host 'End, with UTC offset (e.g. 2026-09-15T10:00:00Z)'
if ($startInput -notmatch 'T.*(Z|[+-][0-9]{2}:[0-9]{2})$' -or $endInput -notmatch 'T.*(Z|[+-][0-9]{2}:[0-9]{2})$') {
  throw 'Both timestamps must include Z or an explicit UTC offset.'
}
$startUtc = [datetimeoffset]::Parse($startInput, [cultureinfo]::InvariantCulture)
$endUtc = [datetimeoffset]::Parse($endInput, [cultureinfo]::InvariantCulture)
if ($endUtc -le $startUtc) { throw 'End must be after start.' }
$start = $startUtc.UtcDateTime.ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ", [cultureinfo]::InvariantCulture)
$end = $endUtc.UtcDateTime.ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ", [cultureinfo]::InvariantCulture)

$connected = $false
try {
  Connect-MgGraph -TenantId $tenantId -ContextScope Process -Scopes 'AuditLog.Read.All'
  $connected = $true
  if ([guid](Get-MgContext).TenantId -ne $tenantId) { throw 'Wrong tenant context.' }
  $filter = "userPrincipalName eq '$upn' and createdDateTime ge $start and createdDateTime lt $end"
  Get-MgAuditLogSignIn -Filter $filter -All |
    Select-Object Id,CreatedDateTime,UserPrincipalName,IsInteractive,
      AppDisplayName,ResourceDisplayName,IpAddress,ClientAppUsed,
      ConditionalAccessStatus,CorrelationId,
      @{Name='ErrorCode';Expression={$_.Status.ErrorCode}}
  # This selected-field view does not preserve the full event. Keep original exports.
} finally {
  if ($connected) { Disconnect-MgGraph }
}

Record one clear outcome

The outcome must explain the evidence and the next action. Do not dismiss risk simply to remove an alert.

These outcomes describe the investigated event and time window. They do not certify that every session or the whole account is safe. Missing coverage stays explicit.

What to do

• Select one outcomeSafe, Troubleshooting, Unresolved, Suspicious or Broader attack. Record confidence and conflicting evidence.
• Update risk state carefullyDismiss only a confirmed false or benign result. Confirm compromise only after investigation and start containment immediately.
• Link the next recordAdd the support ticket or parent Compromised Account incident ID so the reasoning is traceable.
• Validate the resultFor troubleshooting, reproduce a successful protected sign-in. For compromise, validate through the parent SOP closure gate.

Make the next event easier to prevent and explain

Turn the investigation gap into a small, owned improvement. Prefer controls that reduce attack opportunity and preserve better evidence.

What to do

• Write the observed gapFor example: no history beyond seven days, unmanaged legacy client, weak MFA, or no owner for risky-user alerts.
• Create one owned actionGive it an owner, due date, success test and rollback plan.
• Test the detection and responseConfirm the alert arrives, the right role can investigate, exports work, and escalation reaches the incident owner.

Preserve a decision another admin can reproduce

A screenshot is helpful context, but the original export, identifiers, filters and reasoning are the evidence that make the decision repeatable.

What to preserve

• Source and scopeTenant, UPN, alert or report, UTC window, filters, export time and operator.
• Original filesSeparate interactive and non-interactive CSV or JSON exports. Preserve filenames and do not overwrite them.
• Integrity hashesCalculate and record a SHA-256 hash for every original export before working from a copy.
• Exact eventResult, error code, Request ID, Correlation ID, application, resource, IP, device, authentication, Conditional Access, risk and available token identifiers.
• User statementWho contacted the user, which trusted channel was used, the exact question, answer and UTC time.
• Comparison and limitationsNormal pattern, related tenant search, evidence that supports and contradicts the conclusion, retention and licensing gaps.
• Decision and next recordOutcome, confidence, approver, risk-state action and linked support or compromised-account incident.

CASE / ALERT ID:
TENANT:
USER PRINCIPAL NAME:
SIGNAL AND SOURCE:
UTC WINDOW AND FILTERS:
EVENT UTC / RESULT / ERROR CODE:
REQUEST ID / CORRELATION ID:
APPLICATION / RESOURCE / CLIENT APP:
IP / LOCATION / DEVICE / USER AGENT:
AUTHENTICATION DETAILS:
CONDITIONAL ACCESS:
RISK DETAILS:
USER CONFIRMATION AND CHANNEL:
RELATED TENANT ACTIVITY:
ORIGINAL EXPORT FILENAMES:
ORIGINAL EXPORT SHA-256 HASHES:
KNOWN DATA OR LICENSE LIMITATIONS:
DECISION: SAFE | TROUBLESHOOTING | UNRESOLVED | SUSPICIOUS | BROADER ATTACK
CONFIDENCE AND REASON:
NEXT RECORD / OWNER / UTC TIME:

For a JSON export, the local evidence inspector can hash the file and summarize supplied records without uploading it. Counts are not a safety verdict. Keep this detailed note internally and redact identities before an external enquiry.

Get-FileHash -LiteralPath "<original-export.csv>" -Algorithm SHA256

Keep the decision owned

One person owns the investigation and conclusion. Specialist owners join only where their systems or authority are needed.

Escalate immediately when

• Privileged or critical identityAdministrator, emergency access, service, executive, finance or another high-impact identity.
• Denied successful accessThe user denies a successful event, a suspicious token exists, or access continued without prompts.
• Multiple users or shared attacker patternPassword spray, same malicious IP, suspicious application, token pattern or coordinated activity.
• Unknown application or service principalUnexpected OAuth consent, unfamiliar resource, workload identity or tenant-wide permission.
• Data, fraud or device riskRegulated data, mass download, payment activity, malware, token theft or unmanaged device.
• User cannot be reachedTreat unresolved successful activity conservatively, especially for sensitive identities.

Closure gate

• Outcome is explicitSafe, Troubleshooting, Unresolved, Suspicious or Broader attack, with confidence and reason.
• Evidence is reproducibleExports, identifiers, user statement, comparison and limitations are stored.
• Risk state is accurateRisk is not dismissed merely to close the alert.
• Next work is linked and ownedSupport fix, prevention action or Compromised Account incident has an owner and tracking reference.