Skip to main content

​
Overview

When an account is compromised, one of the first questions to answer is: what did the attacker read, send, or delete from the mailbox? Petra pulls Microsoft audit logs and surfaces this directly on the incident page, so you can quickly scope the blast radius without digging through raw logs.
You can explore this in the demo tenant by navigating to any incident from the Incidents tab.

​
Step 1: Open the Incident Page

  1. Navigate to the Incidents tab in the top navigation.
  2. Click the incident for the compromised account.

​
Step 2: Check the Attack Impact Panel

The Attack Impact panel is on the incident page below the threat overview. It answers the email access question in two layers: a summary and a full per-email breakdown.

​
Summary view

The summary shows four counters for the duration of the attacker’s access:
CounterWhat it means
AccessedEmails the attacker opened (MailItemsAccessed)
SentEmails sent by the attacker (Send, SendAs, SendOnBehalf)
ModifiedEmails moved or drafted by the attacker (Create, Move)
DeletedEmails deleted by the attacker (MoveToDeletedItems, SoftDelete, HardDelete)
The panel also shows the total access duration — how long the attacker had access before containment — and the time from Microsoft publishing audit logs to Petra detecting the attack.
Petra preserves hard-deleted items. Even if the attacker tried to erase their tracks by hard-deleting emails, those events are captured and visible here.

​
Full view — per-email breakdown

Click Full in the top-right of the Attack Impact panel to expand the email-by-email table. Switch to the Emails tab if it isn’t already selected. Each row represents one unique email and shows:
  • Email Subject
  • Operations — all attacker actions on that email (e.g. Read, Sent, Deleted)
  • Folder — which folder the email was in
  • From / To
  • Attachments
  • Last Activity
Click any row to open the email detail sidebar, which shows a full per-message activity log: who created, sent, received, or read the message and when. This is the fastest way to confirm whether an attacker read a specific sensitive email.
Pay special attention to Sent rows. Emails sent by the attacker are the most likely to require additional remediation — they may indicate trusted-third-party phishing sent from the compromised account to the victim’s contacts.

​
Step 3: Check the Exchange Logs for Deeper Filtering

For granular analysis, use the Exchange tab in the Logs Viewer (scroll below the Attack Impact panel):
  1. Click the Exchange tab in the Logs Viewer.
  2. Use the Operation filter to focus on the actions you care about most.
    • Filter not in: MailItemsAccessed (Read) and Update to hide bulk read events and surface only high-value actions.
    • Filter in: Send, SendAs, SendOnBehalf to isolate outbound emails the attacker sent.
    • Filter in: SoftDelete, HardDelete, MoveToDeletedItems to see what the attacker deleted.
  3. Click any row to open the detail sidebar with full message metadata.
The most common log events are Read (MailItemsAccessed) and Update events. Filtering these out is usually the fastest path to finding what the attacker actually did.

​
Step 4: Check for Email Forwarding Rules

A common post-compromise tactic is setting up a silent inbox rule to forward all incoming mail to an attacker-controlled address. Petra detects this automatically and surfaces it in the Remediation Actions Panel at the top of the incident page. Look for tagged items under Persistence:
  • New-InboxRule or Set-InboxRule — indicates a rule was created or modified
  • Rules with Forward to, Forward as attachment to, or Redirect to conditions are direct evidence of ongoing email exfiltration
You can view the full rule details (conditions, actions, exceptions) and disable or delete the rule directly from this panel.
If a forwarding rule is present, the attacker may have been receiving a copy of every email sent to the account even after losing direct access. Disable the rule immediately and confirm with the user that no sensitive information arrived after the compromise date.

​
Step 5: Check for Delegated Mailbox Access

An attacker may have granted themselves or an accomplice access to the mailbox as a delegate, allowing ongoing access even after a password reset. Look for these in the Remediation Actions Panel under Persistence:
  • Add-MailboxPermission — full mailbox access granted to another account
  • Add-RecipientPermission (SendAs / SendOnBehalf) — the attacker granted another account the ability to send as the compromised user
Review the target mailbox and trustee shown for each entry to understand the scope.

​
Step 6: Export for Deeper Analysis or Reporting

To export all Exchange activity for offline review:
  1. In the Logs Viewer, go to the Exchange tab.
  2. Click Export at the top of the viewer.
  3. Open the downloaded Excel file.
  4. The Exchange tab contains all metadata for each event, including fields not visible in the web UI.
This export is useful for sharing evidence with clients or performing bulk analysis across a large number of emails.

​
What to Look For — Summary

SignalWhat it indicates
High Sent / SendAs countAttacker sent phishing or exfiltration emails from the account
HardDelete eventsAttacker attempted to cover their tracks
New-InboxRule with forwardingOngoing silent email exfiltration — remediate immediately
Add-MailboxPermissionAttacker granted delegate access as a persistence mechanism
MailItemsAccessed on sensitive foldersAttacker read sensitive emails (finance, HR, executive)
Your clients will want to know whether sensitive emails were read and whether any external communications were sent from the account. The Attack Impact panel and Exchange logs give you the evidence needed to answer both questions precisely.