ArcanaIncident-response documentationBrowse the feedTemplates
Back to feed
Runbook · Evidence
RB-EVIDENCE-003

Identity & Authentication Log Acquisition

1. Prerequisites

  • Impacted identity (UPN/email, user ID, service principal ID, service account name, or API key ID)
  • Incident time window (the period over which activity is to be reviewed)
  • Authorisation to query identity and SaaS / application logs for the impacted identity
  • Access to the systems carrying the identity's auth and activity logs, which may include:
    • The identity provider (IdP) used to manage the identity if federated (e.g. Microsoft Entra ID, Okta, Google Workspace, Ping, Auth0, AWS IAM Identity Center)
    • The SaaS / cloud platforms the identity has access to (e.g. Microsoft 365, Google Workspace, Salesforce, Slack, GitHub, AWS, Azure, GCP)
    • The SaaS / application platform that the account belongs to, if it's a local account not tied to SSO (e.g. a standalone Salesforce account, personal GitHub account)
    • The VPN / network appliance the account authenticates through, where applicable (e.g. VPN concentrator, RADIUS server, bastion host)
    • On-premises Active Directory and its audit logs where the identity is AD-managed
    • The SIEM / central log platform if identity or auth logs are forwarded there

Required Tools:

  • IdP administrative console and/or API (e.g. Microsoft Graph, Okta API, Google Admin SDK, AWS CLI/IAM Identity Center API)
  • SaaS / application admin console and/or audit log API for each platform in scope
  • Network / VPN / bastion appliance admin interface (where applicable)
  • SIEM query interface

2. Step-by-Step Instructions

Common Failure Modes

  • Pulling only IdP sign-in logs and missing downstream SaaS audit logs (where the actual attacker actions occurred)
  • Assuming an IdP carries the auth log when the account is local to the SaaS / application (no SSO)
  • Forgetting non-human identities (service principals, service accounts, workload identities, API keys)
  • Missing logs that have already aged out of the platform's short retention window (e.g. Entra ID sign-in logs default 30 days)
  • Failing to scope cross-tenant or federated activity (B2B guest access, federated identity, SSO downstream apps)
  • Querying only successful authentications and missing failed-auth volume patterns that confirm brute force, password spray, or credential stuffing
  • Allowing the suspect identity to alter or delete logs by not snapshotting first when admin compromise is suspected

  1. Validate Need and Scope of Log Acquisition

    • Confirm the identity is in scope for the incident and define the time window of interest
    • Identify whether the identity is human or non-human (service principal, service account, workload identity, API key, OAuth app), as this dictates which log categories apply
    • Identify the authentication path for the impacted account, as this dictates where the auth log lives:
      • Federated / SSO (IdP-fronted) — the IdP carries the auth log; the downstream SaaS carries activity logs
      • Local SaaS / application account (no SSO) — the SaaS / application platform carries both auth and activity logs
      • Network / VPN / RADIUS / bastion account — the appliance carries the auth log
      • API / programmatic credential (token, key, secret) — the platform's API / audit log carries the auth event
    • List all platforms the identity has access to; these are all in scope
    • Where possible, preserve logs centrally first (SIEM, IdP, SaaS audit) to guard against tampering, especially where admin or IdP-level compromise is suspected

  2. Collect Relevant Identity Activity Logs

    • Identify which categories of activity are relevant to the incident and collect them from whichever source carries them (IdP, SaaS / application audit, network appliance, SIEM). Common categories and where they typically live:
      • Authentication / sign-in events (successful, failed, risk-scored, conditional-access decisions, source IP/ASN/geo, user-agent, device ID, session ID)
        • If federated (SSO): IdP sign-in logs (Entra ID Sign-ins, Okta System Log, Google Login Audit, Auth0 logs, AWS CloudTrail ConsoleLogin, AWS IAM Identity Center sign-ins)
        • If local SaaS / application account: the platform's own auth log (e.g. Salesforce LoginHistory, GitHub user.login, Slack user_login, WordPress login log, application access log)
        • If network / VPN / bastion: appliance auth log (RADIUS, TACACS+, VPN appliance log, bastion session log)
        • If API / programmatic credential: platform API audit (CloudTrail, Azure Activity, GCP Audit Logs, GitHub Audit, M365 Unified Audit) — look for the API key / token's principal in the actor field
      • Brute force / spray / stuffing patterns (high-volume failed auths against one or many accounts)
        • All paths: the same auth logs as above, but queried for failed-auth volume, rate, source IP diversity, and account diversity rather than single-event success/fail
        • Look for fail-then-success patterns (compromise confirmation), low-and-slow patterns, and geo/ASN concentration
      • MFA events (factor used, factor challenged/denied, factor enrolment, factor removal, MFA fatigue patterns)
        • If federated: IdP MFA logs (Entra ID Authentication Methods + Sign-ins, Okta System Log MFA events, Google 2SV logs)
        • If local SaaS / application account: the platform's own MFA log (e.g. GitHub 2FA events, AWS MFA events in CloudTrail, per-app TOTP/U2F logs)
        • If account has no MFA enabled: record this as a finding — the absence of MFA is itself key evidence and a recovery-time hardening requirement
      • Session and token events (token issuance, refresh, revocation, sign-out, suspicious token reuse)
        • If federated: IdP token logs (Entra ID token issuance via Sign-ins, Okta token events, Google OAuth token logs)
        • If local SaaS / application account: the platform's session log (session creation / expiry / revocation events in app audit logs)
        • If API / programmatic credential: token issuance / refresh events in the platform's audit log
      • OAuth / consent / application access (consent grants, admin consent, application access, service principal sign-ins, app role assignments)
        • If federated: IdP consent logs (Entra ID Audit + Sign-ins for service principals, Okta OAuth events, Google OAuth Token audit)
        • If local SaaS / application account: per-app access logs where the SaaS records third-party app activity (e.g. GitHub OAuth app authorizations, Slack app installs)
      • Directory / identity management events (account create / delete / disable, password reset, role assignment, group membership change, privileged role activation, federation / trust changes, sync account activity)
        • If federated: IdP audit logs (Entra ID Audit, Okta System Log, Google Admin Audit, AWS IAM CloudTrail)
        • If local SaaS / application account: the platform's admin / audit log (e.g. GitHub audit log for org/repo permission changes, Salesforce Setup Audit Trail, Slack audit logs API for admin actions)
        • If on-premises Active Directory: Security log (4720/4722/4723/4724/4725/4726/4728/4732/4738/4756), Directory Service log
      • SaaS / application activity (actions taken by the identity inside the platform — file access, sharing, configuration changes, data exports, admin actions)
        • The platform's audit log (M365 Unified Audit Log, Google Workspace Drive/Admin Audit, Salesforce Setup Audit Trail, Slack Audit Logs API, GitHub Audit Log, AWS CloudTrail data events)
      • Mailbox-specific events (inbox rule changes, forwarding rule changes, delegate access, mailbox permission changes, message send / read from new sources)
        • Email platform audit (M365 Exchange Audit / Unified Audit Log, Google Workspace Gmail audit)
      • Conditional access / policy decisions (policy applied, policy result, MFA required, block, session control applied)
        • If federated: IdP conditional access logs (Entra ID Sign-ins conditional access details, Okta policy evaluation events)
        • If local SaaS / application account: platform-side access policy logs where available (e.g. IP allow-list deny events)
      • Risk and detection signals raised by the IdP / platform identity protection (risky user, risky sign-in, leaked credentials, anomalous travel, anomalous token use)
        • If federated: IdP identity protection (Entra ID Identity Protection, Okta ThreatInsight, Google Security Center)
        • If local SaaS / application account: platform-native security signals (e.g. GitHub leaked-secret alerts, Salesforce Real-Time Event Monitoring threat events)
    • For each relevant category, prefer querying or exporting from your SIEM / IdP / platform admin console where the data is centralised; query directly via API for categories not centralised
    • Record the query, time range, and access location for each category collected

  3. Collect Centralised Logs from the SIEM

    • Export matching events from the SIEM or central log platform for the impacted identity over the incident window
    • Include any enriched or correlated identity alerts for the impacted identity
    • Record the query, time range, and export location

  4. Scope to Adjacent Identities and Shared Indicators

    • Identify shared indicators from the impacted identity's activity (source IPs, ASNs, user-agents, device IDs, OAuth application IDs, MFA factor metadata, session/correlation IDs)
    • Re-run the relevant queries across the IdP and SaaS / application audit logs using these indicators to surface adjacent compromised identities
    • Record findings and feed back into the incident scope

3. Post-Action

  • Where logs are exported as files, transfer to the designated evidence storage location via a secure path; verify SHA-256 hashes match before and after transfer
  • Record acquisition metadata: operator, timestamp, identity, sources collected, time range, tools / queries used, and (for exported files) the SHA-256 hash of the resulting archive
  • Confirm chain of custody is recorded end-to-end where files were exported (collection → transfer → storage)
  • Hand off to the analyst responsible for log review and update the incident ticket with the evidence reference

Contributor

Jayden Vo GitHub: https://github.com/jayden-vo

Contributed to the Arcana Incident Response Documentation Framework.