What is a session?
A session is a period of authenticated activity. Some audit records include a session identifier that helps connect actions within that service.
The legitimate user and an attacker can use the same account at the same time. Session context can help distinguish their activity. Session identifiers can work differently across services. Check what the identifier means in the logs you are using.
Move from IPs to sessions and back
- IP to session
- Search events associated with an IP address identified as suspicious during the investigation, and collect any session identifiers recorded.
- Session to activity
- Search those sessions to find related operations, including events where the original IP is missing or a service address is recorded.
- Session to additional IPs
- Review other addresses appearing in the related records. Compare them with the initial list and assess newly discovered leads.
An attacker may change network addresses during an investigation window. A session can provide another way to follow activity, but every new match still needs context.
- 01Suspicious IP leadFind related events and session IDs
- 02Session contextFollow recorded activity in those sessions
- 03Additional IPsReview new addresses and update the leads
Combine the related evidence
A combined search can include events matching a known IP OR a session identifier linked to suspicious activity. OR keeps an event when either condition matches. AND would require both and could miss useful records.
Illustrative search logic
Affected account and investigation period
AND
(Known IP match OR session ID linked to suspicious activity match)This is search logic, not a ready-to-run query. Use the actual fields and identifiers available in your evidence source. The results are related recorded events to review, not a guarantee of complete attacker activity.
Understand the recorded operations
An operation is the activity named in an audit event. Research its meaning before interpreting it.
New-InboxRule- A new inbox rule was created. Examine the rule’s actions and destination to understand its purpose.
MailItemsAccessed- Mail data was accessed. The access type and record details matter when assessing exposure.
FileDownloaded- A file download was recorded. Check the file, account and surrounding context.
Build a timeline
Arrange reviewed events in time order. Record the timestamp and time zone, source, account, operation, relevant identifiers and a short explanation.
An illustrative sequence might be a sign-in at 09:00, rule creation at 09:10 and mail access at 09:20. The ordering helps form questions; it does not establish that the rule caused the mail access.
Separate observed events from interpretations. Check gaps, conflicting details and whether the selected time window needs to be expanded.
- 0109:00 · Sign-inAccess recorded
- 0209:10 · Inbox ruleMailbox change recorded
- 0309:20 · Mail accessMail data access recorded
Key takeaway
Follow both IP and session context, review the matches, and build a timeline from supported events. Explain the sequence without treating every related record as confirmed attacker activity.
Further reading
- Contextualize activity within Exchange Online sessions (opens in a new tab)
- Investigate compromised accounts with MailItemsAccessed (opens in a new tab)
- Microsoft 365 audit activity reference (opens in a new tab)
Based on my learning notes from the DFIR BEC investigation track.