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

An anomalously large number of Multi-Factor Authentication (MFA) user login failures was observed for an account. Check with the user.

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.

Key Fields and Relevant Data Points

  • srcip_usersid — cloud account user ID  
  • srcip_username — cloud account user name
  • event_summary.total_failed — number of failed logins in the period
  • event_summary.total_successful — number of successful logins in the period
  • event_summary.total_fail_ratio — percent of failed logins in the period, which is: event_summary.total_failed / (event_summary.total_failed + event_summary.total_successful)
  • accumulated_anomalous_failures — score value of the model indicating the degree of abnormal activity
  • srcip_host — host name of corresponding source IP address
  • login_type — type of login
  • srcip_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).

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.

Key Fields and Relevant Data Points

  • userIdentity.accountId — key ID for the account  
  • userIdentity.userName — AWS account user name
  • userIdentity.type — AWS account type
  • eventName — AWS event name
  • eventSource — AWS event source
  • eventType — 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.

Key Fields and Relevant Data Points

  • userIdentity.accountId — key ID for the account  
  • userIdentity.userName — AWS account user name
  • userIdentity.type — AWS account type
  • eventName — AWS event name
  • eventSource — AWS event source
  • eventType — 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 detected. 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.

Key Fields and Relevant Data Points

  • userIdentity.accountId — key ID for the account  
  • userIdentity.userName — AWS account user name
  • userIdentity.type — AWS account type
  • eventName — AWS event name
  • eventSource — AWS event source
  • eventType — 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 detected from an IP address with a history of malicious activity. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] XDR NBA (XTA0002)

  • Technique: XDR Bad Reputation (XT2010)

  • Tags: [External]

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address  
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — user name

Use Case with Data Points

The login records are checked for every source IP address (srcip). If a source IP address has successful login records and its reputation (srcip_reputation) is bad (except brute-forcer and scanner), an alert is triggered. A sample Interflow includes source IP address (srcip), source host (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), login type (login_type), and user name (username).

External Account Login Failure Anomaly

An anomalously large number of user login failures was observed for an account. Check with the user.

This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [External]

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — cloud account user ID  
  • scrip_username — cloud account user name
  • event_summary.total_failed — number of failed logins in the period
  • event_summary.total_successful — number of successful logins in the period
  • event_summary.total_fail_ratio — percent of failed logins in the period, which is: event_summary.total_failed / (event_summary.total_failed + event_summary.total_successful)
  • accumulated_anomalous_failures — score value of the model indicating the degree of abnormal activity
  • srcip_host — host name of corresponding source IP address
  • login_type — type of login
  • srcip_reputation — source reputation

Use Case with Data Points

Login failures and successes are calculated periodically for every account (srcip_usersid). If the number of failures is significantly larger than the number of successes, an alert is triggered. A sample Interflow includes the login type (login_type), source host (srcip_host), and source reputation (srcip_reputation).

External Brute-Forced Successful User Login

A successful login was observed from an IP address that had previously seen a large number of login failures, or a successful login to a user account was observed from another IP address or IP addresses that had previously seen a large number of login failures to that account. Check with the user.

This alert type has two subtypes:

This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [External]

Event Name

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

Alert Subtype: Source IP-Based

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

Key Fields and Relevant Data Points

  • srcip — source IP address  
  • srcip_usersid — Windows SID associated with the source IP address
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — user name
  • related_alert._id — link to the related External User Login Failure Anomaly

Use Case with Data Points

The login records are checked for every external source IP address (srcip). An alert is triggered if that IP address:

  1. Has so many failed login attempts that it triggered the External User Login Failure Anomaly, and
  2. Had a successful login

A sample Interflow includes the source IP address (srcip), login type (login_type), source host (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), and user name (username).

Alert Subtype: User ID-Based

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

Key Fields and Relevant Data Points

  • srcip_usersid — Windows SID associated with the source IP address 
  • srcip — source IP address
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — user name
  • related_alert._id — link to the related External Account Login Failure Anomaly

Use Case with Data Points

The login records to a user account (srcip_usersid) are checked for every external source IP address (srcip). An alert is triggered if that user account:

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

  2. Had a successful login

A sample Interflow includes the source IP address (srcip), login type (login_type), source host (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), and user name (username).

External Credential Stuffing

An anomalously large amount of username/password testing was detected on AWS, Okta, or Windows. Check the activity after successful logins, and consider blocking the source IP addresses.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [External]

Event Name

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

Key Fields and Relevant Data Points

  • msg_class — name of the service: cloudtrail for AWS, okta for Okta, Microsoft-Windows-Security-Auditing for Windows  
  • service_id — specific account ID of a service  
  • login_failure_rate — rate of login failures per minute in the period
  • unknown_users_rate — rate of unknown user names per minute in the period
  • unknown_users_to_login_failures — ratio of unknown user names to login failures in the period
  • suspicious_ips — suspicious source IP addresses (up to 100)
  • possible_breached_ips — list of malicious IPs that may have successful breach activities

Use Case with Data Points

External credential stuffing is the constant testing of username/password combinations on the AWS, Okta, or Windows authentication functions. Login activity is monitored and if the number of failed logins is larger than normal for that service, an alert is triggered. The Interflow includes the service (msg_class), tenant's account ID on that service (service_id), suspicious source IP address (suspicious_ips), login failure rate (login_failure_rate), unknown user rate (unknown_users_rate), the ratio of unknown users to login failures (unknown_users_to_login_failures), and a list of source IP addresses that might have suspicious activities and should be investigated (possible_breached_ips).

External User Login Failure Anomaly

An anomalous number of login failures was observed for one of the following applications: SSH, SMTP, FTP, RDP, SMB, databases, Active Directory, Office 365, Okta, AWS CloudTrail, or Google Workspace. For Okta, an anomalous number of multi-factor authentication (MFA) failures was observed. Check with the user.

This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [External]

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address  
  • dstip — destination IP address  
  • dstip_host — destination host name
  • event_summary.total_failed — number of failed logins in the period
  • event_summary.total_successful — number of successful logins in the period
  • event_summary.total_fail_ratio — percent of failed logins in the period, which is: event_summary.total_failed / (event_summary.total_failed + event_summary.total_successful)
  • accumulated_anomalous_failures — score value of the model indicating the degree of abnormal activity
  • login_type — type of login, such as ssh_traffic, okta_log, or aws_cloudtrail
  • srcip_host — source host name
  • srcip_reputation — source reputation

Use Case with Data Points

Login failures and successes are calculated periodically for every source (srcip) and destination (dstip) IP address. If the number of failures is significantly larger than the number of successes, an alert is triggered. The Interflow includes the login type (login_type), source host (srcip_host), and source reputation (srcip_reputation).

Impossible Travel Anomaly

A user logged in from locations that are geographically impossible to travel between in the time frame. Check with the user.

This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] XDR UBA (XTA0004)

  • Technique: XDR Location Anomaly (XT2001)

  • Tags: [User Behavior Analytics]

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — source user ID  
  • srcip_username — source user name
  • srcip — source IP address
  • srcip_geo — source IP address geo location, including latitude and longitude
  • distance_deviation — deviation in distance (miles) between the two login locations
  • time_deviation — deviation in time (seconds) between the two login events
  • travel_speed — calculated speed for the user to travel between the two location (miles/hour)
  • appid_name — application name for the login event
  • last_login_time — time of 2nd login, event 2 (E2)
  • _id2 — ID of E2
  • _index2 — index of E2
  • srcip2 — source IP address of E2
  • srcip_geo2 — source IP address geo location of E2, including latitude and longitude
  • engid_gateway — gateway IP address, used to determine geo location when source IP address is private

Use Case with Data Points

Login events (E1 and E2) are examined for a user (srcip_usersid), to see if the login locations (srcip_geo and srcip_geo2), that are at least 100 miles apart, changed faster (travel_speed = distance_deviation/time_deviation) than possible with the typical commercial flight speed of 600 miles/hour.

E1 is the basis for the Interflow. The srcip_usersid and srcip_username identify the user, appid_name identifies the application, and last_login_time identifies the time when the 2nd login event happened. You can find detailed information about E2 by checking id2 in index2, source IP (srcip2), and geo location (srcip_geo2).

Internal Account Login Failure Anomaly

An anomalously large number of login failures from an internal source IP address to an internal destination IP address was observed for an account. Check with the user.

This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [Internal]

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — account user ID  

    or

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

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

  • event_summary.total_failed — number of failed logins in the period
  • event_summary.total_successful — number of successful logins in the period
  • event_summary.total_fail_ratio — percent of failed logins in the period, which is: event_summary.total_failed / (event_summary.total_failed + event_summary.total_successful)
  • accumulated_anomalous_failures — score value of the model indicating the degree of abnormal activity
  • srcip_host — host name of corresponding source IP address
  • login_type — type of login
  • srcip_reputation — source reputation

Use Case with Data Points

Login failures and successes between any internal IP addresses are calculated periodically for every account (srcip_usersid). If the number of failures is significantly larger than the number of successes, an alert is triggered. A sample Interflow includes the login type (login_type), source host (srcip_host), and source reputation (srcip_reputation).

Internal Brute-Forced Successful User Login

A successful login was observed from an IP address that had previously seen a large number of login failures, or a successful login to a user account was observed from another IP address or IP addresses that had previously seen a large number of login failures to that account. Check with the user.

This alert type has two subtypes:

This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [Internal]

Event Name

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

Alert Subtype: Source IP-Based

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

Key Fields and Relevant Data Points

  • srcip — source IP address  
  • srcip_usersid — Windows SID associated with the source IP address
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — user name
  • related_alert._id — link to the related Internal User Login Failure Anomaly

Use Case with Data Points

The login records to an internal IP address (dstip) are checked for every internal source IP address (srcip). An alert is triggered if that IP address:

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

  2. Had a successful login

A sample Interflow includes the source IP address (srcip), login type (login_type), source host name (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), and user name (username).

Alert Subtype: User ID-Based

The user ID-based alert subtype has the same XDR Kill Chain 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 address
  • srcip_usersid — Windows SID associated with the source IP address 
  • srcip_host — source host name
  • srcip_reputation — source reputation
  • source_geo.countryName — source country
  • dstip_host — destination host name
  • login_type — type of login
  • username — user name
  • related_alert._id — link to the related Internal Account Login Failure Anomaly

Use Case with Data Points

The login records to a user account (srcip_usersid) are checked for every internal source IP address (srcip). An alert is triggered if that user account:

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

  2. Had a successful login

A sample Interflow includes the source IP address (srcip), login type (login_type), source host name (srcip_host), source reputation (srcip_reputation), source country (srcip_geo.countryName), and user name (username).

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 Azure AD. Check with the user.

This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [Internal]

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address  
  • dstip — destination IP address  
  • dstip_host — destination host name
  • service_id — source domain, workstation, organization, or service
  • event_summary.total_failed — number of failed logins in the period
  • event_summary.total_successful — number of successful logins in the period
  • event_summary.total_fail_ratio — percent of failed logins in the period, which is: event_summary.total_failed / (event_summary.total_failed + event_summary.total_successful)
  • accumulated_anomalous_failures — score value of the model indicating the degree of abnormal activity
  • login_type — type of login, such as ssh_traffic, okta_log, or aws_cloudtrail
  • srcip_host — source host name
  • srcip_reputation — source reputation

Use Case with Data Points

Login failures and successes between internal IP addresses are calculated periodically for every source (srcip) and destination (dstip) IP address. If the number of failures is significantly larger than the number of successes, an alert is triggered. The Interflow includes the login type (login_type), source host (srcip_host), and source reputation (srcip_reputation).

Login Time Anomaly

A user logged in at an abnormal time. Check with the user.

This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] XDR UBA (XTA0004)

  • Technique: XDR Time Anomaly (XT4005)

  • Tags: [External; User Behavior Analytics]

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — source user ID  
  • srcip_username — source user name
  • srcip_host — host name of corresponding source IP address
  • srcip_geo.countryName — source country
  • dstip_host — host name of corresponding destination IP address
  • actual — actual login time
  • typical — typical login time
  • actual_range — actual login time range
  • typical_range — typical login time range

Use Case with Data Points

Every user's (srcip_usersid) login time (actual) is compared to the typical login times (typical_range). If it is outside the range, an alert is triggered. The Interflow includes information such as the source user name (srcip_username), source host name (srcip_host), and source country (srcip_geo.countryName), as well as the destination host (dstip_host).

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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious AWS Bucket Enumeration 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious AWS EC2 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar 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 Event. 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious AWS Route 53 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious AWS VPC Flow Logs Modification 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar 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 event 
  • eventName — name of event 
  • eventType — type of event
  • userIdentity.accountId — key ID for the account involved in the event
  • userIdentity.userName — user name of the account involved in the event
  • userIdentity.type — type of account involved in the event
  • stellar.rule_idStellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Modification of S3 Bucket Alert Type

User Login Location Anomaly

A user logged in from an anomalous location. Check with the user.

This alert type has a relatively long detection delay of up to 40 minutes because it waits for login events from high latency data sources and is sensitive to the event order of user logins.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] XDR UBA (XTA0004)

  • Technique: XDR Location Anomaly (XT2001)

  • Tags: [External; User Behavior Analytics]

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — source user ID  
  • distance_deviation — deviation in distance between two login locations (miles)
  • srcip_host — host name of corresponding source IP address
  • srcip_reputation — source reputation
  • srcip_geo.countryName — source country
  • srcip_geo.region — source region
  • srcip_geo.city — source city
  • dstip_host — host name of corresponding destination IP address
  • login_type — type of login

Use Case with Data Points

Successful login events for certain login types (login_type) of a user (srcip_usersid) from a source host (srcip_host) and country location (srcip_geo.countryName are examined. If the detected login location is too far away (distance_deviation in miles) from that user's typical locations, an alert is triggered. The source host's reputation (srcip_reputation) is also checked. Map views of the Interflow include data points for the closest typical login locations for the user.