You can integrate your Microsoft 365 environment with the Incident Responder product to start an investigation on users' email accounts by following the steps below.You must use an account with global administrator permission.
Select App Registration on the Microsoft Azure portal.
Click +New registration.
In the Register an application section, enter the name of the new application (required field).
Select supported accounts from the Accounts in this organizational directory only option (auth secure login only - single-tenant).
Select Public client/native (mobile & desktop) from the dropdown menu to enter a Redirect URL.
Click Register. (Leave the myapp://auth field section blank).
The new application will now appear in the list of app registrations; click on the name of the new application.
Under Essentials, you will see the following displayed:
Application (client) ID
Directory (tenant) ID
Please take note of these as you will need this information later to set up the new configuration.
Now you are ready to proceed to the next step: the application secret key.
An application secret key must be created for the new registration.
Under Manage from the left-side menu, select Certificates & Secrets.
Select Client secrets.
Select +New client secret.
Enter the description and expiration date and click Add.
The last step is to add application permissions.
Select Manage > API Permissions and click +Add permission.
Click Microsoft Graph and a new window called Request API permissions will appear.
Click Application permissions and then choose Application Permission and in the Select permissions field, find and select the following required permissions:
You can find more information about these permissions at “”.
You can test the integration on the platform to make sure that it is working. Go to Incident Responder > Mail Configurations on the left sidebar menu of the dashboard and then click + NEW and choose the mail provider - in this case, Office 365.
Complete the following fields in the Microsoft Office 365 configuration table. The integration details are:
If the test was successful, the new email server integration will be shown in the list of mail configurations.
If an X appears, it indicates there was a problem and the email server integration failed; please wait a few minutes (5-10+min) for O365 to successfully complete the integration, and then if not work still, please review the instructions.
This permission allows the app to read data in your organization's directory, such as users, groups, and apps. Note: Users may consent to applications that require this permission if the application is registered with their organization’s tenant.
The platform uses this permission to retrieve the client's user list when an investigation is initiated and then to access the email addresses. For example, when a user finds a suspicious email, the platform can scan all users in the list retrieved.
This permission allows the app to create, read, update, and delete email in user mailboxes. It does not include permission to send mail. The platform uses this permission to scan and filter users' emails. For example, when the “From” filter is selected as a parameter to be used in an investigation, this authorization enables the creation of a list of the emails that meet this criterion. It is also used to send a warning message to users. This permission also allows the platform to scan the contents of the emails to find and match the designated investigation parameters. For example, specific filters such as regex, keywords, etc.
This permission allows the app to create, read, update, and delete the user's mailbox settings. It does not include permission to send mail directly, but allows the app to create rules that can forward or redirect messages. The platform uses this permission to mark emails that will receive a warning message.
This permission allows the app to read the full set of profile properties, reports, and managers of other users in your organization on behalf of the signed-in user. The platform uses this permission to read and filter user information during the scanning process. If user-related filters, such as specific users, are selected as scan criteria, the user information may need to be read. For example, an organization may elect to initiate an investigation of employees in a particular department.
A: Yes. The platform’s flexibility allows you to start an investigation at any time and specify how long it is to run, or to create a continuous, automatic search for harmful e-mails. Server-based integration with your email service provides the most comprehensive protection.
A: Yes. The Phishing Reporter plug-in can be used to conduct investigations and mitigation. However, the user must have Outlook open and the plug-in active. Email server integration eliminates this limitation.
Make sure to save the secret key value before you move on to the final step.
Directory.Read.All
Mail.ReadWrite
MailboxSettings.ReadWrite
User.Read.All (under User)
Click Add permissions.
Click Grant admin consent for (user).
Perform a test of the configuration
Name
Name of the configuration
Application (client) ID
Application ID information is provided on the azure portal under the Overview menu.
Application Secret
Application Secret information is provided on the azure portal under the Overview menu.
Directory (tenant) ID
Directory ID information is provided on the azure portal under the Manage > Certificates & secrets menu.
Test Email Address
An active email address to be used for testing purposes
Domain Selection
Authorized domain(s) to start investigations on
Test Connection
You can integrate your Google Workspace environment with the Incident Responder product by following the steps below.
Log into https://console.cloud.google.com/ using an account that has administrative permissions.
Click Select a project > New Project.
Click on the related new project.
On the left-side menu, go to APIs and Services > Library, search for Admin SDK API, and click Enable.
Return to the previous page and search for Gmail API, then click Enable to activate the API.
Select IAM & Admin > Service Accounts from the left-side menu.
Click Create Service Account, name it, and click Create and Continue.
Select Service Directory > Service Directory Admin as the role and click Continue > Done to complete the process.
After creating a service account, click on the related user and go to the user details page.
Go to the Keys tab, click Add Key > Create new key.
Select JSON as the key type and click Create. Save the JSON file.
Go to the Details tab and copy Unique ID information. Save this information for the next step.
Next, log in to .
Go to Security > Access and data control > API controls on the left-side menu.
Scroll down to Domain-wide delegation and click Manage Domain-Wide Delegation.
Click Add New.
For Client ID, enter the Unique ID
https://mail.google.com/,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/gmail.labels,https://www.googleapis.com/auth/gmail.modify
Click Authorize to complete the process.
To make sure that the integration is working, you can test it on the platform. Go to Incident Responder > Mail Configurations on the left sidebar menu of the dashboard and then click + NEW and choose the mail provider - in this case, Google Workspace.Complete the following fields in the configuration table:
The new configuration will now appear in the list of mail configurations if the test was successful.
If an X appears, it indicates there was a problem and the email server integration failed; please review the instructions.
API scopes identify the information an application will be able to access on a user’s behalf.
This permission allows the app access to emails in user mailboxes. Please note, it is only used to enable investigative searches; we do not create, read, edit, or send emails using this permission.
The platform uses this permission to scan and filter users' emails. For example, when the “From” filter is selected as a criterion for investigation, this authorization enables the creation of a list of the emails that meet the specified parameter. Other uses include regex and keyword searches.
This permission enables quick deletion of malicious content without compromising user privacy.
This permission allows the app to read data in the organization's user directory. The platform uses this access to retrieve a client's user list and their email addresses when an investigation has been initiated.
This permission allows the app to create, read, update, and delete labels. The platform uses this authority to mark emails in the user's inbox with a warning message when the client deems this appropriate. For example, after running an investigation, you may choose to warn the user rather than delete the email results.
A: No. In order to be able to start an investigation and take action on emails, integration with Google Workspace is required.
For OAuth Scopes, paste the scope information below:
Name
Name of the configuration
Credential JSON
Open the JSON file with a text editor and copy/paste all of the information
Test Email Address
An active email address to be used for testing purposes
Test Connection
Perform a test of the configuration
This article section describes how to integrate the Incident Responder module with Google Workspace, Exchange, or Microsoft Office 365 email services. It's important to follow the steps accurately. Please contact your email server administrator if you don’t have the required permissions to make these configurations.
The Incident Responder module investigation tool can detect malicious emails in user inboxes and remove them automatically or can be removed by the admin as well.
Server-based integration with your email service provides the most comprehensive protection. While email investigations can be conducted with the Phishing Reporter plug-in, the user must have Outlook open and the plug-in active for the investigation to be successful. If the Outlook application is closed for any reason, a complete investigation can only be performed using a server-based integration.
The server-based integration has the advantage to start an investigation at any time.
Select Incident Responder > Mail Configurations from the left sidebar menu of the dashboard to create a new mail configuration or view the details of an existing configuration.
To set initial configurations, select the appropriate email server integration:
Office 365
Exchange
Google Workspace
The integration details are:
Name
Name of the configuration
Platform
Email service name to be integrated: Exchange EWS, Office 365, or Google Workspace
An active email address is required for testing purposes
Status
Status of the configuration: (running/not running)
Date Created
Integration start date
Action
Edit/remove the integration
You can integrate your EWS environment with the Incident Responder product by following the steps below.
First, you must have or create a Microsoft user identity with either impersonation or delegation permission.
The user must have exchange admin permissions to configure these options.
Please refer to this document for information on how to create a service/admin user.
The impersonation option is recommended for setting up email server integration.
Impersonation gives one service account access to every mailbox in a database. This enables quick and easy investigation and response to an incident.
Restrictions may also be designated for the impersonation account, depending on the policies of the organization.
The following command can be used in the Exchange Management Shell to grant the impersonation privilege to a service account. This example assigns the service account [email protected] full access permission to all user mailboxes in the company.com organization.
The delegation privilege requires that permissions be added individually to each mailbox. The platform can access the mailboxes within the Exchange designated by the organization.
Restrictions may also be designated for the account, depending on the policies of the organization.
The following command can be used in the Exchange Management Shell to grant delegation privilege to a service account. This example assigns the service account user [email protected] full access permission to the specified ‘TargetUserName’ user mailbox.
To make sure that the integration is working, you can test it on the platform. Go to Incident Responder > Mail Configurations on the left sidebar menu of the dashboard and then click + NEW and choose the mail provider - in this case, Exchange EWS. Complete the following fields in the configuration table:
The integration details are:
The new configuration will now appear in the list of mail configurations if the test was successful.
If an X appears, it indicates there was a problem and the email server integration failed; please review the instructions.
Throttling policy is a control mechanism designed to preserve server reliability and functionality by limiting the resources consumed by a single user or application.
The Microsoft Exchange throttling policy is a default setting that restricts users on various client access protocols, such as MAPI, Activesync, OWA, POP3, etc., intended to prevent a potential crash or denial of service (DoS) via repeated requests.
A successful integration between Exchange and the Incident Responder will lead to hundreds of connections on the Exchange server when an investigation begins.
The investigation may be obstructed by the throttling policy. Therefore, the default throttling policy rights of the service user defined in the Incident Responder product should be expanded to avoid this problem.
You can use the command below in Exchange Management to view all of the available throttling policies.
Open the Exchange Management Shell and use the command below to create a new throttling policy.
Once you have added a new throttling policy, please enter the following command to set the permissions of the new policy.
User Use the command below to assign a throttling policy to a specific user. Replace “[email protected]” with the service user you designated in the Incident Responder.
An active email address to be used for testing purposes
X-Anchor Mail Box Header
Check this box if the platform needs to use the X-Anchor MailBox header in connections to the Exchange server.
Target Groups
Selection of the users to be subjects of investigation
All Groups: All user inboxes
Specific User Groups: Selected group of user inboxes
Test Connection
Perform a test of the configuration
Name
Name of the configuration
Service URL
Exchange URL information
Exchange Version
Exchange version information
Account Type
Account type of the service user
Username
Username of the service user
Password
Password of the service user
Test Email Address
[PS] C:\Windows\system32> Get-Mailbox -ResultSize unlimited -Filter "(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Admin')" | Add-MailboxPermission -User [email protected] -AccessRights FullAccess -InheritanceType All[PS] C:\Windows\system32> Add-MailboxPermission -Identity "TargetUserName" -User "[email protected]" -AccessRights FullAccess Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}New-ThrottlingPolicy KeepnetUnlimitedPolicyNameSet-ThrottlingPolicy KeepnetUnlimitedPolicyName -RCAMaxConcurrency Unlimited -Exchange EWSMaxConcurrency Unlimited -Exchange EWSMaxSubscriptions Unlimited -CPAMaxConcurrency Unlimited -Exchange EWSCutoffBalance Unlimited -Exchange EWSMaxBurst Unlimited -Exchange EWSRechargeRate Unlimited -Exchange EWSFindCountLimit UnlimitedSet-Mailbox “[email protected]" -ThrottlingPolicy KeepnetUnlimitedPolicyName