.png)
Abnormal Security
LAST UPDATED: DEC. 30, 2024
Overview
The Abnormal cloud-native email security platform utilizes behavioral AI to identify and stop never-before-seen attacks that evade traditional security tools. Where legacy email security solutions rely on rules and policies to identify attacks, Abnormal delivers a fundamentally-different approach that precisely detects and then automatically remediates email threats.
D3 SOAR is providing REST operations to function with Abnormal Security.
Abnormal Security is available for use in:
Connection
To connect to Abnormal Security from D3 SOAR, follow this part to collect the required information below:
Parameter | Description | Example |
Server URL | The base server URL. | https://api.abnormalplatform.com |
Access Token | The Access Token obtained from the Abnormal portal. | ***** |
API Version | The API version to use for the connection. | v1 |
Configuring Abnormal Security to Work with D3 SOAR
Sign in to the Abnormal Security portal and click on Abnormal REST API.
Copy and save the authentication token in the Abnormal portal. This will be used for the vSOC connection. Refer to step 3j sub-step 2 in Configuring D3 SOAR to Work with Abnormal Security.
Enable IP allowlisting in the Abnormal portal by entering the specific IPv4 or IPv6 addresses, or a range of IP addresses using a CIDR block.
READER NOTE
Ensure that API access is only possible from IP addresses belonging to your organization. This keeps your data safe by preventing users from unauthorized networks from accessing your Abnormal SOAR data.
Configuring D3 SOAR to Work with Abnormal Security
Log in to D3 SOAR.
Find the Abnormal Security integration.
Navigate to Configuration on the top header menu.
Click on the Integration icon on the left sidebar.
Type Abnormal Security in the search box, then press Enter.
Click + Connection, on the right side of the Connections section. A new connection window will appear.
Configure the following fields to create a connection to Abnormal Security.
Connection Name: The desired name for the connection.
Site: Specifies the site to use the integration connection. Use the drop-down menu to select the site. The Share to Internal Sites option enables all sites defined as internal sites to use the connection. Selecting a specific site will only enable that site to use the connection.
Recipient site for events from connections Shared to Internal Sites: This field appears if you selected Share to Internal Sites for Site to let you select the internal site to deploy the integration connection.
Agent Name (Optional): Specifies the proxy agent required to build the connection. Use the dropdown menu to select the proxy agent from a list of previously configured proxy agents.
Description (Optional): Add your desired description for the connection.
Tenant (Optional): When configuring the connection from a master tenant site, you have the option to choose the specific tenant sites you want to share the connection with. Once you enable this setting, you can filter and select the desired tenant sites from the dropdowns to share the connection.
Active: Tick the checkbox to ensure the connection is available for use.
Privileged: Applicable for custom commands. Select this checkbox, along with the Privileged checkbox in custom commands, to secure integration usage. These privileged options are managed through the Privileged Commands and Privileged Secured Integration configuration modules, accessible under Organization Management > Roles.
Configure User Permissions: Defines which users have access to the connection.
System: This section contains the parameters defined specifically for the integration. These parameters must be configured to create the integration connection.
1. Input the Server URL. The default value is https://api.abnormalplatform.com.
2. Copy the Access Token from the Abnormal Security platform. Refer to step 2 in Configuring Abnormal Security to Work with D3 SOAR.
3. Input the API Version. The default value is v1.Enable Password Vault: An optional feature that allows users to take the stored credentials from their own password vault. Refer to the password vault connection guide if needed.
Connection Health Check: Updates the connection status you have created. A connection health check is done by scheduling the Test Connection command of this integration. This can only be done when the connection is active.
To set up a connection health check, check the Connection Health Check tick box. You can customize the interval (minutes) for scheduling the health check. An email notification can be set up after a specified number of failed connection attempts.
Test the connection.
Click Test Connection to verify the account credentials and network connection. If the Test Connection Passed alert window appears, the test connection is successful. You will see Passed with a green checkmark appear beside the Test Connection button. If the test connection fails, check your connection parameters and try again.
Click OK to close the alert window.
Click + Add to create and add the configured connection.
Commands
Abnormal Security includes the following executable commands for users to set up schedules or create playbook workflows. With the Test Command, you can execute these commands independently for playbook troubleshooting.
Integration API Note
For more information about the Abnormal Security API, refer to the Abnormal Security API reference.
Note for Time-related parameters
The input format of time-related parameters may vary based on your account settings. As a result, the sample data provided in our commands is different from what you see. To set your preferred time format, follow these steps:
Navigate to Configuration > Application Settings. Select Date/Time Format.
Choose your desired date and time format.
After that, you will be able to view your preferred time format when configuring the DateTime input parameters for commands.
Fetch Event
Retrieves Abuse Mailbox campaigns or Abnormal Cases from Abnormal Security as events, based on the specified criteria.
READER NOTE
D3 recommends ticking the Initiate the buffer time of the Data Reacquire for [x] minutes after completing the event fetch checkbox instead of using the tolerance scope when setting up a new data ingestion schedule.
Input
Input Parameter | Required/Optional | Description | Example |
Start Time | Required | Abuse Mailbox campaign event type
Abnormal Cases event type
| 2023-01-01 00:00 |
End Time | Required | Abused Mailbox campaigns event type
Abnormal Cases event type
| 2023-03-01 00:00 |
Number of Event(s) Fetched | Optional | The maximum number of events to fetch. By default, all emails last reported between Start Time to End Time and matching the search criteria will be returned. | 10 |
Email Sender | Optional | Filters threats by the name or email address of the sender. This parameter only applies to the Abused Mailbox campaigns event type. | *****@*****.*** |
Email Recipient | Optional | Filters threats by the name or email address of the recipient. This parameter only applies to the Abused Mailbox campaigns event type. | *****@*****.*** |
Email Subject | Optional | Filters threats by the email subject. This parameter only applies to the Abused Mailbox campaigns event type. | SUBJECT |
Attack Type | Optional | Filters threats by the attack type. Available options are:
This parameter only applies to the Abused Mailbox campaigns event type. | Malware |
Email Reporter | Optional | Filters threats by the name or email address of the reporter. This parameter only applies to the Abused Mailbox campaigns event type. | *****@*****.*** |
Threat Type | Optional | Filters threats by the threat type. Available options are:
This parameter only applies to the Abused Mailbox campaigns event type. | Malicious |
Tolerance Scope | Optional | Note: Instead of using tolerance scope, it is recommended to check the Initiate the buffer time of the Data Reacquire for [x] minutes after completing the event fetch checkbox when setting up a new Data Ingestion schedule. A time window (in minutes) that extends the time range for fetching events by subtracting from the specified start time. Tolerance scope helps prevent data loss by accounting for API response delays caused by temporary server-side data unavailability—arising from processing and synchronization—from the vendor. With the tolerance scope applied, events will be fetched within the range of (Start Time - Tolerance Scope) to End Time. By default, the tolerance scope is set to 0. | 10 |
Event Type | Optional | The type of events to fetch. Available options are:
By default, the value is Abuse Mailbox campaigns. | Abnormal Cases |
Output
To view the sample output data for all commands, refer to this article.
Fetch Event Field Mapping
Note that Fetch Event commands require event field mapping. Field mapping plays a key role in the data normalization process part of the event pipeline. Field mapping converts the original data fields from the different providers to the D3 fields which are standardized by the D3 Model. Refer to Event and Incident Intake Field Mapping for details.
If you require a custom field mapping, click + Add Field to add a custom field mapping. You can also remove built-in field mappings by clicking x. Note that two underscore characters will automatically prefix the defined Field Name as the System Name for a custom field mapping. Additionally, if an input Field Name contains any spaces, they will automatically be replaced with underscores for the corresponding System Name.
The Abnormal Security integration in D3 SOAR has some pre-configured field mappings for the Abuse Mailbox campaigns and Abnormal Cases, which correspond to the Event Source for Abuse Mailbox Campaign and Event Source for Abnormal Case mappings:
Default Event Source
The Default Event Source is the default set of field mappings that are applied when this fetch event command is executed. For out-of-the-box integrations, you will find a set of field mapping provided by the system. Default event source provides field mappings for common fields from the fetched data. The default event source has a "Main Event JSON Path" (i.e. $) that is used to extract a batch of events from the response raw data. View the "Main Event JSON Path" by clicking on the Edit Main JSON Path button.
Main Event JSON Path: $
The Main Event JSON Path determines the root path where the system starts parsing raw response data into D3 event data. The JSON path begins with $, representing the root element. The path is formed by appending a sequence of child elements to $, each separated by a dot (.). Square brackets with nested quotation marks ([‘...’]) should be used to separate child elements in JSON arrays.
For example, the root node of a JSON Path is $. The child node denoting the Event Type field would be attackType. Putting it together, the JSON Path expression to extract the Event Type is $.attackType.
Event Source for Abuse Mailbox Campaign
Configures the field mapping which are specific to the Abuse Mailbox campaign-related events. If a source field in the field mapping is not found, the corresponding field mapping will be ignored. As the data of the Abuse Mailbox campaign-related events have a character that the value of the Type field is AbuseCampaign, the Abuse Mailbox campaign-related events can be defined by the Search String: {$.Type}=AbuseCampaign. Click on Edit Event Source to view the Search String.
Note: The Event Source for Abuse Mailbox Campaign field mapping will be applied in addition to the Default Event Source field mapping for Abuse Mailbox campaign-related events.
Event Source for Abnormal Case
Configures the field mapping which are specific to the Abnormal Case-related events. If a source field in the field mapping is not found, the corresponding field mapping will be ignored. As the data of the Abnormal Case-related events have a character that the value of the Type field is AbnormalCase, the Abnormal Case-related events can be defined by the Search String: {$.Type}=AbnormalCase. Click on Edit Event Source to view the Search String.
Note: The Event Source for Abnormal Case field mapping will be applied in addition to the Default Event Source field mapping for Abnormal Case-related events.
The pre-configured field mappings are detailed below:
Field Name | Source Field |
Default Event Source (Main Event JSON Path: $) | |
Unique Event Key | .abxMessageId |
Start Time | .sentTime |
Email subject | .subject |
Event Type | .attackType |
Attack Strategy | .attackStrategy |
Status | .remediationStatus |
Sender | .fromName |
Sender Email | .fromAddress |
Sender Domain | .senderDomain |
toRecipients | .toAddresses |
Recipient | .recipientAddress |
Receipt time | .receivedTime |
Message ID | .internetMessageId |
Return address | .returnPath |
Sender IP Address | .senderIpAddress |
CcRecipients | .ccEmails |
Reply To Emails | .replyToEmails |
Impersonated Party | .impersonatedParty |
Attack Vector | .attackVector |
Attachment Names | .attachmentNames |
URL | .urls |
Summary Insights | .summaryInsights |
Remediation Time | .remediationTimestamp |
Attacked Party | .attackedParty |
Auto Remediated | .autoRemediated |
Post Remediated | .postRemediated |
Event Source for Abuse Mailbox Campaign (Search String: {$.Type}=AbuseCampaign) The search string format is {jsonpath}=value. If the value of the Type key is AbuseCampaign in the event object under raw data, then the Abuse Mailbox Campaign-related events will use the field mapping below. | |
Unique Event Key | .campaignId |
Internal message ID | .messageId |
First Reported Time | .firstReported |
Last Reported Time | .lastReported |
Email subject | .subject |
Sender | .fromName |
Sender Email | .fromAddress |
Original Recipient | .recipientName |
Recipient | .recipientAddress |
Status | .overallStatus |
Judgement Status | .judgementStatus |
Event Type | .attackType |
Start Time | .firstReported |
Event Source for Abnormal Case (Search String: {$.Type}=AbnormalCase) The search string format is {jsonpath}=value. If the value of the Type key is AbnormalCase in the event object under raw data, then the Abnormal Case-related events will use the field mapping below. | |
Unique Event Key | .caseId |
Start Time | .firstObserved |
Severity | .severity |
Affected Employee | .affectedEmployee |
Threat IDs | .threatIds |
Error Handling
If the Return Data displays Failed, an Error tab will appear in the Test Result window.
The error tab contains the details responded from D3 SOAR or third-party API calls, including Failure Indicator, Status Code, and Message. This can help you locate the root cause of a command failure.
Parts in Error | Description | Example |
Failure Indicator | Indicates the command failure that happened at a specific input and/or API call. | Fetch Event failed. |
Status Code | The response code issued by the third-party API server or the D3 SOAR system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Abnormal Security portal. Refer to the HTTP Status Code Registry for details. | Status Code: 400. |
Message | The raw data or captured key error message from the integration API server about the API request failure. | Message: Server URL, Access Token, API Version are all required. |
Error Sample Data Fetch Event failed. Status Code: 400. Message: Server URL, Access Token, API Version are all required. |
Fetch Incident
Retrieves threat logs from Abnormal Security based on the specified criteria.
READER NOTE
[December 2023]: The 200 response code example for the /threats/{threatId}/links API endpoint contains an error. The top-level JSON path field is incorrectly specified as $.threats; it should be $.links.
D3 recommends ticking the Initiate the buffer time of the Data Reacquire for [x] minutes after completing the event fetch checkbox instead of using the tolerance scope when setting up a new data ingestion schedule.
Input
Input Parameter | Required/Optional | Description | Example |
Start Time | Required | Returns threats received after this time. | 2023-01-01 00:00 |
End Time | Required | Returns threats received before this time. | 2023-03-01 00:00 |
Number of Incident(s) Fetched | Optional | The number of most recently received threats to return. By default, all incidents matching the search criteria will be returned. | 10 |
Detection Source | Optional | Filters threats by the detection source. Available options are:
By default, the value is All. | All |
Email Sender | Optional | Filters threats by the name or email address of the sender. | *****@*****.*** |
Email Recipient | Optional | Filters threats by the name or email address of the recipient. | *****@*****.*** |
Email Subject | Optional | Filters threats by the email subject. | SUBJECT |
Topic | Optional | Filters threats by the topic of the email content. Available options are:
| Invoice |
Attack Type | Optional | Filters threats by the attack type. Available options are:
| Malware |
Attack Vector | Optional | Filters threats by the attack vector. Available options are:
| Link |
Attack Strategy | Optional | Filters threats by the attack strategy. Available options are:
| Name Impersonation |
Impersonated Party | Optional | Filters threats by the impersonated party. Available options are:
| VIP |
Tolerance Scope | Optional | Note: Instead of using tolerance scope, it is recommended to check the Initiate the buffer time of the Data Reacquire for [x] minutes after completing the event fetch checkbox when setting up a new Data Ingestion schedule. A time window (in minutes) that extends the time range for fetching events by subtracting from the specified start time. Tolerance scope helps prevent data loss by accounting for API response delays caused by temporary server-side data unavailability—arising from processing and synchronization—from the vendor. With the tolerance scope applied, events will be fetched within the range of (Start Time - Tolerance Scope) to End Time. By default, the tolerance scope is set to 0. | 10 |
Get Threat Links | Optional | Whether to ingest threat links. Available options are:
By default, the value is False. | True |
Incident Field Mapping
For this integration, the default incident fields in D3 SOAR are fixed with no built-in source fields. Users can specify the source fields as needed.
Event and Incident Intake Field Mapping
Incident field mapping is mandatory for the Fetch Incident command, while event field mapping is optional for the same command. Users can edit the provided mappings or create custom mappings as needed. See Event and Incident Intake Field Mapping for more details.
Incident Main JSON Path: $
Field Name | Source Field |
Title | User defined |
Description | User defined |
Severity | User defined |
Incident Type | User defined |
Incident Creator | User defined |
Incident Owner | User defined |
Incident Playbook | User defined |
Due In Date | User defined |
Unique Key | User defined |
Tactics | User defined |
Techniques | User defined |
Event Field Mapping
Main Event JSON Path
$.messages
The event field mapping used in the Fetch Incident command is identical to the one used in the Fetch Event command.
Output
To view the sample output data for all commands, refer to this article.
Error Handling
If the Return Data displays Failed, an Error tab will appear in the Test Result window.
The error tab contains the details responded from D3 SOAR or third-party API calls, including Failure Indicator, Status Code, and Message. This can help you locate the root cause of a command failure.
Parts in Error | Description | Example |
Failure Indicator | Indicates the command failure that happened at a specific input and/or API call. | Fetch Incident failed. |
Status Code | The response code issued by the third-party API server or the D3 SOAR system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Abnormal Security portal. Refer to the HTTP Status Code Registry for details. | Status Code: 400. |
Message | The raw data or captured key error message from the integration API server about the API request failure. | Message: Server URL, Access Token, API Version are all required. |
Error Sample Data Fetch Incident failed. Status Code: 400. Message: Server URL, Access Token, API Version are all required. |
Report Email
Reports a missed attack or a false positive judgment by Abnormal Security.
READER NOTE
Portal Link is an optional parameter to run this command.
Run the Fetch Incident command to obtain the Portal Link. Portal Links can be found in the raw data at the path $[*].messages[*].abxPortalUrl.
Input
Input Parameter | Required/Optional | Description | Example |
Report Type | Optional | The report type. Available options are:
By default, the value is False Negative. False negative indicates that a missed attack has been reported. False positive indicates that a false positive judgment has been reported. | False Negative |
Subject | Optional | The subject of the email to report. This parameter only applies to the False Negative report type. | Test Phishing Email |
Recipient Email | Optional | The email address of the recipient who has received a potentially malicious email. This parameter only applies to the False Negative report type. | *****@*****.*** |
Sender Email | Optional | The email address that may be potentially malicious. This parameter only applies to the False Negative report type. | *****@*****.*** |
Received Date | Optional | When the email was received in the YYYY-MM-DD format (in UTC). | 2023-03-01 |
Description | Optional | A description providing context for the issue. | Alice reported this phishing email was missing from their inbox. |
Portal Link | Optional | The link of the portal for a False Positive threat. Portal Links can be obtained using the Fetch Incident command. This parameter only applies to the False Positive report type. | https://portal.abnormalsecurity.com/home/threat-center/remediation-history/***** |
Output
To view the sample output data for all commands, refer to this article.
Error Handling
If the Return Data displays Failed, an Error tab will appear in the Test Result window.
The error tab contains the details responded from D3 SOAR or third-party API calls, including Failure Indicator, Status Code, and Message. This can help you locate the root cause of a command failure.
Parts in Error | Description | Example |
Failure Indicator | Indicates the command failure that happened at a specific input and/or API call. | Report Email failed. |
Status Code | The response code issued by the third-party API server or the D3 SOAR system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Abnormal Security portal. Refer to the HTTP Status Code Registry for details. | Status Code: 400. |
Message | The raw data or captured key error message from the integration API server about the API request failure. | Message: Server URL, Access Token, API Version are all required. |
Error Sample Data Report Email failed. Status Code: 400. Message: Server URL, Access Token, API Version are all required. |
Search Emails
Retrieves Abuse Mailbox campaign details based on the search conditions. A maximum of 100 campaigns can be returned.
Input
Input Parameter | Required/Optional | Description | Example |
Email Sender | Optional | Filters threats by the name or email address of the sender. | *****@*****.*** |
Email Recipient | Optional | Filters threats by the name or email address of the recipient. | *****@*****.*** |
Email Subject | Optional | Filters threats by the email subject. | SUBJECT |
Attack Type | Optional | Filters threats by the attack type. Available options are:
| Malware |
Email Reporter | Optional | Filters threats by the name or email address of the reporter. | *****@*****.*** |
Threat Type | Optional | Filters threats by the threat type. Available options are:
| Malicious |
Output
To view the sample output data for all commands, refer to this article.
Error Handling
If the Return Data displays Failed, an Error tab will appear in the Test Result window.
The error tab contains the details responded from D3 SOAR or third-party API calls, including Failure Indicator, Status Code, and Message. This can help you locate the root cause of a command failure.
Parts in Error | Description | Example |
Failure Indicator | Indicates the command failure that happened at a specific input and/or API call. | Search Emails failed. |
Status Code | The response code issued by the third-party API server or the D3 SOAR system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Abnormal Security portal. Refer to the HTTP Status Code Registry for details. | Status Code: 400. |
Message | The raw data or captured key error message from the integration API server about the API request failure. | Message: Server URL, Access Token, API Version are all required. |
Error Sample Data Search Emails failed. Status Code: 400. Message: Server URL, Access Token, API Version are all required. |
Take Action To Threats
Takes action to remediate or un-remediate the specified threats.
READER NOTE
Threat IDs is a required parameter to run this command.
Run the Fetch Incident command to obtain the Threat IDs. Threat IDs can be found in the raw data at the path $[*].threatId.
Input
Input Parameter | Required/Optional | Description | Example |
Threat IDs | Required | The IDs of the threats against which to take action. Threat IDs can be obtained using the Fetch Incident command. | [ "*****" ] |
Action | Required | The action to take against the specified threats. Available options are: Remediate Unremediate | Remediate |
Output
To view the sample output data for all commands, refer to this article.
Error Handling
If the Return Data displays Partially Successful or Failed, an Error tab will appear in the Test Result window.
The error tab contains the details responded from D3 SOAR or third-party API calls, including Failure Indicator, Status Code, and Message. This can help you locate the root cause of a command failure.
Parts in Error | Description | Example |
Failure Indicator | Indicates the command failure that happened at a specific input and/or API call. | Take Action To Threats failed. |
Status Code | The response code issued by the third-party API server or the D3 SOAR system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Abnormal Security portal. Refer to the HTTP Status Code Registry for details. | Status Code: 400. |
Message | The raw data or captured key error message from the integration API server about the API request failure. | Message: Server URL, Access Token, API Version are all required. |
Error Sample Data Take Action To Threats failed. Status Code: 400. Message: Server URL, Access Token, API Version are all required. |
Test Connection
Allows you to perform a health check on an integration connection. You can schedule a periodic health check by selecting Connection Health Check when editing an integration connection.
Input
N/A
Output
Output Type | Description | Return Data Type |
Return Data | Indicates one of the possible command execution states: Successful or Failed. The Failed state can be triggered by any of the following errors: - A connection issue with the integration - The API returned an error message - No response from the API You can view more details about an error in the Error tab. | String |
Error Handling
If the Return Data displays Failed, an Error tab will appear in the Test Result window.
The error tab contains the details responded from D3 SOAR or third-party API calls, including Failure Indicator, Status Code, and Message. This can help you locate the root cause of a command failure.
Parts in Error | Description | Example |
Failure Indicator | Indicates the command failure that happened at a specific input and/or API call. | Test Connection failed. Failed to check the connector. |
Status Code | The response code issued by the third-party API server or the D3 SOAR system that can be used to locate the corresponding error category. For example, if the returned status code is 401, the selected connection is unauthorized to run the command. The user or system support would need to check the permission setting in the Abnormal Security portal. Refer to the HTTP Status Code Registry for details. | Status Code: 401. |
Message | The raw data or captured key error message from the integration API server about the API request failure. | Message: Unauthorized. |
Error Sample Data Test Connection failed. Failed to check the connector. Status Code: 401. Message: Unauthorized. |