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.

Azure Application Gateway Changed

The Azure Application Gateway Changed rules are used to identify events when an Azure application's gateway is changed. Any one or more of these will trigger the Azure Application Gateway Changed alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is azure_application_gateway_changed.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Azure Application Gateway Changed Alert Type

Azure DNS Zone Changed

The Azure DNS Zone Changed rules are used to identify events when an Azure DNS zone is changed. Any one or more of these will trigger the Azure DNS Zone Changed alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is azure_dns_zone_change.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Azure DNS Zone Changed Alert Type

Azure New CloudShell Created

The Azure New CloudShell Created rules are used to identify events when an Azure new Cloud Shell is changed. Any one or more of these will trigger the Azure New CloudShell Created alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is azure_new_cloudshell_created.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Azure New CloudShell Created Alert Type

Azure Security Configuration Changed

The Azure Security Configuration Changed rules are used to identify events when an Azure security configuration is changed. Any one or more of these will trigger the Azure Security Configuration Changed alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is azure_security_config_changed.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Azure Security Configuration Changed Alert Type

Bad Reputation Login

A successful login was observed 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.

Severity

50

Key Fields and Relevant Data Points

  • srcip — source IP address
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — 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).

DNS Query to TOR Proxy Domain

The DNS Query to TOR Proxy Domain rules are used to identify DNS queries to onion domains and proxy domains for TOR network. Any one or more of these will trigger the DNS Query to TOR Proxy Domain alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is dns_tor_proxy_domain.

Key Fields and Relevant Data Points

  • srcip — IP address sending TOR network related DNS query
  • dns.question.name — TOR network domain being resolved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to DNS Query to TOR Proxy Domain Alert Type

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 the following subtypes:

This alert type has a detection delay for on-time records while maintaining detection coverage for high latency data sources. High latency data will have a detection delay corresponding to their amount of latency.

The expected detection delay is 5-10 minutes, although it could be longer when there is an ingestion delay. Sources without ingestion delays will get their alerts between 5 and 10 minutes after ingestion.

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.

Severity

45

Key Fields and Relevant Data Points

  • srcip_usersid — cloud account user ID
  • scrip_username — cloud account user name
  • 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)
  • weighted_anomaly_score — net score based on weighted rating of successful versus failed attempts (scanning, login, or other). Scores greater than upper threshold are potentially malicious and less than lower threshold are benign.
  • srcip_host — host name of corresponding source IP address
  • login_type — type of login
  • srcip_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).

Alert Subtype: Office 365 / Entra ID

The Office 365 / Entra ID alert subtype is the same as the External Account Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Office 365 and Microsoft Entra ID (formerly Azure AD).

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is external_cloud_account_login_failure_o365_azure.

Alert Subtype: Windows Security Events

The Windows Security Events alert subtype is the same as the External Account Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from all Windows security events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is external_cloud_account_login_failure_windows.

...

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_type or dstip_type of private are 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_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in 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 the dstip as the source address and the srcip as the destination address, even though the srcip was 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 of srcip and dstip to 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 the following 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.

Severity

90

Alert Subtype: Source IP Based

The source IP-based alert subtype has the same XDR Kill Chain as the user ID-based alert subtype, but differs in the Key Fields and Relevant Data Points and Use Case with Data Points.

The xdr_event.subtype.name for this alert subtype in the Interflow data is external_user_success_brute_forcer_srcip.

Key Fields and Relevant Data Points

  • srcip — source IP address
  • srcip_usersid — Windows SID associated with the source IP address
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — user name
  • related_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:

  1. Has so many failed login attempts that it triggered the External User Login Failure Anomaly, and
  2. 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).

Alert Subtype: User ID Based

The user ID-based alert subtype has the same XDR Kill Chain as the source IP-based alert subtype, but differs in the Key Fields and Relevant Data Points and Use Case with Data Points.

The xdr_event.subtype.name for this alert subtype in the Interflow data is external_user_success_brute_forcer_srcip_usersid.

Key Fields and Relevant Data Points

  • srcip_usersid — Windows SID associated with the source IP address
  • srcip — source IP address
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — user name
  • related_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:

  1. Has so many failed login attempts that it triggered the External Account Login Failure Anomaly, and

  2. 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_type or dstip_type of private are 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_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in 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 the dstip as the source address and the srcip as the destination address, even though the srcip was 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 of srcip and dstip to understand which address initiated the threat event.

External Credential Stuffing

An anomalously large amount of username/password testing was observed 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.

Severity

50

Key Fields and Relevant Data Points

  • msg_class — name of the service: cloudtrail for AWS, okta for Okta, Microsoft-Windows-Security-Auditing for Windows
  • service_id — specific account ID of a service
  • login_failure_rate — rate of login failures per minute in the period
  • unknown_users_rate — rate of unknown user names per minute in the period
  • unknown_users_to_login_failures — ratio of unknown user names to login failures in the period
  • suspicious_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_type or dstip_type of private are 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_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in 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 the dstip as the source address and the srcip as the destination address, even though the srcip was 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 of srcip and dstip to 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 detection delay for on-time records while maintaining detection coverage for high latency data sources. High latency data will have a detection delay corresponding to their amount of latency.

The expected detection delay is 5-10 minutes, although it could be longer when there is an ingestion delay. Sources without ingestion delays will get their alerts between 5 and 10 minutes after ingestion.

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.

Severity

30

Key Fields and Relevant Data Points

  • srcip — source IP address
  • dstip — destination IP address
  • dstip_host — destination host name
  • 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)
  • weighted_anomaly_score — net score based on weighted rating of successful versus failed attempts (scanning, login, or other). Scores greater than upper threshold are potentially malicious and less than lower threshold are benign.
  • login_type — type of login, such as ssh_traffic, okta_log, or aws_cloudtrail
  • srcip_host — source host name
  • srcip_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).

Alert Subtype: Office 365 / Entra ID

The Office 365 / Entra ID alert subtype is the same as the External User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Office 365 and Microsoft Entra ID (formerly Azure AD).

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is external_user_login_fail_o365_azure.

Alert Subtype: Source IP Based

The Source IP-based alert subtype is the same as the External User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from network traffic, system logs, Linux events, and AWS events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is external_user_login_fail_srcip.

Alert Subtype: Destination IP Based

The Destination IP-based alert subtype is the same as the External User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from network traffic, system logs, Linux events, and AWS events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is external_user_login_fail_dstip.

Alert Subtype: Kerberos Events

The Kerberos Events alert subtype is the same as the External User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Kerberos events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is external_user_login_fail_kerberos.

Alert Subtype: Source IP Based Windows Logon Events

The Source IP-based Windows Logon Events alert subtype is the same as the External User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Windows logon events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is external_user_login_fail_src_win_logon.

Alert Subtype: Destination IP Based Windows Logon Events

The Destination IP-based Windows Logon Events alert subtype is the same as the External User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Windows logon events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is external_user_login_fail_dst_win_logon.

...

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_type or dstip_type of private are 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_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in 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 the dstip as the source address and the srcip as the destination address, even though the srcip was 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 of srcip and dstip to 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 detection delay for on-time records while maintaining detection coverage for high latency data sources. High latency data will have a detection delay corresponding to their amount of latency.

The expected detection delay is 5-10 minutes, although it could be longer when there is an ingestion delay. Sources without ingestion delays will get their alerts between 5 and 10 minutes after ingestion.

For the Impossible Travel Anomaly, there are two chances for ingestion delay, so the slowest of the two records will define the delay. This alert type is also sensitive to the 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.

Severity

60

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the source user
  • srcip_username — source user name
  • srcip — source IP address
  • srcip_host — source host name
  • srcip_geo — source IP address geo location, including latitude and longitude
  • distance_deviation — deviation in distance (miles) between the two login locations
  • time_deviation — deviation in time (seconds) between the two login events
  • travel_speed — calculated speed for the user to travel between the two location (miles/hour)
  • appid_name — application name for the login event
  • last_login_time — time of 2nd login, event 2 (E2)
  • _id2 — ID of E2
  • _index2 — index of E2
  • srcip2 — source IP address of E2
  • srcip_geo2 — source IP address geo location of E2, including latitude and longitude
  • engid_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 the following subtypes:

This alert type has a detection delay for on-time records while maintaining detection coverage for high latency data sources. High latency data will have a detection delay corresponding to their amount of latency.

The expected detection delay is 5-10 minutes, although it could be longer when there is an ingestion delay. Sources without ingestion delays will get their alerts between 5 and 10 minutes after ingestion.

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.

Severity

60

Key Fields and Relevant Data Points

  • srcip_usersid — account user ID

    or

  • srcip_username — account user name, enriched from event_data.targetusername

    The key field for this alert type can be either srcip_usersid or srcip_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)
  • weighted_anomaly_score — net score based on weighted rating of successful versus failed attempts (scanning, login, or other). Scores greater than upper threshold are potentially malicious and less than lower threshold are benign.
  • srcip_host — host name of corresponding source IP address
  • login_type — type of login
  • srcip_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).

Alert Subtype: Windows Logon Events

The Windows Logon Events alert subtype is the same as the Internal Account Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Windows logon events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_cloud_account_login_failure_win_logon.

Alert Subtype: Kerberos Events

The Kerberos Events alert subtype is the same as the Internal Account Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Kerberos events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_cloud_account_login_failure_kerberos.

Alert Subtype: NTLM Events

The NTLM Events alert subtype is the same as the Internal Account Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from NTLM events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_cloud_account_login_failure_ntlm.

Alert Subtype: Hibun Security Logs

The Hibun Security Logs alert subtype is the same as the Internal Account Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Hibun security logs.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_cloud_account_login_failure_hibun.

...

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_type or dstip_type of private are 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_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in 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 the dstip as the source address and the srcip as the destination address, even though the srcip was 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 of srcip and dstip to 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 the following 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.

Severity

95

Alert Subtype: Source IP Based

The source IP-based alert subtype has the same XDR Kill Chain as the user ID-based alert subtype, but differs in the Key Fields and Relevant Data Points and Use Case with Data Points.

The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_user_success_brute_forcer_srcip_usersid.

Key Fields and Relevant Data Points

  • srcip — source IP address
  • srcip_usersid — Windows SID associated with the source IP address
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — user name
  • related_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:

  1. Has so many failed login attempts that it triggered the Internal User Login Failure Anomaly, and

  2. 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).

Alert Subtype: User ID Based

The user ID-based alert subtype has the same XDR Kill Chain as the source IP-based alert subtype, but differs in the Key Fields and Relevant Data Points and Use Case with Data Points.

The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_user_success_brute_forcer_srcip.

Key Fields and Relevant Data Points

  • srcip — source IP address
  • srcip_usersid — Windows SID associated with the source IP address
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — user name
  • related_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:

  1. Has so many failed login attempts that it triggered the Internal Account Login Failure Anomaly, and

  2. 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_type or dstip_type of private are 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_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in 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 the dstip as the source address and the srcip as the destination address, even though the srcip was 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 of srcip and dstip to 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 detection delay for on-time records while maintaining detection coverage for high latency data sources. High latency data will have a detection delay corresponding to their amount of latency.

The expected detection delay is 5-10 minutes, although it could be longer when there is an ingestion delay. Sources without ingestion delays will get their alerts between 5 and 10 minutes after ingestion.

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.

Severity

60

Key Fields and Relevant Data Points

  • srcip — source IP address
  • service_id — source domain, workstation, organization, or service
  • dstip — destination IP address
  • dstip_host — destination host name
  • 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)
  • weighted_anomaly_score — net score based on weighted rating of successful versus failed attempts (scanning, login, or other). Scores greater than upper threshold are potentially malicious and less than lower threshold are benign.
  • login_type — type of login, such as ssh_traffic, okta_log, or aws_cloudtrail
  • srcip_host — source host name
  • srcip_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).

Alert Subtype: Source IP Based

The Source IP-based alert subtype is the same as the Internal User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from network traffic, system logs, Linux events, and AWS events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_user_login_fail_srcip.

Alert Subtype: Destination IP Based

The Destination IP-based alert subtype is the same as the Internal User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from network traffic, system logs, Linux events, and AWS events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_user_login_fail_dstip.

Alert Subtype: NTLM Events

The NTLM Events alert subtype is the same as the Internal User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from NTLM events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_user_login_fail_ntlm.

Alert Subtype: Kerberos Events

The Kerberos Events alert subtype is the same as the Internal User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Kerberos events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_user_login_fail_kerberos.

Alert Subtype: Windows Logon Events

The Windows Logon Events alert subtype is the same as the Internal User Login Failure Anomaly alert type above, with the following differences:

  • The subtype is for data sources from Windows Logon events.

  • The xdr_event.subtype.name for this alert subtype in the Interflow data is internal_user_login_fail_win_logon.

...

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_type or dstip_type of private are 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_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in 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 the dstip as the source address and the srcip as the destination address, even though the srcip was 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 of srcip and dstip to 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.

This alert type reads the System Timezone in Global Settings and puts the timezone into the alert descriptions. In Global Settings, set your timezone relative to UTC.

When a Login Time Anomaly occurs, the timezone is bound to the alert description with the following priorities:

  • The timezone inferred from engid_gateway takes precedence over the DP timezone, but only when it is present. If engid_gateway is present, the description will use the timezone where the login actually happened.

  • If engid_gateway is not present, the DP timezone setting is used.

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.

Severity

40

Key Fields and Relevant Data Points

  • srcip_usersid — key ID of the source user

    or

  • event_data.TargetUserName — name of the user (Windows event)

  • The key field for this alert type can be either srcip_usersid or event_data.TargetUserName, depending on the data feed.

  • srcip_username — source user name
  • srcip_host — host name of corresponding source IP address
  • srcip_geo.countryName — source country
  • actual_range — actual login time range
  • typical_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

Sophos is deprecated from this alert type as of the 5.2.0 release. It is replaced by Sophos alert integration.

Malicious software or a potentially unwanted application was 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.

Severity

90 (Windows Defender)

80 (Sophos)

Key Fields and Relevant Data Points

  • hostip — IP address of the host
  • file_path — file path
  • computer_name — computer name
  • malware_engine — malware engine, can be Sophos or Windows Defender
  • group — type of malware
  • type — status of malware

Use Case with Data Points

If either of the following occurs, an alert is triggered:

  • Windows Defender indicates a failure or error when taking actions to protect the system
  • Sophos engine indicates there is uncleaned malware

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).

Microsoft Entra Hybrid Health AD FS New Server

The Microsoft Entra Hybrid Health AD FS New Server rules are used to identify a new hybrid health AD FS server. Any one or more of these will trigger the Microsoft Entra Hybrid Health AD FS New Server alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is microsoft_entra_hybrid_health_adfs_new_server.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Microsoft Entra Hybrid Health AD FS New Server Alert Type

Microsoft Entra Hybrid Health AD FS Service Deleted

The Microsoft Entra Hybrid Health AD FS Service Deleted rules are used to identify events when a hybrid health AD FS server is deleted. Any one or more of these will trigger the Microsoft Entra Hybrid Health AD FS Service Deleted alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is microsoft_entra_hybrid_health_adfs_service_deleted.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Microsoft Entra Hybrid Health AD FS Service Deleted Alert Type

Phishing Domain with File Extension TLD

The Phishing Domain with File Extension TLD rules are used to identify DNS queries to Top-Level Domains (TLDs) that resemble file extensions. Any one or more of these will trigger the Phishing Domain with File Extension TLD alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is dns_phishing_file_extension_tld.

Key Fields and Relevant Data Points

  • srcip — IP address sending TOR network related DNS query
  • dns.question.name — TOR network domain being resolved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Phishing Domain with File Extension TLD Alert Type

Suspicious Azure Account Permission Elevation

The Suspicious Azure Account Permission Elevation rules are used to identify suspicious Azure account permission elevation. Any one or more of these will trigger the Suspicious Azure Account Permission Elevation alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_account_permission_elevation.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Account Permission Elevation Alert Type

Suspicious Azure Deployment Activity

The Suspicious Azure Deployment Activity rules are used to identify suspicious Azure deployment activity. Any one or more of these will trigger the Suspicious Azure Deployment Activity alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_deployment_activity.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Deployment Activity Alert Type

Suspicious Azure Firewall Activity

The Suspicious Azure Firewall Activity rules are used to identify suspicious Azure firewall activity. Any one or more of these will trigger the Suspicious Azure Firewall Activity alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_firewall_activity.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Firewall Activity Alert Type

Suspicious Azure Key Vault Activity

The Suspicious Azure Key Vault Activity rules are used to identify suspicious Azure Key Vault activity. Any one or more of these will trigger the Suspicious Azure Key Vault Activity alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_key_vault_activity.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Key Vault Activity Alert Type

Suspicious Azure Kubernetes Activity: Credential Access

The Suspicious Azure Kubernetes Activity: Credential Access rules are used to identify suspicious Azure Kubernetes activity usually in the credential access stage. Any one or more of these will trigger the Suspicious Azure Kubernetes Activity: Credential Access alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_kubernetes_activity_credential_access.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Kubernetes Activity: Credential Access Alert Type

Suspicious Azure Kubernetes Activity: Defense Evasion

The Suspicious Azure Kubernetes Activity: Defense Evasion rules are used to identify suspicious Azure Kubernetes activity usually in the defense evasion stage. Any one or more of these will trigger the Suspicious Azure Kubernetes Activity: Defense Evasion alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_kubernetes_activity_defense_evasion.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Kubernetes Activity: Defense Evasion Alert Type

Suspicious Azure Kubernetes Activity: Impact

The Suspicious Azure Kubernetes Activity: Impact rules are used to identify suspicious Azure Kubernetes activity usually in the impact stage. Any one or more of these will trigger the Suspicious Azure Kubernetes Activity: Impact alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_kubernetes_activity_impact.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Kubernetes Activity: Impact Alert Type

Suspicious Azure Kubernetes Activity: Persistence

The Suspicious Azure Kubernetes Activity: Persistence rules are used to identify suspicious Azure Kubernetes activity usually in the persistence stage. Any one or more of these will trigger the Suspicious Azure Kubernetes Activity: Persistence alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_kubernetes_activity_persistence.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Kubernetes Activity: Persistence Alert Type

Suspicious Azure Kubernetes Activity: Privilege Escalation

The Suspicious Azure Kubernetes Activity: Privilege Escalation rules are used to identify suspicious Azure Kubernetes activity usually in the privilege escalation stage. Any one or more of these will trigger the Suspicious Azure Kubernetes Activity: Privilege Escalation alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_kubernetes_activity_privilege_escalation.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Kubernetes Activity: Privilege Escalation Alert Type

Suspicious Azure Network Activity

The Suspicious Azure Network Activity rules are used to identify suspicious Azure network activity. Any one or more of these will trigger the Suspicious Azure Network Activity alert type.

Event Name

The xdr_event.name for this alert type in the Interflow data is suspicious_azure_network_activity.

Key Fields and Relevant Data Points

  • callerIpAddress — IP address of the user who performed the activity
  • resourceId — identifier of the resource involved
  • operationName — name of the activity
  • category — activity category
  • resultType — result of the operation
  • identity.authorization.evidence.principalType — type of the service principal involved
  • identity.authorization.evidence.principalId — identifier of the service principal involved
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Azure Network Activity Alert Type

User Login Location Anomaly

A login to a user account occurred from a source IP address that is anomalously distant from the nearest location typically observed for logins to that user account.

This alert type has a detection delay for on-time records while maintaining detection coverage for high latency data sources. High latency data will have a detection delay corresponding to their amount of latency.

The expected detection delay is 5-10 minutes, although it could be longer when there is an ingestion delay. Sources without ingestion delays will get their alerts between 5 and 10 minutes after ingestion.

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.

Severity

50

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the source user
  • distance_deviation — deviation in distance between two login locations (miles)
  • srcip_host — host name of corresponding source IP address
  • srcip_reputation — source reputation
  • srcip_geo.countryName — source country name
  • srcip_geo.region — source region name
  • srcip_geo.city — source city name
  • dstip_host — host name of corresponding destination IP address
  • login_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.

Severity

30

Key Fields and Relevant Data Points

  • hostip — device internal IP address
  • host.external_ip — device external IP address
  • actual — actual volume of log records in the period
  • typical — 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).