Alert Types That Use the Linux Index
The Alert Types listed below use the Linux 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.
- File Action Anomaly
- Process Anomaly
- Bad Reputation Login
- Command Anomaly
- External Account Login Failure Anomaly
- External User Login Failure Anomaly
- External Brute-Forced Successful User Login
- File Creation Anomaly
- Google Workspace Attack Warning
- Google Workspace Suspicious Activities
- Google Workspace Account Manipulation
- Google Workspace User Suspended
- Internal Account Login Failure Anomaly
- Internal User Login Failure Anomaly
- Internal Brute-Forced Successful User Login
- Uncommon Process Anomaly
- Abnormal Parent / Child Process
- Impossible Travel Anomaly
- User Login Location Anomaly
- Login Time Anomaly
- User Process Usage Anomaly
File Action Anomaly
Actions, such as move, copy, delete, or change attribute, were taken on a file or files an anomalous number of times. Investigate the actions and the user to see if this is expected.
XDR Kill Chain
-
Kill Chain Stage: Exfiltration & Impact
-
Tactic: Impact (TA0040 )
-
Technique: Data Manipulation (T1565 )
-
Tags: []
Event Name
The xdr_event.name
for this alert type in the Interflow data is anomalous_file_action
.
Key Fields and Relevant Data Points
secondary
— user nameactual
— actual number of file actions in the periodtypical
— typical number of file actions in the periodpath
— path to the file
Use Case with Data Points
The number of file actions for each user (command
) is calculated periodically. If the volume (actual
) is anomalous compared to the typical volume (typical
) of file actions in any period, an alert is triggered. The Interflow includes the directory to the file (path
).
Process Anomaly
A process has been launched an anomalously large number of times. Investigate the process and the user to see if this is expected.
XDR Kill Chain
-
Kill Chain Stage: Persistent Foothold
-
Tactic: XDR EBA (XTA0001)
-
Technique: XDR Process Anomaly (XT1001)
-
Tags: []
Event Name
The xdr_event.name
for this alert type in the Interflow data is bad_process
.
Key Fields and Relevant Data Points
process_name
— name of the processhostip
— host IP addresshostip_host
— host nameactual
— actual number of launches in the periodtypical
— typical number of launches in the periodprocess_user
— user who launched the process
Use Case with Data Points
The number of times a process (process_name
) has been launched is calculated periodically. If the volume (actual
) is much larger than the typical volume (typical
) of the command or other commands in any period, an alert is triggered. The Interflow includes the name of the user who launched the process (process_user
).
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 addresssrcip_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
).
Command Anomaly
A command has been executed an anomalously large number of times compared to its typical executions or those of other commands. Investigate the command and the user to determine if this is expected.
XDR Kill Chain
-
Kill Chain Stage: Persistent Foothold
-
Tactic: Execution (TA0002 )
-
Technique: Command and Scripting Interpreter (T1059 )
-
Tags: []
Event Name
The xdr_event.name
for this alert type in the Interflow data is command_anomaly
.
Key Fields and Relevant Data Points
command
— command executedactual
— actual number of executions in the periodtypical
— typical number of executions in the periodcwd
— current working directory from which the command executedhostip
— host running the agent sensorsrcip
— source IP address from which the command was runusername
— user name who ran the command
Use Case with Data Points
The number of times a command (command
) has been executed is calculated periodically. If the volume (actual
) is much larger than the typical volume (typical
) of the command or other commands in any period, an alert is triggered. The Interflow includes the directory from which the command was executed (cwd
), the host and source IP addresses (hostip
and srcip
) from which the command was executed, and the name of the user who ran the command (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 IDscrip_username
— cloud account user nameevent_summary.total_failed
— number of failed logins in the periodevent_summary.total_successful
— number of successful logins in the periodevent_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_type
ordstip_type
ofprivate
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
anddstip_type
are bothprivate
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 thedstip
as the source address and thesrcip
as the destination address, even though thesrcip
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 ofsrcip
anddstip
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 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 addressdstip
— destination IP addressdstip_host
— destination host nameevent_summary.total_failed
— number of failed logins in the periodevent_summary.total_successful
— number of successful logins in the periodevent_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_cloudtrail
srcip_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_type
ordstip_type
ofprivate
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
anddstip_type
are bothprivate
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 thedstip
as the source address and thesrcip
as the destination address, even though thesrcip
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 ofsrcip
anddstip
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 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 addresssrcip_usersid
— Windows SID associated with the 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 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 addresssrcip
— 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_type
ordstip_type
ofprivate
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
anddstip_type
are bothprivate
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 thedstip
as the source address and thesrcip
as the destination address, even though thesrcip
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 ofsrcip
anddstip
to understand which address initiated the threat event.
File Creation Anomaly
A file or files were created an anomalously large number of times. Check with the user to see if this is expected.
XDR Kill Chain
-
Kill Chain Stage: Persistent Foothold
-
Tactic: XDR EBA (XTA0001)
-
Technique: XDR File Anomaly (XT1003)
-
Tags: []
Event Name
The xdr_event.name
for this alert type in the Interflow data is file_creation
.
Key Fields and Relevant Data Points
secondary
— user nameactual
— actual number of file creations in the periodtypical
— typical number of file creations in the periodpath
— path to the file(s) created
Use Case with Data Points
The number of file creations for each user (command
) is calculated periodically. If the volume (actual
) is much larger than the typical volume (typical
) of file creations in any period, an alert is triggered. The Interflow includes the directory to the file (path
).
Google Workspace Attack Warning
Attacks to a Google Workspace account were detected. Check with the account holder.
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 gsuite_attack_warning
.
Key Fields and Relevant Data Points
actor.email
— key ID for the accountsrcip
— source IP addresssrcip_host
— source host nameevent_detail.name
— Google Workspace suspicious event nameevent_detail.type
— Google Workspace suspicious event type
Use Case with Data Points
For each Google Workspace account (actor.email
), attacks are searched periodically. If an attack is identified, an alert is triggered. The Interflow includes the account ID (actor.email
), source IP address (srcip
), Google Workspace event name (event_detail.name
), and Google Workspace event type (event_detail.type
).
Google Workspace Suspicious Activities
Suspicious activities were detected in a Google Workspace account. Check with the account holder.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] XDR UBA (XTA0004)
-
Technique: XDR Login Anomaly (XT4006)
-
Tags: [External]
Event Name
The xdr_event.name
for this alert type in the Interflow data is gsuite_suspicious_activities
.
Key Fields and Relevant Data Points
actor.email
— key ID for the accountsrcip
— source IP addresssrcip_host
— source host nameevent_detail.name
— Google Workspace suspicious event nameevent_detail.type
— Google Workspace suspicious event type
Use Case with Data Points
For each Google Workspace account (actor.email
), suspicious activities are searched periodically. If suspicious activities are detected, an alert is triggered. The Interflow includes the account ID (actor.email
), source IP address (srcip
), Google Workspace event name (event_detail.name
), and Google Workspace event type (event_detail.type
).
Google Workspace Account Manipulation
A Google Workspace user was suspended for a suspicious reason or because a password leak was detected. Check with the user.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] XDR UBA (XTA0004)
-
Technique: XDR Account Anomaly (XT4007)
-
Tags: [External]
Event Name
The xdr_event.name
for this alert type in the Interflow data is gsuite_account_manipulation
.
Key Fields and Relevant Data Points
event_detail.affected_email_address
— key ID for the accountevent_detail.name
— Google Workspace suspicious event nameevent_detail.type
— Google Workspace suspicious event type
Use Case with Data Points
For each Google Workspace account (event_detail.affected_email_address
), account manipulation is evaluated periodically. This alert is triggered if the Google Security center reports a leaked password or a user account being suspended for specific reasons. The Interflow includes the account ID (event_detail.affected_email_address
), Google Workspace event name (event_detail.name
), and Google Workspace event type (event_detail.type
).
Google Workspace User Suspended
A Google Workspace user was suspended. Check with the user.
XDR Kill Chain
-
Kill Chain Stage: Initial Attempts
-
Tactic: [External] XDR UBA (XTA0004)
-
Technique: XDR Account Anomaly (XT4007)
-
Tags: [External]
Event Name
The xdr_event.name
for this alert type in the Interflow data is gsuite_user_suspended
.
Key Fields and Relevant Data Points
actor.email
— key ID for the accountsrcip
— source IP addresssrcip_host
— source host nameevent_detail.name
— Google Workspace suspicious event nameevent_detail.type
— Google Workspace suspicious event type
Use Case with Data Points
For each Google Workspace account (actor.email
), suspension status is searched periodically. If a user is suspended, an alert is triggered. The Interflow includes the account ID (actor.email
), source IP address (srcip
), Google Workspace event name (event_detail.name
), and Google Workspace event type (event_detail.type
).
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 IDor
-
srcip_username
— account user name, enriched fromevent_data.targetusername
The key field for this alert type can be either
srcip_usersid
orsrcip_username
, depending on the data feed. event_summary.total_failed
— number of failed logins in the periodevent_summary.total_successful
— number of successful logins in the periodevent_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_type
ordstip_type
ofprivate
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
anddstip_type
are bothprivate
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 thedstip
as the source address and thesrcip
as the destination address, even though thesrcip
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 ofsrcip
anddstip
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 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 addressdstip
— destination IP addressdstip_host
— destination host nameservice_id
— source domain, workstation, organization, or serviceevent_summary.total_failed
— number of failed logins in the periodevent_summary.total_successful
— number of successful logins in the periodevent_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_cloudtrail
srcip_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_type
ordstip_type
ofprivate
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
anddstip_type
are bothprivate
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 thedstip
as the source address and thesrcip
as the destination address, even though thesrcip
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 ofsrcip
anddstip
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 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 addresssrcip_usersid
— Windows SID associated with the 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 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 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 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_type
ordstip_type
ofprivate
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
anddstip_type
are bothprivate
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 thedstip
as the source address and thesrcip
as the destination address, even though thesrcip
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 ofsrcip
anddstip
to understand which address initiated the threat event.
Uncommon Process Anomaly
An asset launched a process that has never been observed by Stellar Cyber (or been seen very rarely). This could indicate a malware attack.
XDR Kill Chain
-
Kill Chain Stage: Persistent Foothold
-
Tactic: XDR EBA (XTA0001)
-
Technique: XDR Process Anomaly (XT1001)
-
Tags: []
Event Name
The xdr_event.name
for this alert type in the Interflow data is network_uncommon_process
.
Key Fields and Relevant Data Points
process_name
— name of the processdays_silent
— number of days since this process was last seensrcip
— source IP address running the processprocess_user
— name of the user running the process
Use Case with Data Points
If a process (process_name
) has never been observed by Stellar Cyber or been seen very rarely (days_silent
), an alert is triggered. The Interflow includes the user (process_user
) and host (srcip
) that executed the process.
Abnormal Parent / Child Process
A process that typically launches a small, consistent number of child processes launched a new child process. Investigate the child process to see if it is benign.
This alert type has two subtype categories:
Alert Subtype: Machine Learning Anomaly Detection
XDR Kill Chain
-
Kill Chain Stage: Persistent Foothold
-
Tactic: XDR EBA (XTA0001)
-
Technique: XDR Process Relationship Anomaly (XT1002)
-
Tags: []
Event Name
The xdr_event.name
for this alert type in the Interflow data is parent_child
.
Key Fields and Relevant Data Points
parent_proc_name
— name of the parent processsrcip_host
— host name of corresponding source IP addressprocess_name
— name of the processstability
— score measuring the time since the parent process launched the last child processdiversity
— score measuring the number of child processes that the parent process spawneddays_stable
— time since the parent process launched the last child processchild_count
— number of child processes that the parent process spawned
Use Case with Data Points
Each pair of parent/child processes (parent_proc_name
and process_name
) is examined periodically. If a parent process (parent_proc_name
) with a small number of child processes (diversity
, child_count
) has not launched a new child process (process_name
) for a long time (stability
, days_stable
) launches a new child process from a host (srcip_host
), an alert is triggered.
Alert Subtype: Rule Based Detection
The Parent/Child Suspicious Process Creation rules are used to identify suspicious activity with parent/child relationships associated with process creation. Any one or more of these will trigger the Parent/Child Suspicious Process Creation alert types.
Key Fields and Relevant Data Points
hostip
— host IP addresshostip_host
— host namestellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Parent/Child Suspicious Process Creation Alert Type
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 IDsrcip_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
).
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 IDdistance_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.
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 IDsrcip_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
).
User Process Usage Anomaly
A user who typically executes a small, consistent number of processes suddenly executed a new process. Investigate the process, to see if it is benign. Check with the user to see if this process was expected.
XDR Kill Chain
-
Kill Chain Stage: Persistent Foothold
-
Tactic: XDR EBA (XTA0001)
-
Technique: XDR Process Anomaly (XT1001)
-
Tags: [User Behavior Analytics]
Event Name
The xdr_event.name
for this alert type in the Interflow data is user_uncommon_process
.
Key Fields and Relevant Data Points
srcip_usersid
— non-Windows source user IDor
user.identifier
— Windows source user IDThe key field for this alert type can be either
srcip_usersid
oruser.identifier
, depending on the data feed.process_name
— name of the processsrcip_host
— host name of corresponding source IP addressdstip_host
— host name of corresponding destination IP addresssrcip_username
— source user namestability
— score measuring the time since the last new process was executeddiversity
— score measuring the number of processes that the user executeddays_stable
— time since the last new process was executedchild_count
— number of processes that the user executed
Use Case with Data Points
Looks for a user (srcip_usersid
or user.identifier
and a srcip_username
) with a small number of processes (diversity
, child_count
) who also has not used a new process for a long time (stability
, days_stable
). If a new process (process_name
) appears on a host (srcip_host
) with this user and connects to another host (dstip_host
), an alert is triggered.
The user is identified with the scrip_userid
or user.identifier
and scrip_username
fields. The process is identified with the process_name
field. The host on which the user is running the process is identified with the srcip_host
field. The destination of the traffic generated by the process is identified with the dstip_host
field. Stability is identified with the stability
field, and diversity is identified with the diversity
field.