Skip to content

M365 EMAIL IRP Guide

Jump to bottom
Elli edited this page Dec 28, 2021 · 4 revisions

This guide is for incident response teams and investigators that need to respond to Exchange Online incidents.

__Note: The principles of this guide can fit into other email platforms with minimal changes.

Prepare Stage

The pre-prepared stage gives you the big picture of knowing which logs are enabled and which components are configured and exist in your environment. That would provide you gaps in which platform and tools you’ve got, which logs are enabled, and what should be your next steps in preparing the incident response process.

Platforms, Logs, and Security Tools

Azure AD, M365 Logs, and M365XDR Logs

General Logs

  • Azure AD Plan
  • Exchange Online Plan
  • Office 365 Apps (SPO, Teams, etc.)
  • Compliance (Information Protection, DLP, and others)
  • SIEM and Monitor Solutions (Microsoft Sentinel, etc.)

Azure AD Logs

  • Signin Logs
  • Audit Logs

Exchange Online Logs

  • Mailbox Audit Logs
  • Unified Audit Log
  • Message Trace Log

Extended Logs

  • Microsoft Sentinel (EXO Connector) - Recommended
  • Microsoft Defender for Cloud Apps
  • Azure AD Identity Protection
  • Defender 365 Advanced Hunting
  • M365 Defender Streaming API

TIP: Use Advanced Audit because it provides audit log retention policies, longer retention of audit records, high-value vital events, and higher bandwidth access to the Office 365 Management Activity API._

Email Defense Platform and Stuff

Email defense platforms, security tools, and other security controls

  • Domain owned by the company
  • List active register MX records
  • Domain ownership and who’s can register an MX domain
  • Set Anti-Malware solution, settings, and configurations
  • Set Anti-Spam solution, settings, and configurations
  • Set Anti-Phishing solution, settings, and configurations
  • Set File sandbox solution, settings, and configurations
  • Set URL Protection solution, settings, and configurations
  • Set CDR solution, settings, and configurations
  • Detection exists for office documents spawning processes (PowerShell, CMD, MSHT, etc.)
  • Set Threat Intelligence platform
  • Check Threat Intelligence for common patterns, brands, sectors, newly developing risks, and vulnerabilities
  • Ensure access to any information such as IR Playbook, Phishing attacks, malware, and reporting
  • Perform Firedrill to ensure all Playbook aspects are working. Public / Per Year / Test / Validation
  • Third-Party security email (Ironscales, ODIX, etc.)

Security Tools (Additional)

  • Message Header Analyzer (or equivalent tool)
  • Threat Investigation (based AIR)
  • Explorer (based AIR)
  • Campaigns (based AIR)
  • eDiscovery (based Compliance)
  • Content Search (based Compliance)
  • URL Scanner (URLScanIO / CheckPhish / PhishLabs)
  • Defender for Endpoint (or other EDR solutions) - OPTIONAL
  • Information Protection to classify, encrypt and tag data
  • DLP to protect sensitive info

SIEM Platform

In case that you’ve got a SIEM solution, you need a dedicated configuration and systems. Some of them can be optional requirements.

  • Ticket Management
  • MISP Integration
  • HUB Content (CI\CD for automatic content creations)
  • Workbook to Analyze existing information
  • Automation to respond to generic scenario's

General Assets List

A list of assets and owners should exist and be available for the following.

environment

Note: Main point for assets and involved entities such as company, customer and subcontractors

  • Main Administrators and Prov owners
  • Owners (Domains, M365, Azure AD, etc.)
  • Contacts (external and internal)
  • Authorized actions (services and apps)
  • Pre-autorized members
  • Endpoints (optional)
  • Servers (optional)
  • Network Equipements (optional)
  • Security Appliances (optional)
  • Network Ranges (optional)
  • Public legit exposure
  • Private access
  • VPN and external connection
  • Internal IR contact and esclation path
  • External IR contact and esclation path
  • Entities owner cards

Specific Assets

Exchange Online

  • Roles and Permissions - Who’s has access to manage Exchange Online
  • Roles and Permissions - Who’s can disable or enable the relevant Exchange Online logs
  • Roles and Permissions - Who’s can disable or enable the relevant Azure AD or other logs
  • Forwarding Rule - Map and set restricted forwarding rules for Domain. Connectors, Users and organization
  • Malicuios Forwarding Rule - Identity unknown, modified, and malicious forwarding rules

Azure AD

  • Is Azure MFA enabled for users?
  • Is Azure MFA enabled for admins?
  • Azure AD Conditional Access is configured with Apps, location, and session?
  • Suspicious logins detection mode
  • Password Attack (Spray, BF) detection
  • Review OAuth connection and existing configuration
  • Review Azure Apps changes (Enterprise App and App Registration)
  • OAuth Detection (abuse, malicious, anomalous, etc.,)

Defender for Cloud Apps

  • Exchange Online Integration (parts of Office 365)
  • Exchange Online Visbility
  • Exchange Online advanced rules and policies
  • Azure AD integration
  • Azure AD Identity Protection integration

Azure AD PIM

  • Did Azure AD Roles manage?
  • Roles don’t require multi-factor authentication for activation?
  • Roles are being assigned outside of Privileged Identity Management?
  • Potential stale accounts in a privileged role?
  • Access reviews for Privileged Identity
  • Did alerts and notifications configured?

TIP: This can be done via Azure AD signing, Azure AD Identity Protection, and Microsoft Defender for Cloud Apps

RBAC & Permissions

  • Map exiting privileged roles
  • Detect privileged roles changes and modification (new & existing)
  • Identify user account creation

Detect Stage

Alerts

Alerts are generated by different systems owned by the SecOps, Security Engineers, and SOC teams. The primary sources for alerts are

  • Tickets
  • SIEM
  • Exchange Online Protection
  • Defenbder for Office
  • Proactive Hunting
  • Scheduele Reports
  • IT issues
  • Third-Party Tools
  • Users

Identify Risks Factors

  • Credential Theft
  • Malware Delivery (Ransomware)
  • Known Campigns
  • Blacklist
  • Application Abuse
  • Malicuios website access

Data Collection

This section describes the information that should be collected and documented about the incident. There is a lot of resources to help you with that phase here.

  • Cloud Provider (cloud storage, VM, etc.)
  • Domains (Reputation, Registrar, Owner)
  • IP's (Geo-localisation, hosts)
  • MultiStage Attack
  • Custom (files, custom page, email manipulation)

Categorize Determine the type of email

  • Phish (speaer/whale/bulk)
  • Spam
  • Malware
  • BEC
  • Account TakeOver
  • Mailbox forwarding

Triage The post-detection method that provides the first indication for any incident

  • Determine Impact
  • Determine message type
  • Type of message received
  • Did users click on URL?
  • Did users opened attachment?
  • Did users submitted information (creds)?
  • Check for false positive
  • Check the scope if wide or narrow

Analyze Stage

Verify

  • Check MDO AIR Console
  • Check Explorer Console
  • Double-check previous data
  • Rule out false positives
  • Check Messager Trace
  • Check Microsoft Sentinel

Identify IOCs

Validate hashes, TI, URL’s, ID’s

  • VirusTotal
  • Hybrid Analysis
  • VirusTotal
  • Hybrid Analysis
  • URLScan
  • Hybrid Analysis
  • Talos Intelligence
  • Office 365 TI (campign's)

Scope Validation Search mailboxes for IOCs and endpoints for IOCs

  • Identity
  • Mailbox
  • URLs
  • Domains
  • IP
  • Ports
  • Files
  • Device
  • Hash
  • Email Headers
  • Check for Impersonation
  • Check for Spoofing (5321/5322)
  • Check for Malicious URL's
  • Check for Similar Object (Mail/URL)
  • Check Subject & Body Content
  • Search Threat Intel sources
  • Disk forensics on infected recipient endpoint

Scan Enterprise

  • Update Anti-Spam filter
  • Update Anti-Malware filter
  • Update Anti-Phishing policy
  • Update Custom Indicator
  • Update FW, IDS, etc.
  • Search all mail for IOCs
  • Search EDR for IOCs

Update Scope

  • Check for Affected Recipient
  • Check for Affected Endpoints
  • Check for affected legal entities
  • Check for affected business units

Communications

  • Internal Security Teams
  • Email Team
  • Firewall Team

Contain

Block (C2, Email Traffic)

  • Update MDO Policies
  • Update Anti-Malware Policies
  • Update Anti-Spam Policies
  • Update FW, Proxy, etc. rules

action Taken by User

  • Did emails have been read
  • Did attachments have been opened
  • Did users click on the URL
  • Did the user provide any information (creds)
  • Did the user approve any OAuth app

Emails Actions

Delete emails from users Inboxes with PowerShell Delete downloaded attachments Scan for infected extensions (additional)

Monitoring Status

  • Monitor Related message
  • Monitor related user actions
  • Monitor similar email
  • Monitor clicked URL's for other users
  • Monitor if it dedicated phishing (speaer/whare/bulk)
  • Monitor Internet connections to IOC
  • Monitor files that match hashes identify

Recover & Post-Incident

Update Defenses Platform

  • Update Anti-Spam policy
  • Update Anti-Malware policy
  • Update Anti-Phishing policy
  • Update Sandbox policy
  • Update Firewall policy
  • Submit IOC's to Office 365 (email headers, files, hash, etc.)
  • Update EDR policies and IOC's
  • Update policy any other platforms
  • Update Documentations
  • Update existing Playbooks
  • Update Runbooks
  • Update Procedures
  • Configure new and update existing Detection Rules

Main Checklist Action

  • Review initial phishing email
  • Get the list of users who got this email
  • Get the latest dates when the user had access to the mailbox
  • Is delegated access configured on the mailbox?
  • Is there a forwarding rule configured for the mailbox?
  • Review your Mail Transport Rules
  • Find the email(s)
  • Did the user read or open the email?
  • Who else got the same email?
  • Did the email contain an attachment?
  • Was there a payload in the attachment?
  • Check email header for a true source of the sender
  • Verify IP addresses to attackers/campaigns
  • Did the user click the link in the email?
  • On what endpoint was the email opened?
  • Was the attachment payload executed?
  • Was the destination IP or URL touched or opened?
  • Was malicious code executed?
  • What sign-ins happened with the account for the federated scenario?
  • What sign-ins happened with the account for the managed scenario?
  • Investigate the source IP address
  • Investigate the device ID found
  • Investigate each App ID

IR Metrics

  • DateTime Occurred
  • DateTime Detected
  • DateTime Contained
  • DateTime Expelled
  • DateTime Owner Notified
  • DateTime Escalated
  • Recommended Mitigation
  • Severity
  • Source Use Case
  • Source Signature
  • Origination
  • MITRE ATT&CK Technique
  • Average Cost Per Incident
  • Average Time to Detect
  • Average Time to Escalate
  • Average Time to Contain
  • Average Time to Triage
  • Average Time to Expel
  • Average Time to Notify
  • Average Time to Closure
  • Incidents Opened in a given time frame
  • Incidents Closed in a given time frame
  • Count of Incidents per Recommended Mitigation
  • Count of Incidents per Severity
  • Count of Incidents per Severity Not Reviewed Within Required Time
  • Count of Incidents per Alert/Rule/Signature
  • Count of Incidents per Use Case
  • Count of False Positive Incidents Per Use Case
  • Count of Incidents per Attack Technique

Incident Response Best Practices

  • Try to identify the scope of the attack operation.
  • Most adversaries use multiple persistence mechanisms.
  • Identify the objective of the attack, if possible.
  • Persistent attackers will frequently return for their objective (data/systems) in a future attack.
  • Don’t upload files to online scanners
  • Many adversaries monitor instance count on services like VirusTotal to discover targeted malware.
  • Carefully consider modifications
  • Don’t investigate forever
  • Unless you face an imminent threat of losing business-critical data—such as deletion, encryption, and exfiltration—balance the risk of not modifying with the projected business impact.
  • If changes are necessary where the risk of not doing an action is higher than that, document the activity in a changelog.
  • Changes made during incident response focus on disrupting the attacker and may adversely impact the business. You will need to roll these changes back after the recovery process.
  • You must ruthlessly prioritize your investigation efforts. For example, only perform forensic analysis on endpoints that attackers have used or modified. It is practically impossible to investigate all potentially compromised resources in a significant incident where an attacker has administrative privileges.
  • Confirm that all investigation teams, including all internal teams and external investigators or insurance providers, are sharing their data, based on the advice of your legal department.
  • Access the right expertise
  • Confirm that you integrate people with deep knowledge of the systems into the investigation—such as internal staff or external entities like vendors—not just security generalists.
  • Plan for 50% of your staff operating at 50% of standard capacity due to situational stress.
  • A pivotal expectation to manage with stakeholders is that you may never be able to identify the initial attack because the data required for this may have been deleted before the investigation starts, such as an attacker covering their tracks by log rolling.
  • Consider the Incident Command System (ICS) for crisis management
  • If you don’t have a permanent organization that manages security incidents, we recommend using the ICS as a temporary organizational structure to address the crisis.
  • Keep ongoing daily operations intact and ensure that normal security operations are not entirely sidelined to support incident investigations. This work still needs to be done.
  • Many significant incidents result in purchasing expensive security tools under pressure never deployed or used. If you can’t deploy and use a tool during the investigation, including hiring and training additional staff with the skill sets needed to operate the tool, defer acquisition until after you finish the investigation.
  • Confirm you can escalate questions and issues to deep experts on critical platforms. This may require access to the operating system and application vendor for business-critical systems and enterprise-wide components such as desktops and servers.
  • Set clear guidelines and expectations for the flow of information between senior incident response leaders and organization stakeholders. See incident response planning for more details.
  • Password resets should focus first on known compromised accounts based on your investigation and are potentially administrator or service accounts. If warranted, user passwords should be reset only staged and controlled.
  • Unless you face an imminent threat of losing business-critical data, you should plan a consolidated operation to rapidly remediate all compromised resources versus remediating compromised resources as you find them. Compressing this time window will make it difficult for attack operators to adapt and maintain persistence.
  • Research and use the capabilities of tools you have already deployed before trying to deploy and learn a new tool during a recovery.
  • As practical, you should take steps to limit the information available to adversaries about the recovery operation. Adversaries typically have access to all production data and email in a significant cybersecurity incident. But in reality, most attackers don’t have time to monitor all your communications.
Clone this wiki locally