SaaS Log Sources — M365, Okta, and the Unified Audit Log

Modern organizations don’t just live in AWS or Azure — they live in Microsoft 365, Salesforce, Okta, and Slack. SaaS platforms are where attackers find the data and where they establish persistence. Detection requires pulling logs from all of them.

The SaaS Detection Challenge

On-prem detection: install Sysmon on every host, ingest to SIEM, done. SaaS detection: every vendor has a different API, different log format, different retention policy, different pricing model for log access, and different event taxonomy. There is no standard.

The practical approach:

Identify which SaaS platforms your organization uses for sensitive data or authentication
Enable audit logging in each (not always on by default)
Build SIEM connectors (most vendors provide Splunk/Sentinel/Elastic integrations)
Write detections starting with identity events (authentication, admin changes)

Microsoft 365 Unified Audit Log

The UAL covers all M365 services in one log stream. Query via PowerShell or the Compliance Center UI:

# Retrieve audit log for a user suspected of BEC
Search-UnifiedAuditLog -StartDate "2026-05-10" -EndDate "2026-05-20" `
  -UserIds "alice@corp.com" `
  -Operations "New-InboxRule","Set-InboxRule","Add-MailboxPermission","Set-Mailbox" `
  -ResultSize 1000 | Select-Object CreationDate, Operations, UserIds, AuditData

Detection Pattern 1: Inbox Rule Exfiltration (BEC)

title: Exchange Online — Suspicious Inbox Rule to External Address
logsource:
  product: m365
  service: exchange
detection:
  selection:
    Operation:
      - "New-InboxRule"
      - "Set-InboxRule"
  selection_external_forward:
    Parameters|contains:
      - "ForwardTo"
      - "ForwardAsAttachmentTo"
      - "RedirectTo"
  selection_external_domain:
    AuditData|contains: "@gmail.com"   # adapt to known-external domains
  condition: selection and selection_external_forward
falsepositives:
  - Legitimate out-of-office forwarding to personal email (document in baseline)
level: high

title: M365 OAuth Application — High-Permission Consent Granted
logsource:
  product: azure
  service: auditlog
detection:
  selection:
    ActivityDisplayName: "Consent to application"
  selection_high_perm:
    ModifiedProperties.NewValue|contains:
      - "Mail.Read"
      - "Mail.Send"
      - "Files.ReadWrite.All"
      - "Directory.ReadWrite.All"
  condition: selection and selection_high_perm
falsepositives:
  - Legitimate business app integrated with M365 (must be reviewed case by case)
level: high

Hunting complement: Query all OAuth apps granted Mail.Read or Files.ReadWrite.All in the past 90 days. Identify apps not in your approved application catalog.

Okta System Log: The SSO Chokepoint

Okta System Log events critical for detection:

Event	Signal
`user.authentication.auth_via_mfa` with `factor.type=SMS` and `outcome.result=FAILURE`	MFA OTP failure (possible OTP phishing or SIM swap)
`user.account.update_password`	Password changed (may follow account takeover)
`policy.rule.update` — MFA policy	MFA requirement weakened
`application.lifecycle.update` — new app added	New SSO app configured (possible persistence)
`user.session.impersonation.initiate`	Admin impersonating a user
`security.threat.detected` — anomalous device	Okta ThreatInsight flagged suspicious login

title: Okta — Admin Role Granted to User
logsource:
  product: okta
  service: system_log
detection:
  selection:
    eventType: "group.user_membership.add"
    target.displayName|contains: "Okta Admin"
  condition: selection
level: critical

Correlating Across SaaS Platforms

The most valuable detections connect events across platforms:

OKTA LOGIN (success, new IP) → EXCHANGE INBOX RULE CREATED → SHAREPOINT DATA DOWNLOAD
     │                                │                              │
[Okta System Log]          [M365 Unified Audit Log]      [M365 UAL or SharePoint Logs]

This is a classic BEC sequence:

Attacker logs in via Okta SSO from a new IP (Okta log)
Creates inbox forwarding rule (Exchange UAL)
Downloads files from SharePoint (SharePoint UAL)

Each event alone might be a tuning problem. Together, they’re a high-confidence BEC. SIEM correlation rules should look for this sequence within a 1-hour window per user.

SaaS Log Maturity Checklist

Before writing SaaS detection rules, verify each:

□ Audit logging enabled and confirmed flowing to SIEM
□ Log retention period known and documented (90 days? 1 year?)
□ Admin activity events confirmed (user creation, role grants, policy changes)
□ Authentication events confirmed (login success/failure, MFA outcomes)
□ Data access events confirmed (file access, email access) — often separate/opt-in
□ SIEM field mapping validated (event names, usernames, timestamps in correct fields)
□ Alert for logging gaps (if Okta events stop flowing for > 5 minutes, alert immediately)

M365 Unified Audit Log— Microsoft Okta System Log API— Okta

Retrieval Practice

An analyst finds that a user account (jsmith@corp.com) created a new inbox rule in Exchange Online to forward all email matching 'invoice' or 'payment' to external-email@gmail.com. jsmith claims he didn't create the rule. Walk through the full investigation sequence and the SIEM queries you'd run.

Reveal answer

Step 1: Establish the compromise timeline. Query Okta System Log (or Entra ID Sign-in Logs) for jsmith@corp.com authentications in the past 7 days — show source IP, country, device, and MFA outcome. Look for: logins from new IPs or countries, especially ones that preceded the inbox rule creation. Step 2: Pull the UAL event for the inbox rule. Search-UnifiedAuditLog for jsmith, operation New-InboxRule — get the full AuditData JSON including ClientInfoString (what client created the rule — 'Client=OWA' is browser, 'Client=Outlook/16.x' is desktop, 'EWSClient' may be attacker tool) and CreationTime. Step 3: Check what the attacker did after accessing the mailbox. Search UAL for jsmith, Operations MailItemsAccessed — shows every email thread read. Look for: finance-related emails, M&A docs, sensitive threads. Step 4: Check for other persistence. Search for Add-MailboxPermission (delegate added), consent grants in Entra ID Audit Log, and Okta app token grants for jsmith. Response: (1) Delete the inbox rule immediately. (2) Revoke all jsmith active sessions in Okta and Entra ID. (3) Reset jsmith's password and enforce MFA re-registration. (4) Review every email delivered to gmail.com for BEC risk. (5) Preserve all UAL evidence for IR documentation.

Retrieval Practice

Your organization uses Okta as the identity provider for all SaaS apps. An attacker compromises an Okta admin account. What can they do and what Okta System Log events would each action generate?

Reveal answer

With Okta admin access, the attacker can: (1) Add a new Okta admin: event group.user_membership.add targeting Okta Super Administrators group — creates a backdoor admin account persisting after the original compromise is remediated. (2) Disable MFA for a user: event policy.rule.update or user.mfa.factor.deactivate — removes the MFA requirement, making future compromise easier. (3) Add a new app with persistent OAuth access: event application.lifecycle.create — new application registered, potentially with broad scopes. (4) Reset a user's password: event user.account.reset_password — allows the attacker to take over any user account. (5) Grant Okta API access token: event system.api_token.create — long-lived API token for continued programmatic access after the user session is revoked. Detection: all five events are high-severity in Okta System Log. Alert on: any change to the Okta Super Administrators group, any MFA policy modification, any new app creation, any API token creation. These events are rare and almost always require immediate investigation.

The SaaS Detection Challenge

Microsoft 365 Unified Audit Log

Detection Pattern 1: Inbox Rule Exfiltration (BEC)

Detection Pattern 2: OAuth App Consent Grant

Okta System Log: The SSO Chokepoint

Correlating Across SaaS Platforms

SaaS Log Maturity Checklist