Alert Types That Use the AWS Index
The alert types listed below use the AWS 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.
- Account MFA Login Failure Anomaly
- AWS AMI Made Public
- AWS Logging Stopped
- AWS S3 Ransomware
- Bad Reputation Login
- External Account Login Failure Anomaly
- External Brute-Forced Successful User Login
- External Credential Stuffing
- External User Login Failure Anomaly
- Impossible Travel Anomaly
- Internal Account Login Failure Anomaly
- Internal Brute-Forced Successful User Login
- Internal User Login Failure Anomaly
- Login Time Anomaly
- Potentially Malicious AWS Activity
- Suspicious AWS Bucket Enumeration
- Suspicious AWS EBS Activity
- Suspicious AWS EC2 Activity
- Suspicious AWS ELB Activity
- Suspicious AWS IAM Activity
- Suspicious AWS Login Failure
- Suspicious AWS RDS Event
- Suspicious AWS Root Account Activity
- Suspicious AWS Route 53 Activity
- Suspicious AWS SSL Certificate Activity
- Suspicious AWS VPC Flow Logs Modification
- Suspicious AWS VPC Mirror Session
- Suspicious Modification of AWS CloudTrail Logs
- Suspicious Modification of AWS Route Table
- Suspicious Modification of S3 Bucket
- User Login Location Anomaly
Account MFA Login Failure Anomaly
An anomalously large number of Multi-Factor Authentication (MFA) user login failures was observed for an account. Check with the user.
This alert type has the following subtypes:
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 cloud_account_login_failure_okta
.
Severity
45
Key Fields and Relevant Data Points
srcip_usersid
— cloud account user IDsrcip_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
)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 addresslogin_type
— type of loginsrcip_reputation
— source reputation
Use Case with Data Points
Multi-Factor Authentication 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: Rule Based Alert Type
The Suspicious AWS Login Failure rules are used to identify suspicious AWS account login failures. Any one or more of these will trigger the AWS Cloud Account Login Failure alert type.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
AWS AMI Made Public
An AWS AMI was made public. Check with the user to make sure this was intentional.
XDR Kill Chain
-
Kill Chain Stage: Propagation
-
Tactic: Privilege Escalation (TA0004 )
-
Technique: Valid Accounts (T1078 )
-
Tags: []
XDR Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_ami_public
.
Severity
70
Key Fields and Relevant Data Points
userIdentity.accountId
— key ID for the accountuserIdentity.userName
— AWS account user nameuserIdentity.type
— AWS account typeeventName
— AWS event nameeventSource
— AWS event sourceeventType
— AWS event type
Use Case with Data Points
For each AWS account (userIdentity.accountId
), activity to make an AMI public is monitored. If an AMI is made public, an alert is triggered. The Interflow includes the account ID (userIdentity.accountId
), user name (userIdentity.userName
), account type (userIdentity.type
), AWS event name (eventName
), AWS event source (eventSource
), and AWS event type (eventType
).
AWS Logging Stopped
AWS CloudTrail logging was stopped. Check with the user to make sure this was intentional.
XDR Kill Chain
-
Kill Chain Stage: Persistent Foothold
-
Tactic: Defense Evasion (TA0005 )
-
Technique: Impair Defenses (T1562 )
-
Tags: []
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_stoplogging
.
Severity
70
Key Fields and Relevant Data Points
userIdentity.accountId
— key ID for the accountuserIdentity.userName
— AWS account user nameuserIdentity.type
— AWS account typeeventName
— AWS event nameeventSource
— AWS event sourceeventType
— AWS event type
Use Case with Data Points
For each AWS account (userIdentity.accountId
), log disabling is monitored. Logging is enabled by default, so if logging is disabled, an alert is triggered. The Interflow includes the account ID (userIdentity.accountId
), AWS account user name (userIdentity.userName
), AWS account type (userIdentity.type
), AWS event name (eventName
), AWS event source (eventSource
), and AWS event type (eventType
).
AWS S3 Ransomware
Possible AWS S3 ransomware was observed. Check with the user.
XDR Kill Chain
-
Kill Chain Stage: Exfiltration & Impact
-
Tactic: Impact (TA0040 )
-
Technique: Data Encrypted for Impact (T1486 )
-
Tags: [Malware; Ransomware]
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_s3_ransomware
.
Severity
90
Key Fields and Relevant Data Points
userIdentity.accountId
— key ID for the accountuserIdentity.userName
— AWS account user nameuserIdentity.type
— AWS account typeeventName
— AWS event nameeventSource
— AWS event sourceeventType
— AWS event type
Use Case with Data Points
For each AWS account user name (userIdentity.userName
), suspicious S3 ransomware is monitored. If ransomware is detected, an alert is triggered. The Interflow includes the account ID (userIdentity.accountId
), AWS account user name (userIdentity.userName
), AWS account type (userIdentity.type
), AWS event name (eventName
), AWS event source (eventSource
), and AWS event type (eventType
).
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 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
).
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 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
)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 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
).
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 isexternal_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 isexternal_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
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 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 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 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 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.
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 Windowsservice_id
— specific account ID of a servicelogin_failure_rate
— rate of login failures per minute in the periodunknown_users_rate
— rate of unknown user names per minute in the periodunknown_users_to_login_failures
— ratio of unknown user names to login failures in the periodsuspicious_ips
— suspicious source IP addresses (up to 100)possible_breached_ips
— list of malicious IPs that may have successful breach activities
Use Case with Data Points
External credential stuffing is the constant testing of username/password combinations on the AWS, Okta, or Windows authentication functions. Login activity is monitored and if the number of failed logins is larger than normal for that service, an alert is triggered. The Interflow includes the service (msg_class
), tenant's account ID on that service (service_id
), suspicious source IP address (suspicious_ips
), login failure rate (login_failure_rate
), unknown user rate (unknown_users_rate
), the ratio of unknown users to login failures (unknown_users_to_login_failures
), and a list of source IP addresses that might have suspicious activities and should be investigated (possible_breached_ips
).
Stellar Cyber reports both internal and external versions of some alerts, with
different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound
or outbound
. Use the following as a guide for these concepts:
- Addresses with a
srcip_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 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_user_login_fail
.
Severity
30
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
)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 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
).
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 isexternal_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 isexternal_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 isexternal_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 isexternal_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 isexternal_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 isexternal_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
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.
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 usersrcip_username
— source user namesrcip
— source IP addresssrcip_host
— source host namesrcip_geo
— source IP address geo location, including latitude and longitudedistance_deviation
— deviation in distance (miles) between the two login locationstime_deviation
— deviation in time (seconds) between the two login eventstravel_speed
— calculated speed for the user to travel between the two location (miles/hour)appid_name
— application name for the login eventlast_login_time
— time of 2nd login, event 2 (E2)_id2
— ID of E2_index2
— index of E2srcip2
— source IP address of E2srcip_geo2
— source IP address geo location of E2, including latitude and longitudeengid_gateway
— gateway IP address, used to determine geo location when source IP address is private
Use Case with Data Points
Login events (E1 and E2) are examined for a user (srcip_usersid
), to see if the login locations (srcip_geo
and srcip_geo2
), that are at least 100 miles apart, changed faster (travel_speed
= distance_deviation
/time_deviation
) than possible with the typical commercial flight speed of 600 miles/hour.
E1 is the basis for the Interflow. The srcip_usersid
and srcip_username
identify the user, appid_name
identifies the application, and last_login_time
identifies the time when the 2nd login event happened. You can find detailed information about E2 by checking id2
in index2
, source IP (srcip2
), and geo location (srcip_geo2
).
Internal Account Login Failure Anomaly
An anomalously large number of login failures from an internal source IP address to an internal destination IP address was observed for an account. Check with the user.
This alert type has 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 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
)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 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
).
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 isinternal_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 isinternal_cloud_account_login_failure_kerberos
.
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 isinternal_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 isinternal_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
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 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 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 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 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.
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 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_user_login_fail
.
Severity
60
Key Fields and Relevant Data Points
srcip
— source IP addressservice_id
— source domain, workstation, organization, or servicedstip
— 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
)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 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
).
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 isinternal_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 isinternal_user_login_fail_dstip
.
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 isinternal_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 isinternal_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 isinternal_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
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.
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. Ifengid_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 useror
event_data.TargetUserName
— name of the user (Windows event)-
The key field for this alert type can be either
srcip_usersid
orevent_data.TargetUserName
, depending on the data feed. srcip_username
— source user namesrcip_host
— host name of corresponding source IP addresssrcip_geo.countryName
— source countryactual_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
).
Potentially Malicious AWS Activity
The Potentially Malicious AWS Activity rules are used to identify suspicious activity within AWS logs. Any one or more of these will trigger the Potentially Malicious AWS Activity alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_malicious_activity
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Potentially Malicious AWS Activity Alert Type
Suspicious AWS Bucket Enumeration
The Suspicious AWS Bucket Enumeration rules are used to identify suspicious activity related to AWS Bucket enumeration. Any one or more of these will trigger the AWS Bucket Enumeration alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_bucket_enumeration
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS Bucket Enumeration Alert Type
Suspicious AWS EBS Activity
The Suspicious AWS EBS Activity rules are used to identify suspicious AWS Elastic Block Store (EBS) activity. Any one or more of these will trigger the Suspicious AWS EBS Activity alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_ebs_activity
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS EBS Activity Alert Type
Suspicious AWS EC2 Activity
The Suspicious AWS EC2 Activity rules are used to identify suspicious activity within AWS EC2 logs. Any one or more of these will trigger the Suspicious AWS EC2 Activity alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_ec2_activity
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS EC2 Activity Alert Type
Suspicious AWS ELB Activity
The Suspicious AWS ELB Activity rules are used to identify suspicious activity with AWS ELB. Any one or more of these will trigger the Suspicious AWS ELB Activity alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_elb_activity
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS ELB Activity Alert Type
Suspicious AWS IAM Activity
The Suspicious AWS IAM Activity rules are used to identify suspicious activity within AWS IAM logs. Any one or more of these will trigger the Suspicious AWS IAM Activity alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_iam_activity
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS IAM Activity Alert Type
Suspicious AWS RDS Event
The Suspicious AWS RDS Event rules are used to identify suspicious activity related to AWS RDS events. Any one or more of these will trigger the Suspicious AWS RDS Event alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_rds_event
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS RDS Event Alert Type
Suspicious AWS Root Account Activity
The Suspicious AWS Root Account Activity rules are used to identify suspicious activity with AWS Root Account. Any one or more of these will trigger the Suspicious AWS Root Account Activity alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_root_account_activity
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS Root Account Activity Alert Type
Suspicious AWS Route 53 Activity
The Suspicious AWS Route 53 Activity rules are used to identify suspicious activity within AWS Route 53 logs. Any one or more of these will trigger the Suspicious AWS Route 53 Activity alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_route53_activity
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS Route 53 Activity Alert Type
Suspicious AWS SSL Certificate Activity
The Suspicious AWS SSL Certificate Activity rules are used to identify suspicious activity with AWS SSL certificates. Any one or more of these will trigger the Suspicious AWS SSL Certificate alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_ssl_certificate_activity
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS SSL Certificate Activity Alert Type
Suspicious AWS VPC Flow Logs Modification
The Suspicious AWS VPC Flow Logs Modification rules are used to identify suspicious modification of AWS VPC Flow logs. Any one or more of these will trigger the Suspicious AWS VPC Flow Logs Modification alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_vpc_flow_logs_modification
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS VPC Flow Logs Modification Alert Type
Suspicious AWS VPC Mirror Session
The Suspicious AWS VPC Mirror Session rules are used to identify suspicious AWS VPC mirror session activity. Any one or more of these will trigger the Suspicious AWS VPC Mirror Session alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_vpc_mirror_session
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious AWS VPC Mirror Session Alert Type
Suspicious Modification of AWS CloudTrail Logs
The Suspicious Modification of AWS CloudTrail Logs rules are used to identify suspicious activity within AWS Cloudtrail logs. Any one or more of these will trigger the Suspicious Modification of AWS CloudTrail Logs alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_cloudtrail_logs_modification
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious Modification of AWS CloudTrail Logs Alert Type
Suspicious Modification of AWS Route Table
The Suspicious Modification of AWS Route Table rules are used to identify suspicious activity related to modification of AWS route table. Any one or more of these will trigger the Suspicious Modification of AWS Route Table alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_modification_of_route_table
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious Modification of AWS Route Table Alert Type
Suspicious Modification of S3 Bucket
The Suspicious Modification of S3 Bucket rules are used to identify suspicious activity within S3 Bucket logs. Any one or more of these will trigger the Suspicious Modification of S3 Bucket alert type.
Event Name
The xdr_event.name
for this alert type in the Interflow data is aws_suspicious_modification_of_s3_bucket
.
Key Fields and Relevant Data Points
eventSource
— source of eventeventName
— name of eventeventType
— type of eventuserIdentity.accountId
— key ID for the account involved in the eventuserIdentity.userName
— user name of the account involved in the eventuserIdentity.type
— type of account involved in the eventstellar.rule_id
— Stellar Cyber rule ID
Link to Rule-Based Alert Types
Rules Contributing to Suspicious Modification of S3 Bucket 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 userdistance_deviation
— deviation in distance between two login locations (miles)srcip_host
— host name of corresponding source IP addresssrcip_reputation
— source reputationsrcip_geo.countryName
— source country namesrcip_geo.region
— source region namesrcip_geo.city
— source city namedstip_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.