Task 2.3: Investigate Microsoft 365 activities to identify threats

• ATurn on mailbox auditing for the Teams users

  Incorrect

  Mailbox auditing covers Exchange mailbox actions, not Teams activities.

• BSwitch the search to the Search-UnifiedAuditLog cmdlet

  Incorrect

  The cmdlet reads the same retained records.

• CExport audit records to CSV every month

  Incorrect

  Exports work but don't change retention in the audit log.

• DAn audit log retention policy for Teams with a one-year duration

  Correct

  Only Entra, Exchange, OneDrive and SharePoint records get one year by default.

Audit (Premium) retains Microsoft Entra ID, Exchange, OneDrive and SharePoint records for one year through a default policy. Records for all other activities are kept for 180 days unless an audit log retention policy, based on service, activity or user, keeps them longer.

• ACount as exposed only the messages listed by InternetMessageId in bind records

  Incorrect

  Bind records list individual messages, but sync access is recorded per folder, not per item.

• BCount nothing as opened; sync entries mean browsing only

  Incorrect

  A sync means the client downloaded the folder's items, so they're assumed compromised.

• CTreat every item in each synced folder as accessed by the attacker

  Correct

  Sync access is audited per folder, and all items in a synced folder are assumed compromised.

• DWait up to 24 hours for per-message records to replace the folder entries

  Incorrect

  Sync access isn't recorded per item; the folder-level event is the record.

MailItemsAccessed covers sync access, where a client downloads sets of messages, and bind access to individual messages. Sync is recorded only for desktop Outlook for Windows or Mac, and because of its volume the system records one event for the synced folder instead of one per item; all items in that folder are assumed compromised. Bind operations within a 2-minute interval are aggregated into one record that identifies each message by its InternetMessageId.

• AConnect with Connect-ExchangeOnline instead of Connect-IPPSSession

  Incorrect

  Purge actions run in Security & Compliance PowerShell.

• BReconnect with Connect-IPPSSession -EnableSearchOnlySession

  Correct

  Purge actions in Security & Compliance PowerShell need this switch.

• CAdd the Compliance Search role as well

  Incorrect

  That role creates and runs searches; purge rights are already in place.

• DAdd -PurgeType HardDelete to the command

  Incorrect

  The purge type doesn't fix the session requirement.

To use the purge action in Security & Compliance PowerShell, use the Exchange Online PowerShell module version 3.9.0 or later and run Connect-IPPSSession with the EnableSearchOnlySession switch. The user also needs the Search And Purge role.

• AAn Entra diagnostic setting that sends Graph activity logs to Log Analytics

  Correct

  Graph activity logs are collected through Entra diagnostic settings.

• BAn Entra diagnostic setting that sends service principal sign-in logs to Log Analytics

  Incorrect

  Service principal sign-ins record the app's authentications, not each Graph request it makes.

• CAn Entra diagnostic setting that sends audit logs to Log Analytics

  Incorrect

  Entra audit logs capture changes to applications, groups and users, not every Graph request.

• DAudit (Premium) licenses for the app's owners

  Incorrect

  Graph activity logs aren't Purview audit records.

Microsoft Graph activity logs record HTTP requests that Graph receives for the tenant. They need a Microsoft Entra ID P1 or P2 license and a diagnostic setting, for which Security Administrator is the least privileged role, sending the logs to a Log Analytics workspace where you can query them. Collection starts when the setting is created.

• AIngestion stopped today; turn it back on with Set-AdminAuditLogConfig in that session

  Incorrect

  The property reads False there even when search is on, and the setting is changed in Exchange Online PowerShell.

• BAuditing is on only for users with Audit (Premium) licenses

  Incorrect

  Audit log search is on by default for enterprise organizations; it isn't a per-license switch.

• CThe Purview portal reads a different audit log than PowerShell does

  Incorrect

  The portal search and the Search-UnifiedAuditLog cmdlet use the same audit log.

• DThe property always reads False there; check it in Exchange Online PowerShell

  Correct

  Only Exchange Online PowerShell reports the real value of UnifiedAuditLogIngestionEnabled.

To verify unified audit log ingestion, run Get-AdminAuditLogConfig in Exchange Online PowerShell; True means audit log search is on. The cmdlet also exists in Security & Compliance PowerShell, but there the UnifiedAuditLogIngestionEnabled property is always False, even when audit log search is turned on. Audit log search is on by default for enterprise organizations, and the portal search uses the same audit log as the Search-UnifiedAuditLog cmdlet.

• AAll 120,000 records in one file

  Incorrect

  Audit (Standard) exports are capped per search.

• BThe export fails with an error

  Incorrect

  The export completes but might omit records.

• CThree files of 40,000 records each

  Incorrect

  Exports aren't split automatically.

• DAt most 50,000 records, so split the date range into smaller searches

  Correct

  Audit (Standard) exports up to 50,000 records per search.

With Audit (Standard) you can export up to 50,000 records from a single audit search; Audit (Premium) raises this to 1,000,000. If results exceed the limit, the file doesn't include them all, so narrow the scope or split the date range.

• Asender == "billing@contoso.com" and subject == "Invoice overdue"

  Incorrect

  That's KQL for Kusto, not Keyword Query Language for eDiscovery.

• BEmailEvents | where SenderFromAddress == "billing@contoso.com"

  Incorrect

  That's an advanced hunting query, not an eDiscovery search.

• C(From:billing@contoso.com) AND (Subject:"Invoice overdue")

  Correct

  eDiscovery uses Keyword Query Language property restrictions such as From and Subject.

• DFrom=billing@contoso.com; Subject=Invoice overdue

  Incorrect

  Property restrictions use a colon and Boolean operators.

eDiscovery searches use Keyword Query Language (KQL) with property restrictions such as From, Subject and Received, combined with Boolean operators like AND. Put exact phrases in quotes.

• AMailItemsAccessed and Send

  Incorrect

  They record mail access and sending, not rule changes.

• BNew-InboxRule, Set-InboxRule and Remove-InboxRule

  Correct

  These operations record rules being created, modified and deleted.

• CUserLoggedIn and FileAccessed

  Incorrect

  They record sign-ins and file access.

• DGet-InboxRule

  Incorrect

  Get-InboxRule shows current rules; it isn't an audited change.

Use Get-InboxRule to see a mailbox's current rules and search the audit log for the New-InboxRule, Set-InboxRule and Remove-InboxRule operations to find who created, modified or deleted them.

• ACore-service records usually appear 60 to 90 minutes after the event

  Correct

  Microsoft doesn't guarantee a time, but core services usually take 60 to 90 minutes.

• BThe default search date range doesn't include today

  Incorrect

  The default range is the last seven days, which includes today.

• CAudit log search is turned off by default

  Incorrect

  It's on by default for Microsoft 365 and Office 365 enterprise organizations.

• DThe search must run in Exchange Online PowerShell instead of the portal

  Incorrect

  The Search-UnifiedAuditLog cmdlet searches the same audit log, so it wouldn't find the record sooner.

Microsoft doesn't guarantee when an audit record becomes searchable. For core services such as Exchange, SharePoint, OneDrive and Teams, records are typically available 60 to 90 minutes after the event, and other services can take longer. Audit log search is on by default, and the default search range is the last seven days.