Alert Types That Use the Syslog Index
The Alert Types listed below use the Syslog Index . For a list of Alert Types by each index or XDR Kill Chain stage, or for a general overview, refer to Machine Learning and Analytics Overview.
To minimize excessive alerting, each alert type is triggered only once in a 24-hour period for the set of attributes that triggered that specific alert.
Where applicable, the Tactics and Techniques are linked to the relevant MITRE | ATT&CK page.
Stellar Cyber also provides an interactive tool that lets you look up alert types by data source, alert name, event type, or source index.
- Bad Reputation Login
- External Account Login Failure Anomaly
- External Brute-Forced Successful User Login
- External Credential Stuffing
- External User Login Failure Anomaly
- Impossible Travel Anomaly
- Internal Account Login Failure Anomaly
- Internal Brute-Forced Successful User Login
- Internal User Login Failure Anomaly
- Login Time Anomaly
- Malware on Disk
- User Login Location Anomaly
- Carbon Black XDR Anomaly
Bad Reputation Login
A successful login was detected from an IP address with a history of malicious activity. Check with the user.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] XDR NBA (XTA0002)
-
Technique: XDR Bad Reputation (XT2010)
-
Tags: [External]
Event Name
The xdr_event.name for this alert type in the Interflow data is bad_reputation_login.
Key Fields and Relevant Data Points
srcip— source IP address
srcip_host— source host namesrcip_reputation— source reputationsource_geo.countryName— source countrydstip_host— destination host namelogin_type— type of loginusername— user name
Use Case with Data Points
The login records are checked for every source IP address (srcip). If a source IP address has successful login records and its reputation (srcip_reputation) is bad (except brute-forcer and scanner), an alert is triggered. A sample Interflow includes source IP address (srcip), source host (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), login type (login_type), and user name (username).
External Account Login Failure Anomaly
An anomalously large number of user login failures was observed for an account. Check with the user.
This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] Credential Access (TA0006 )
-
Technique: Brute Force (T1110 )
-
Tags: [External]
Event Name
The xdr_event.name for this alert type in the Interflow data is external_cloud_account_login_failure.
Key Fields and Relevant Data Points
srcip_usersid— cloud account user ID
scrip_username— cloud account user nameevent_summary.total_failed— number of failed logins in the period
event_summary.total_successful— number of successful logins in the period
event_summary.total_fail_ratio— percent of failed logins in the period, which is:event_summary.total_failed/ (event_summary.total_failed+event_summary.total_successful)
accumulated_anomalous_failures— score value of the model indicating the degree of abnormal activitysrcip_host— host name of corresponding source IP addresslogin_type— type of loginsrcip_reputation— source reputation
Use Case with Data Points
Login failures and successes are calculated periodically for every account (srcip_usersid). If the number of failures is significantly larger than the number of successes, an alert is triggered. A sample Interflow includes the login type (login_type), source host (srcip_host), and source reputation (srcip_reputation).
Stellar Cyber reports both internal and external versions of some alerts, with
different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:
- Addresses with a
srcip_typeordstip_typeofprivateare identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external). - Communications
between hosts where
srcip_typeanddstip_typeare bothprivateare considered internal communications. - When an anomaly is observed on an internal communication, the attack is considered to be internal.
- Stellar Cyber always sets the
srcipin the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show thedstipas the source address and thesrcipas the destination address, even though thesrcipwas the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record ofsrcipanddstipto understand which address initiated the threat event.
External Brute-Forced Successful User Login
A successful login was observed from an IP address that had previously seen a large number of login failures, or a successful login to a user account was observed from another IP address or IP addresses that had previously seen a large number of login failures to that account. Check with the user.![]()
This alert type has two subtypes:![]()
This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] Credential Access (TA0006 )
-
Technique: Brute Force (T1110 )
-
Tags: [External]
Event Name
The xdr_event.name for this alert type in the Interflow data is external_user_success_brute_forcer.
Alert Subtype: Source IP-Based![]()
The source IP-based alert subtype has the same XDR Kill Chain and Event Name as the user ID-based alert subtype, but differs in the Key Fields and Relevant Data Points and Use Case with Data Points.
Key Fields and Relevant Data Points
srcip— source IP address
srcip_usersid— Windows SID associated with the source IP address
srcip_host— source host namesrcip_reputation— source reputationsource_geo.countryName— source countrydstip_host— destination host namelogin_type— type of loginusername— user namerelated_alert._id— link to the related External User Login Failure Anomaly
Use Case with Data Points
The login records are checked for every external source IP address (srcip). An alert is triggered if that IP address:
- Has so many failed login attempts that it triggered the External User Login Failure Anomaly, and
- Had a successful login
A sample Interflow includes the source IP address (srcip), login type (login_type), source host (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), and user name (username).
The user ID-based alert subtype has the same XDR Kill Chain and Event Name as the source IP-based alert subtype, but differs in the Key Fields and Relevant Data Points and Use Case with Data Points.
Key Fields and Relevant Data Points
srcip_usersid— Windows SID associated with the source IP address

srcip— source IP addresssrcip_host— source host namesrcip_reputation— source reputationsource_geo.countryName— source countrydstip_host— destination host namelogin_type— type of loginusername— user namerelated_alert._id— link to the related External Account Login Failure Anomaly
Use Case with Data Points
The login records to a user account (srcip_usersid) are checked for every external source IP address (srcip). An alert is triggered if that user account:
-
Has so many failed login attempts that it triggered the External Account Login Failure Anomaly, and
-
Had a successful login
A sample Interflow includes the source IP address (srcip), login type (login_type), source host (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), and user name (username).
Stellar Cyber reports both internal and external versions of some alerts, with
different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:
- Addresses with a
srcip_typeordstip_typeofprivateare identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external). - Communications
between hosts where
srcip_typeanddstip_typeare bothprivateare considered internal communications. - When an anomaly is observed on an internal communication, the attack is considered to be internal.
- Stellar Cyber always sets the
srcipin the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show thedstipas the source address and thesrcipas the destination address, even though thesrcipwas the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record ofsrcipanddstipto understand which address initiated the threat event.
External Credential Stuffing
An anomalously large amount of username/password testing was detected on AWS, Okta, or Windows. Check the activity after successful logins, and consider blocking the source IP addresses.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] Credential Access (TA0006 )
-
Technique: Brute Force (T1110 )
-
Tags: [External]
Event Name
The xdr_event.name for this alert type in the Interflow data is external_credential_stuffing.
Key Fields and Relevant Data Points
msg_class— name of the service:cloudtrailfor AWS,oktafor Okta,Microsoft-Windows-Security-Auditingfor Windows
service_id— specific account ID of a service
login_failure_rate— rate of login failures per minute in the periodunknown_users_rate— rate of unknown user names per minute in the periodunknown_users_to_login_failures— ratio of unknown user names to login failures in the periodsuspicious_ips— suspicious source IP addresses (up to 100)possible_breached_ips— list of malicious IPs that may have successful breach activities
Use Case with Data Points
External credential stuffing is the constant testing of username/password combinations on the AWS, Okta, or Windows authentication functions. Login activity is monitored and if the number of failed logins is larger than normal for that service, an alert is triggered. The Interflow includes the service (msg_class), tenant's account ID on that service (service_id), suspicious source IP address (suspicious_ips), login failure rate (login_failure_rate), unknown user rate (unknown_users_rate), the ratio of unknown users to login failures (unknown_users_to_login_failures), and a list of source IP addresses that might have suspicious activities and should be investigated (possible_breached_ips).
Stellar Cyber reports both internal and external versions of some alerts, with
different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:
- Addresses with a
srcip_typeordstip_typeofprivateare identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external). - Communications
between hosts where
srcip_typeanddstip_typeare bothprivateare considered internal communications. - When an anomaly is observed on an internal communication, the attack is considered to be internal.
- Stellar Cyber always sets the
srcipin the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show thedstipas the source address and thesrcipas the destination address, even though thesrcipwas the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record ofsrcipanddstipto understand which address initiated the threat event.
External User Login Failure Anomaly
An anomalous number of login failures was observed for one of the following applications: SSH, SMTP, FTP, RDP, SMB, databases, Active Directory, Office 365, Okta, AWS CloudTrail, or Google Workspace. For Okta, an anomalous number of multi-factor authentication (MFA) failures was observed. Check with the user.
This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] Credential Access (TA0006 )
-
Technique: Brute Force (T1110 )
-
Tags: [External]
Event Name
The xdr_event.name for this alert type in the Interflow data is external_user_login_fail.
Key Fields and Relevant Data Points
srcip— source IP address
dstip— destination IP address
dstip_host— destination host nameevent_summary.total_failed— number of failed logins in the period
event_summary.total_successful— number of successful logins in the period
event_summary.total_fail_ratio— percent of failed logins in the period, which is:event_summary.total_failed/ (event_summary.total_failed+event_summary.total_successful)
accumulated_anomalous_failures— score value of the model indicating the degree of abnormal activitylogin_type— type of login, such asssh_traffic,okta_log, oraws_cloudtrailsrcip_host— source host namesrcip_reputation— source reputation
Use Case with Data Points
Login failures and successes are calculated periodically for every source (srcip) and destination (dstip) IP address. If the number of failures is significantly larger than the number of successes, an alert is triggered. The Interflow includes the login type (login_type), source host (srcip_host), and source reputation (srcip_reputation).
Stellar Cyber reports both internal and external versions of some alerts, with
different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:
- Addresses with a
srcip_typeordstip_typeofprivateare identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external). - Communications
between hosts where
srcip_typeanddstip_typeare bothprivateare considered internal communications. - When an anomaly is observed on an internal communication, the attack is considered to be internal.
- Stellar Cyber always sets the
srcipin the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show thedstipas the source address and thesrcipas the destination address, even though thesrcipwas the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record ofsrcipanddstipto understand which address initiated the threat event.
Impossible Travel Anomaly
A user logged in from locations that are geographically impossible to travel between in the time frame. Check with the user.
This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] XDR UBA (XTA0004)
-
Technique: XDR Location Anomaly (XT2001)
-
Tags: [User Behavior Analytics]
Event Name
The xdr_event.name for this alert type in the Interflow data is user_impossible_travel.
Key Fields and Relevant Data Points
srcip_usersid— source user ID
srcip_username— source user namesrcip— source IP addresssrcip_geo— source IP address geo location, including latitude and longitudedistance_deviation— deviation in distance (miles) between the two login locationstime_deviation— deviation in time (seconds) between the two login eventstravel_speed— calculated speed for the user to travel between the two location (miles/hour)appid_name— application name for the login eventlast_login_time— time of 2nd login, event 2 (E2)_id2— ID of E2_index2— index of E2srcip2— source IP address of E2srcip_geo2— source IP address geo location of E2, including latitude and longitudeengid_gateway— gateway IP address, used to determine geo location when source IP address is private
Use Case with Data Points
Login events (E1 and E2) are examined for a user (srcip_usersid), to see if the login locations (srcip_geo and srcip_geo2), that are at least 100 miles apart, changed faster (travel_speed = distance_deviation/time_deviation) than possible with the typical commercial flight speed of 600 miles/hour.
E1 is the basis for the Interflow. The srcip_usersid and srcip_username identify the user, appid_name identifies the application, and last_login_time identifies the time when the 2nd login event happened. You can find detailed information about E2 by checking id2 in index2, source IP (srcip2), and geo location (srcip_geo2).
Internal Account Login Failure Anomaly
An anomalously large number of login failures from an internal source IP address to an internal destination IP address was observed for an account. Check with the user.
This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.
XDR Kill Chain
-
Kill Chain Stage: Propagation
-
Tactic: [Internal] Credential Access (TA0006 )
-
Technique: Brute Force (T1110 )
-
Tags: [Internal]
Event Name
The xdr_event.name for this alert type in the Interflow data is internal_cloud_account_login_failure.
Key Fields and Relevant Data Points
srcip_usersid— account user ID
or
-
srcip_username— account user name, enriched fromevent_data.targetusername
The key field for this alert type can be either
srcip_usersidorsrcip_username, depending on the data feed. event_summary.total_failed— number of failed logins in the period
event_summary.total_successful— number of successful logins in the period
event_summary.total_fail_ratio— percent of failed logins in the period, which is:event_summary.total_failed/ (event_summary.total_failed+event_summary.total_successful)
accumulated_anomalous_failures— score value of the model indicating the degree of abnormal activitysrcip_host— host name of corresponding source IP addresslogin_type— type of loginsrcip_reputation— source reputation
Use Case with Data Points
Login failures and successes between any internal IP addresses are calculated periodically for every account (srcip_usersid). If the number of failures is significantly larger than the number of successes, an alert is triggered. A sample Interflow includes the login type (login_type), source host (srcip_host), and source reputation (srcip_reputation).
Stellar Cyber reports both internal and external versions of some alerts, with
different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:
- Addresses with a
srcip_typeordstip_typeofprivateare identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external). - Communications
between hosts where
srcip_typeanddstip_typeare bothprivateare considered internal communications. - When an anomaly is observed on an internal communication, the attack is considered to be internal.
- Stellar Cyber always sets the
srcipin the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show thedstipas the source address and thesrcipas the destination address, even though thesrcipwas the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record ofsrcipanddstipto understand which address initiated the threat event.
Internal Brute-Forced Successful User Login
A successful login was observed from an IP address that had previously seen a large number of login failures, or a successful login to a user account was observed from another IP address or IP addresses that had previously seen a large number of login failures to that account. Check with the user.![]()
This alert type has two subtypes:![]()
This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.
XDR Kill Chain
-
Kill Chain Stage: Propagation
-
Tactic: [Internal] Credential Access (TA0006 )
-
Technique: Brute Force (T1110 )
-
Tags: [Internal]
Event Name
The xdr_event.name for this alert type in the Interflow data is internal_user_success_brute_forcer.
Alert Subtype: Source IP-Based![]()
The source IP-based alert subtype has the same XDR Kill Chain and Event Name as the user ID-based alert subtype, but differs in the Key Fields and Relevant Data Points and Use Case with Data Points.
Key Fields and Relevant Data Points
srcip— source IP address
srcip_usersid— Windows SID associated with the source IP address
srcip_host— source host namesrcip_reputation— source reputationsource_geo.countryName— source countrydstip_host— destination host namelogin_type— type of loginusername— user namerelated_alert._id— link to the related Internal User Login Failure Anomaly
Use Case with Data Points
The login records to an internal IP address (dstip) are checked for every internal source IP address (srcip). An alert is triggered if that IP address:
-
Has so many failed login attempts that it triggered the Internal User Login Failure Anomaly, and
-
Had a successful login
A sample Interflow includes the source IP address (srcip), login type (login_type), source host name (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), and user name (username).
The user ID-based alert subtype has the same XDR Kill Chain and Event Name as the source IP-based alert subtype, but differs in the Key Fields and Relevant Data Points and Use Case with Data Points.
Key Fields and Relevant Data Points
srcip— source IP addresssrcip_usersid— Windows SID associated with the source IP address

srcip_host— source host namesrcip_reputation— source reputationsource_geo.countryName— source countrydstip_host— destination host namelogin_type— type of loginusername— user namerelated_alert._id— link to the related Internal Account Login Failure Anomaly
Use Case with Data Points
The login records to a user account (srcip_usersid) are checked for every internal source IP address (srcip). An alert is triggered if that user account:
-
Has so many failed login attempts that it triggered the Internal Account Login Failure Anomaly, and
-
Had a successful login
A sample Interflow includes the source IP address (srcip), login type (login_type), source host name (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), and user name (username).
Stellar Cyber reports both internal and external versions of some alerts, with
different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:
- Addresses with a
srcip_typeordstip_typeofprivateare identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external). - Communications
between hosts where
srcip_typeanddstip_typeare bothprivateare considered internal communications. - When an anomaly is observed on an internal communication, the attack is considered to be internal.
- Stellar Cyber always sets the
srcipin the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show thedstipas the source address and thesrcipas the destination address, even though thesrcipwas the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record ofsrcipanddstipto understand which address initiated the threat event.
Internal User Login Failure Anomaly
An anomalous number of login failures between internal IP addresses was observed for one of the following applications: SSH, SMTP, FTP, RDP, SMB, databases, Active Directory, Office 365, Okta, AWS CloudTrail, Google Workspace, Salesforce, or Microsoft Entra ID (formerly Azure Active Directory). Check with the user.
This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.
XDR Kill Chain
-
Kill Chain Stage: Propagation
-
Tactic: [Internal] Credential Access (TA0006 )
-
Technique: Brute Force (T1110 )
-
Tags: [Internal]
Event Name
The xdr_event.name for this alert type in the Interflow data is internal_user_login_fail.
Key Fields and Relevant Data Points
srcip— source IP address
dstip— destination IP address
dstip_host— destination host nameservice_id— source domain, workstation, organization, or serviceevent_summary.total_failed— number of failed logins in the period
event_summary.total_successful— number of successful logins in the period
event_summary.total_fail_ratio— percent of failed logins in the period, which is:event_summary.total_failed/ (event_summary.total_failed+event_summary.total_successful)
accumulated_anomalous_failures— score value of the model indicating the degree of abnormal activitylogin_type— type of login, such asssh_traffic,okta_log, oraws_cloudtrailsrcip_host— source host namesrcip_reputation— source reputation
Use Case with Data Points
Login failures and successes between internal IP addresses are calculated periodically for every source (srcip) and destination (dstip) IP address. If the number of failures is significantly larger than the number of successes, an alert is triggered. The Interflow includes the login type (login_type), source host (srcip_host), and source reputation (srcip_reputation).
Stellar Cyber reports both internal and external versions of some alerts, with
different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:
- Addresses with a
srcip_typeordstip_typeofprivateare identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external). - Communications
between hosts where
srcip_typeanddstip_typeare bothprivateare considered internal communications. - When an anomaly is observed on an internal communication, the attack is considered to be internal.
- Stellar Cyber always sets the
srcipin the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show thedstipas the source address and thesrcipas the destination address, even though thesrcipwas the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record ofsrcipanddstipto understand which address initiated the threat event.
Login Time Anomaly
A user logged in at an abnormal time. Check with the user.
This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] XDR UBA (XTA0004)
-
Technique: XDR Time Anomaly (XT4005)
-
Tags: [External; User Behavior Analytics]
Event Name
The xdr_event.name for this alert type in the Interflow data is user_login_time.
Key Fields and Relevant Data Points
srcip_usersid— source user ID
srcip_username— source user namesrcip_host— host name of corresponding source IP addresssrcip_geo.countryName— source countrydstip_host— host name of corresponding destination IP addressactual— actual login timetypical— typical login timeactual_range— actual login time rangetypical_range— typical login time range
Use Case with Data Points
Every user's (srcip_usersid) login time (actual) is compared to the typical login times (typical_range). If it is outside the range, an alert is triggered. The Interflow includes information such as the source user name (srcip_username), source host name (srcip_host), and source country (srcip_geo.countryName), as well as the destination host (dstip_host).
Malware on Disk
Malicious software or a potentially unwanted application found on a device and reported as not cleaned. Check with the user.
XDR Kill Chain
-
Kill Chain Stage: Propagation
-
Tactic: [Internal] XDR Malware (XTA0006)
-
Technique: XDR Miscellaneous Malware (XT6001)
-
Tags: [Internal; Malware]
Event Name
The xdr_event.name for this alert type in the Interflow data is malware_on_disk.
Key Fields and Relevant Data Points
hostip— IP address of the host
file_path— file path
computer_name— computer namemalware_engine— malware engine, can beSophosorWindows Defendergroup— type of malwaretype— status of malware
Use Case with Data Points
If either of the following occurs, an alert is triggered:
- Sophos engine indicates there is uncleaned malware
- Windows Defender indicates a failure or error when taking actions to protect the system
A sample Interflow includes the computer name (computer_name), malware engine (malware_engine), host IP address (hostip), path to the file (file_path), type of malware (group, for Sophos), and status of the malware (type, for Sophos).
User Login Location Anomaly
A user logged in from an anomalous location. Check with the user.
This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] XDR UBA (XTA0004)
-
Technique: XDR Location Anomaly (XT2001)
-
Tags: [External; User Behavior Analytics]
Event Name
The xdr_event.name for this alert type in the Interflow data is user_login_region.
Key Fields and Relevant Data Points
srcip_usersid— source user ID
distance_deviation— deviation in distance between two login locations (miles)srcip_host— host name of corresponding source IP addresssrcip_reputation— source reputationsrcip_geo.countryName— source countrysrcip_geo.region— source regionsrcip_geo.city— source citydstip_host— host name of corresponding destination IP addresslogin_type— type of login
Use Case with Data Points
Successful login events for certain login types (login_type) of a user (srcip_usersid) from a source host (srcip_host) and country location (srcip_geo.countryName are examined. If the detected login location is too far away (distance_deviation in miles) from that user's typical locations, an alert is triggered. The source host's reputation (srcip_reputation) is also checked. Map views of the Interflow include data points for the closest typical login locations for the user.
Carbon Black: XDR Anomaly
On a specific device, an anomalously large number of VMware Carbon Black endpoint log records or a rarely seen type of record has been observed compared to the typical number in a measured interval.
XDR Kill Chain
-
Kill Chain Stage: Persistent Foothold
-
Tactic: XDR EBA (XTA0001)
-
Technique: XDR Anomaly (XT1000)
-
Tags: []
Event Name
The xdr_event.name for this alert type in the Interflow data is carbonblack_edr_anomaly.
Key Fields and Relevant Data Points
process.command_id— command ID of the process
hostip— device internal IP address
host.external_ip— device external IP addressactual— actual volume of log records in the periodtypical— typical difference in volume of log records between this period and the previous period
Use Case with Data Points
The number of occurrences of Carbon Black endpoint (cloud) log, based on the “UNKNOWN“ threat category (event.type), is tabulated periodically. If this category occurs (actual) much more often compared to its history (typical) or a rarely seen type of record is observed, an alert is triggered. The Interflow includes information such as the file name (file.name), process (process.name), and description (xdr_event.description).
