Alert Types That Use the Windows Index

The Alert Types listed below use the Windows 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.

Abnormal Parent / Child Process

A process that typically launches a small, consistent number of child processes launched a new child process. Investigate the child process to see if it is benign.

This alert type has two subtype categories:

Alert Subtype: Machine Learning Anomaly Detection

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: XDR EBA (XTA0001)

  • Technique: XDR Process Relationship Anomaly (XT1002)

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • parent_proc_name — name of the parent process  
  • srcip_host — host name of corresponding source IP address
  • process_name — name of the process
  • stability — score measuring the time since the parent process launched the last child process
  • diversity — score measuring the number of child processes that the parent process spawned
  • days_stable — time since the parent process launched the last child process
  • child_count — number of child processes that the parent process spawned

Use Case with Data Points

Each pair of parent/child processes (parent_proc_name and process_name) is examined periodically. If a parent process (parent_proc_name) with a small number of child processes (diversity, child_count) has not launched a new child process (process_name) for a long time (stability, days_stable) launches a new child process from a host (srcip_host), an alert is triggered.

Alert Subtype: Rule Based Detection

The Parent/Child Suspicious Process Creation rules are used to identify suspicious activity with parent/child relationships associated with process creation. Any one or more of these will trigger the Parent/Child Suspicious Process Creation alert types.

Key Fields and Relevant Data Points

  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Parent/Child Suspicious Process Creation Alert Type

Azure AD Apps Modified To Allow Multi-Tenant Access

Azure AD detected an application being modified to allow multi-tenant access. Check with the organization to be sure this was expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Persistence (TA0003 )

  • Technique: Account Manipulation (T1098 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — user ID that modified the property change 
  • activityDisplayName — description of the action
  • targetResources.modifiedProperties.displayName — properties that were changed

Use Case with Data Points

If Azure AD detects any user (srcip_usersid) changing an application to allow multi-tenant access, an alert is triggered. A sample Interflow includes the user ID (srcip_usersid), activity name (activityDisplayName), and name of the changed property (targetResources.modifiedProperties.displayName).

Azure AD Custom Domains Changed

Azure AD detected a custom domain being changed. Check with the organization to be sure this was expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Defense Evasion (TA0005 )

  • Technique: Domain Policy Modification (T1484 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — user account that made the domain change  
  • activityDisplayName — activity display name
  • activity_name — action description

Use Case with Data Points

If Azure AD detects any user (srcip_usersid) changing a custom domain, an alert is triggered. A sample Interflow includes the user ID (srcip_usersid) and activity name (activity_name).

Backup Catalogs Deleted by Ransomware

The wbadmin.exe utility was used to delete the backup catalog. Ransomware and other malware do this to prevent system recovery. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Defense Evasion (TA0005 )

  • Technique: Indicator Removal on Host (T1070 )

  • Tags: [Malware; Ransomware]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — IP address of the host executing the process  
  • process_name — name of the process
  • event_data.CommandLine — command that was executed

Use Case with Data Points

If wbadmin.exe is used to delete the backup catalog, an alert is triggered. The Interflow includes the host IP address (hostip), process name (process_name), and command line (event_data.CommandLine).

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

Command Anomaly

A command has been executed an anomalously large number of times compared to its typical executions or those of other commands. Investigate the command and the user to determine if this is expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Execution (TA0002 )

  • Technique: Command and Scripting Interpreter (T1059 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • command — command executed  
  • actual — actual number of executions in the period
  • typical — typical number of executions in the period
  • cwd — current working directory from which the command executed
  • hostip — host running the agent sensor
  • srcip — source IP address from which the command was run
  • username — user name who ran the command

Use Case with Data Points

The number of times a command (command) has been executed is calculated periodically. If the volume (actual) is much larger than the typical volume (typical) of the command or other commands in any period, an alert is triggered. The Interflow includes the directory from which the command was executed (cwd), the host and source IP addresses (hostip and srcip) from which the command was executed, and the name of the user who ran the command (username).

Encoded PowerShell

A Windows host executed an encoded PowerShell script. Investigate the script contents to see if it is malicious. If so, consider quarantining the host.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Execution (TA0002 )

  • Technique: Command and Scripting Interpreter (T1059 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address  
  • event_data.ContextInfo — PowerShell script context
  • event_data.Payload — PowerShell script payload

Use Case with Data Points

If a Windows host (srcip) executes a PowerShell script whose context (event_data.ContextInfo) includes flags that indicate encoding or obfuscation of the script, an alert is triggered. The Interflow includes the IP address of the Windows host (srcip), the script context (event_data.ContextInfo), and script payload (event_data.Payload).

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

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

External Brute-Forced Successful User Login

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

This alert type has 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).

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

External Credential Stuffing

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

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

External Password Spraying

.An anomalously large number of failed logins with unknown user names was observed on external Windows authentication services. Check the activity after successful logins, and consider blocking the source IP addresses.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Sub-technique: Password Spraying (T1110.003 )

  • Tags: [External]

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address generating a failed login 

    or

  • event_data.Workstation — workstation causing the alert 

    The key field for this alert type can be either srcip or event_data.Workstation, depending on the data feed.

  • event_id — Windows event ID corresponding to the login failure
  • login_type — type of login; the available values vary by event_id
  • actual — actual number of failed logins with unknown user names in a 5-minute period
  • typical — typical number of failed logins with unknown user names in a 5-minute period
  • password_spray_user_summary — list of up to 100 unknown user names associated with the failed logins (the first three are shown in the alert description)

Use Case with Data Points

If a potential password spraying attack is observed, an alert is triggered. The Interflow includes a source (srcip or event_data.Workstation), timestamp, the type of login (login_type), the number of failed logins (actual), the usual number of failed logins (typical), and a sampling of the user names used in the attack (password_spray_user_summary).

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

External RDP BlueKeep

Detects the use of a scanner by zerosum0x0 that discovers targets vulnerable to BlueKeep (CVE-2019-0708). Check the IP address and block if necessary.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [External] Privilege Escalation (TA0004 )

  • Technique: Exploitation for Privilege Escalation (T1068 )

  • Tags: [External; RDP]

Event Name

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

Key Fields and Relevant Data Points

  • ids.signature — IDS signature  
  • srcip_host — source host name 
  • dstip_host — destination host name 

Use Case with Data Points

If the scanner by zerosum0x0 is used, an alert is triggered. A sample Interflow includes the IDS signature (ids.signature), source host (srcip_host), and destination host (dstip_host).

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

External RDP Suspicious Outbound

Non-standard tools connecting to TCP port 3389 were detected. This could indicate lateral movement attempting to establish an RDP connection. Check the IP address and block if necessary.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] XDR NBA (XTA0002)

  • Technique: XDR App Anomaly (XT2003)

  • Tags: [External; RDP]

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address of the host that connects to TCP port 3389 with a non-standard tool 
  • srcip_host — source host name
  • process_name — process name

Use Case with Data Points

Connections to TCP port 3389 are monitored, and if non-standard tools connect, an alert is triggered. A sample Interflow includes the source IP address (srcip) and the process name (process_name). The following are the standard tools:

  • mstsc.exe
  • RTSApp.exe
  • RTS2App.exe
  • RDCMan.exe
  • ws_TunnelService.exe
  • RSSensor.exe
  • RemoteDesktopManagerFree.exe
  • RemoteDesktopManager.exe
  • RemoteDesktopManager64.exe
  • mRemoteNG.exe
  • mRemote.exe
  • Terminals.exe
  • spiceworks-finder.exe
  • FSDiscovery.exe
  • FSAssessment.exe
  • MobaRTE.exe
  • chrome.exe
  • thor.exe
  • thor64.exe

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

External User Login Failure Anomaly

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

This alert type has a 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).

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

Hydra Password Guessing Hack Tool

A user on a Windows host executed a command-line script that launched either the hydra.exe command or a command using known Hydra style parameters, which may be an inappropriate use of the Hydra password guessing tool.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [Hydra]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — device internal IP address  
  • event_data.Image — process running hydra.exe for password cracking.  
  • event_data.CommandLine — command used to run the tool  
  • computer_name — name of the Windows host

Use Case with Data Points

This alert is triggered if a Windows host (hostip) executes a PowerShell script with a context that includes one or more flags (event_data.Imageor event_data.CommandLine indicating usage of the Hydra password guessing hack tool. The Interflow includes the IP address of the Windows host (hostip), the host name (computer_name), and the script image (event_data.Image) or script payload (event_data.CommandLine).

Validation / Remediation

Check the body of the Powershell script that is reported on the Windows host to identify whether the contents of the script are actually malicious. If malicious, consider quarantining the host.

Potential False Positives

The running of any executable named hydra.exe or a command that has parameters of -u and -p or ^user^ and ^pass^ triggers this alert.

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

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

Internal Brute-Forced Successful User Login

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

This alert type has 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).

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

Internal Password Spraying

An anomalously large number of failed logins with unknown user names was observed on internal Windows authentication services. Check the activity after successful logins, and consider blocking the internal source IP addresses.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Sub-technique: Password Spraying (T1110.003 )

  • Tags: [Internal]

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address generating a failed login 

    or

  • event_data.Workstation — workstation generating a failed login 

    The key field for this alert type can be either srcip or event_data.Workstation, depending on the data feed.

  • event_data.WorkstationName — workstation associated with the alerting srcip (when applicable)
  • event_id — Windows event ID corresponding to the login failures
  • login_type — type of login; the available values vary by event_id
  • actual — actual number of failed logins with unknown user names in a 5-minute period
  • typical — typical number of failed logins with unknown user names in a 5-minute period
  • password_spray_user_summary — list of up to 100 unknown user names associated with the failed logins (the first three are shown in the alert description)

Use Case with Data Points

If a potential password spraying attack is observed, an alert is triggered. The Interflow includes a source (srcip or event_data.Workstation), timestamp, the type of login (login_type), the number of failed logins (actual), the usual number of failed logins (typical), and a sampling of the user names used in the attack (password_spray_user_summary).

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

Internal Credential Stuffing

An anomalously large amount of username/password testing was detected on an internal Windows authentication service. Check the activity after successful logins, and consider blocking the internal source IP addresses.

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

Key Fields and Relevant Data Points

  • msg_class — 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 IP addresses that may have successful breach activities

Use Case with Data Points

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

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

Internal RDP BlueKeep

Detects the use of a scanner by zerosum0x0 that discovers targets vulnerable to BlueKeep (CVE-2019-0708) between internal hosts. Check the IP address and block if necessary.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Privilege Escalation (TA0004 )

  • Technique: Exploitation for Privilege Escalation (T1068 )

  • Tags: [Internal; RDP]

Event Name

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

Key Fields and Relevant Data Points

  • ids.signature — IDS signature 
  • srcip_host — source host name 
  • dstip_host — destination host name 

Use Case with Data Points

If the scanner by zerosum0x0 is used, an alert is triggered. A sample Interflow includes the IDS signature (ids.signature), source host (srcip_host), and destination host (dstip_host).

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

Internal RDP Suspicious Outbound

Non-standard tools from an internal host connecting to TCP port 3389 in the other internal host were detected. This could indicate lateral movement attempting to establish an RDP connection. Check the IP address and block if necessary.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Lateral Movement (TA0008)

  • Technique: Remote Services (T1021)

  • Tags: [Internal; RDP]

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address of the host that connects to TCP port 3389 with a non-standard tool 
  • srcip_host — source host name
  • process_name — process name

Use Case with Data Points

Connections to TCP port 3389 are monitored, and if non-standard tools connect, an alert is triggered. A sample Interflow includes the source IP address (srcip) and the process name (process_name). The following are the standard tools:

  • mstsc.exe
  • RTSApp.exe
  • RTS2App.exe
  • RDCMan.exe
  • ws_TunnelService.exe
  • RSSensor.exe
  • RemoteDesktopManagerFree.exe
  • RemoteDesktopManager.exe
  • RemoteDesktopManager64.exe
  • mRemoteNG.exe
  • mRemote.exe
  • Terminals.exe
  • spiceworks-finder.exe
  • FSDiscovery.exe
  • FSAssessment.exe
  • MobaRTE.exe
  • chrome.exe
  • thor.exe
  • thor64.exe

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

Internal User Login Failure Anomaly

An anomalous number of login failures between internal IP addresses was observed for one of the following applications: SSH, SMTP, FTP, RDP, SMB, databases, Active Directory, Office 365, Okta, AWS CloudTrail, Google Workspace, Salesforce, or 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).

...

Stellar Cyber reports both internal and external versions of some alerts, with different analysis and recommended actions for each. Similarly, IDS signatures report the direction of data flow as inbound or outbound. Use the following as a guide for these concepts:

  • Addresses with a srcip_type or dstip_type of private are identified as internal. All other values are identified as external (when applicable; not all alerts have unique analytics for internal/external).
  • Communications between hosts where srcip_type and dstip_type are both private are considered internal communications.
  • When an anomaly is observed on an internal communication, the attack is considered to be internal.
  • Stellar Cyber always sets the srcip in the Interflow record as the initiating IP address of an event. Note that IDS signatures, which are reported with relevant alerts, instead list addresses based on the direction of data flow, not the initiating address. So an INBOUND data flow may show the dstip as the source address and the srcip as the destination address, even though the srcip was the initiator of the request. Use INBOUND and OUTBOUND information in the signature to understand the direction of data flow, together with Stellar Cyber’s Interflow record of srcip and dstip to understand which address initiated the threat event.

Login Time Anomaly

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

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

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

Malware on Disk

Malicious software or a potentially unwanted application found on a device and reported as not cleaned. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] XDR Malware (XTA0006)

  • Technique: XDR Miscellaneous Malware (XT6001)

  • Tags: [Internal; Malware]

Event Name

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

Key Fields and Relevant Data Points

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

Use Case with Data Points

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

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

A sample Interflow includes the computer name (computer_name), malware engine (malware_engine), host IP address (hostip), path to the file (file_path), type of malware (group, for Sophos), and status of the malware (type, for Sophos).

Mimikatz Credential Dump

A potential Mimikatz memory dump was detected. Check the process to determine whether the host is compromised. Consider quarantining the host.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Credential Access (TA0006 )

  • Technique: OS Credential Dumping (T1003 )

  • Tags: [Internal]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address 
  • hostip_host — host name
  • access_subject — process attempting access  

  • access_mask — mask that the process used to get access privileges (different access masks indicate different capabilities of the suspicious process)

Use Case with Data Points

If a process (access_subject) on a Windows host (srcip) tries to access lsass.exe with a special access mask (access_mask), an alert is triggered. The Interflow includes the IP address of the Windows host (srcip), the process performing mimikatz activity (access_subject), and the access mask used to acquire access privilege (access_mask).

Mimikatz DCSync

An attempt to replicate Active Directory for the first time on a domain controller, or the first time by that account, has occurred. Evaluate whether the replication is intended and, if not, consider disabling the account involved in the replication and investigate for further signs of compromise.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Credential Access (TA0006 )

  • Technique: OS Credential Dumping (T1003 )

  • Tags: [Internal, Active Directory]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — IP address of the targeted domain controller  
  • event_data.SubjectUserSid — source user ID associated with the account attempting replication  
  • hostip_host — host name of the targeted domain controller
  • event_data.SubjectUserName — name of the account that attempted the Active Directory replication
  • event_data.SubjectDomainName — domain of the account that attempted the Active Directory replication

Use Case with Data Points

This alert is triggered when replication of an Active Directory domain controller (hostip) occurs for the first time or is attempted by a user account or computer account (event_data.SubjectUserName) that has rarely occurred (days_silent) or never initiated replication on that DC before. The Interflow includes the IP address of the targeted domain controller (hostip), the account (event_data.SubjectUserName) attempting the replication and its domain (event_data.SubjectDomainName), and the replication operation attempted (event_data.Properties). (For guidance understanding the GUID in the event_data.Properties field, refer to Microsoft Documentation.)

Validation / Remediation

To triage an alert of this type, consider first verifying whether the Active Directory replication event was expected. If the replication is not intended, then the alert has indicated that a DCSync attack is highly likely. This attack can be very severe, because all password hashes stored on the targeted domain controller might have been dumped. Disable the account involved in the replication as soon as possible and further investigate the account for any signs of compromise.

There is no simple remediation for a confirmed DCSync attack. Evaluate the overall risks of credential leakage and apply appropriate corrective actions, including minimizing accounts with permissions to perform Active Directory replication, and forcing a change of credentials for accounts with weak passwords.

Potential False Positives

The following will trigger an alert:

  • Set up of a new  DC

  • Replication of a DC for the first time

Office 365 Access Governance Anomaly

This alert type is deprecated as of the 4.3.7 release. It is replaced by Microsoft 365 alert integration. See Microsoft 365: Valid Accounts (Privilege Escalation) and Microsoft 365: Account Manipulation.

Office 365 generated an access governance alert, which might indicate a change in Exchange admin privileges. Check with the user to make sure this was expected.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: Privilege Escalation (TA0004 )

  • Technique: Valid Accounts (T1078 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account  
  • Name — alert type description
  • Source — source that generated the alert seen by Stellar Cyber
  • srcip — source IP address

Use Case with Data Points

For each Office 365 account (srcip_usersid), access governance alerts detected by Office 365 are checked periodically. If Office 365 finds an access governance alert, an alert is triggered. A sample Interflow includes the account ID (srcip_usersid), this alert type description (Name),the alerting source (Source), and source IP address (srcip).

Office 365 Admin Audit Logging Disabled

Office 365 admin audit logging was disabled, make sure this change was expected.

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account  
  • OrganizationName — organization with audit logging

Use Case with Data Points

Office 365 monitors each Office 365 account (srcip_usersid) for admin audit logging status. If admin audit logging is disabled, an alert is triggered. A sample Interflow includes the account ID (srcip_usersid) and organization name (OrganizationName).

Office 365 Blocked User

This alert type is deprecated as of the 4.3.7 release. It is replaced by Microsoft 365 alert integration. See Microsoft 365: Valid Accounts (Initial Access).

The Office 365 Security Compliance Center discovered a user exceeding the sending limits of the service or outbound spam policies and blocked the user from sending email. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [External] XDR UBA (XTA0004)

  • Technique: XDR Suspicious User (XT4008)

  • Tags: [External]

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account 
  • Source — alerting source
  • srcip — source IP address of the account

Use Case with Data Points

Office 365 monitors email sending actions for each Office 365 account (srcip_usersid). If an account exceeds the sending limit, an alert is triggered. A sample Interflow includes the account ID (srcip_usersid), alerting source (Source), and source IP address (srcip).

Office 365 Content Filter Policy Changed

The Microsoft Exchange content policy was changed. An overly permissive content policy can allow spammers to send your organization unwanted email. Make sure this change was expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Persistence (TA0003 )

  • Technique: Account Manipulation (T1098 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account  
  • OrganizationId — ID of the organization with the Microsoft content policy change 
  • OrganizationName — organization with the Microsoft content policy change

Use Case with Data Points

Office 365 monitors all Office 365 accounts (srcip_usersid) in each organization (OrganizationId) for a Microsoft Exchange content policy change. If a change is detected, an alert is triggered. A sample Interflow includes the Office 365 account ID (srcip_usersid), organization ID (OrganizationId), and organization name (OrganizationName).

Office 365 Data Exfiltration Attempt Anomaly

This alert type is deprecated as of the 4.3.7 release. It is replaced by Microsoft 365 alert integration. See Microsoft 365: Exfiltration Over Web Service.

The Office 365 Security Compliance Center discovered a data exfiltration attempt. Office 365 then blocked, quarantined, encrypted, or applied a hold on the possible exfiltration. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Exfiltration & Impact

  • Tactic: Exfiltration (TA0010 )

  • Technique: Exfiltration Over Web Service (T1567 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account  
  • Name — alert type description
  • Source — reporting source
  • srcip — source IP address

Use Case with Data Points

Office 365 periodically checks each Office 365 account (srcip_usersid) for data exfiltration attempts. If data exfiltration is detected, an alert is triggered. A sample Interflow includes the account ID (srcip_usersid), this alert type description (Name), reporting source (Source), and source IP address (srcip).

Office 365 Data Loss Prevention

This alert type is deprecated as of the 4.3.7 release. It is replaced by Microsoft 365 alert integration. See Microsoft 365: Exfiltration Over Web Service.

The Office 365 Security Compliance Center discovered data loss. Office 365 then blocked, quarantined, encrypted, or applied a hold on the possible exfiltration. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Exfiltration & Impact

  • Tactic: Exfiltration (TA0010 )

  • Technique: Exfiltration Over Web Service (T1567 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account  
  • Name — alert type description
  • Source — reporting source
  • srcip — source IP address

Use Case with Data Points

Office 365 periodically checks each Office 365 account (srcip_usersid) for data loss. If data loss is detected, an alert is triggered. A sample Interflow includes the account ID (srcip_usersid), this alert type description (Name), reporting source (Source), and source IP address (srcip).

Office 365 File Sharing with Outside Entities

An Office 365 account shared multiple files with entities outside of the organization. Check with the user to make sure this was expected.

XDR Kill Chain

  • Kill Chain Stage: Exfiltration & Impact

  • Tactic: Exfiltration (TA0010 )

  • Technique: Transfer Data to Cloud Account (T1537 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account 
  • srcip — source IP address of the sharing action
  • srcip_host — source host name
  • srcip_geo.countryName — source country

Use Case with Data Points

Office 365 monitors sharing with outside entities for each Office 365 account (srcip_usersid). If an account shares multiple files with outside entities, an alert is triggered. A sample Interflow includes the user ID (srcip_usersid), source IP address (srcip), and source country (srcip_geo.countryName).

Office 365 Malware Filter Policy Changed

The Microsoft Exchange malware filter policy changed. An overly permissive malware filter policy can allow attackers to send malicious attachments to your organization. Make sure this change was expected.

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account  
  • OrganizationId — ID of the organization with the Microsoft Exchange malware policy change 
  • OrganizationName — organization with the Microsoft Exchange malware policy change

Use Case with Data Points

Office 365 monitors all Office 365 accounts (srcip_usersid) in every organization (OrganizationId) for Microsoft Exchange malware policy changes. If a change is discovered, an alert is triggered. A sample Interflow includes the account ID (srcip_usersid), organization ID (OrganizationId), and organization name (OrganizationName).

Office 365 Multiple Files Restored

Office 365 detected that multiple files were restored in a short period. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Exploration

  • Tactic: Collection (TA0009 )

  • Technique: Data Staged (T1074 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account 
  • EventSource — event source
  • srcip — source IP address that caused the restore
  • srcip_host — source host name

Use Case with Data Points

Office 365 periodically checks file restore records. If multiple file restore records are detected within a short period, an alert is triggered. A sample Interflow includes the Office 365 account ID (srcip_usersid), event source (EventSource), and source IP address (srcip).

Office 365 Multiple Users Deleted

Office 365 detected that multiple users were deleted in a short period. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Exfiltration & Impact

  • Tactic: Impact (TA0040 )

  • Technique: Account Access Removal (T1531 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account 
  • EventSource — event source
  • srcip — source IP address that did the deletion

Use Case with Data Points

Office 365 periodically checks user deletion records. If multiple users were deleted within a short period, an alert is triggered. A sample Interflow includes the Office 365 account ID (srcip_usersid), event source (EventSource), and source IP address (srcip).

Office 365 Network Security Configuration Changed

Office 365 identified a change to your organization's network security configuration, which is uncommon. Make sure this was expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Persistence (TA0003 )

  • Technique: Account Manipulation (T1098 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for ther Office 365 account 
  • OrganizationId — ID of the organization whose security configuration changed 
  • OrganizationName — name of the organization whose security configuration changed

Use Case with Data Points

Office 365 monitors all Office 365 accounts (srcip_usersid) in every organization (OrganizationId) for network security configuration changes. If a change is detected, an alert is triggered. A sample Interflow includes the Office 365 account ID (srcip_usersid), organization ID (OrganizationId), and organization name (OrganizationName).

Office 365 Password Policy Changed

Office 365 identified a change to your organization's password policy, which is uncommon. Make sure this was expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Defense Evasion (TA0005 )

  • Technique: Modify Authentication Process (T1556 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account 
  • OrganizationId — ID of the organization whose password policy changed 
  • OrganizationName — name of the organization whose password policy changed

Use Case with Data Points

Office 365 monitors all Office 365 accounts (srcip_usersid) in every organization (OrganizationId) for sharing policy changes. If a change is detected, an alert is triggered. A sample Interflow includes the account ID (srcip_usersid), organization ID (OrganizationId), and organization name (OrganizationName).

Office 365 Sharing Policy Changed

Office 365 identified a change to your organization's sharing policy, which is uncommon. Make sure this was expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Persistence (TA0003 )

  • Technique: Account Manipulation (T1098 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account 
  • OrganizationId — ID of the organization whose sharing policy changed 
  • OrganizationName — name of the organization whose sharing policy changed

Use Case with Data Points

Office 365 monitors all Office 365 accounts (srcip_usersid) in every organization (OrganizationId) for password policy changes. If a change is detected, an alert is triggered. A sample Interflow includes the Office 365 account ID (srcip_usersid), organization ID (OrganizationId), and organization name (OrganizationName).

Office 365 User Network Admin Changed

The Office 365 account’s network admin information was changed. Make sure this change was expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Persistence (TA0003 )

  • Technique: Account Manipulation (T1098 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — key ID for the Office 365 account 
  • OrganizationName — name of the organization

Use Case with Data Points

Office 365 monitors the network admin information for each Office 365 account (srcip_usersid). If changes to the network admin are discovered, an alert is triggered. A sample Interflow includes the account ID (srcip_usersid) and organization name (OrganizationName).

Password Cracking with Hashcat

A user from a Windows host executed a command-line script that launched either the hashcat.exe command or a command using known Hashcat parameters (-a -m 1000 -r). The Hashcat command is known to use a SAM file from the Windows registry along with a password list to crack passwords.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [Hashcat]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — device internal IP address  
  • event_data.Image — process running the hashcat tool  
  • event_data.CommandLine — command used to run the tool  
  • computer_name — name of the Windows host

Use Case with Data Points

This alert is triggered if a Windows host (hostip) executes a PowerShell script with a context that includes one or more flags (event_data.Image or event_data.CommandLine) indicating usage of the Hashcat password cracking tool. The Interflow includes the IP address of the Windows host (hostip), the host name (computer_name), and the script image (event_data.Image) or script payload (event_data.CommandLine).

Validation / Remediation

Check the body of the Powershell script that is reported on the Windows host to identify whether the contents are actually malicious. If malicious, consider quarantining the host.

Potential False Positives

The running of any executable named hashcat.exe or any command that uses the hashcat signature parameter list (-a -m 1000 -r).

Password Spraying Attempts Using Dsacls

A user from a Windows host executed a command-line script to launch a command that by name and parameter list indicates an attempt to abuse dsacls.exe for password spraying.

XDR Kill Chain

  • Kill Chain Stage: Initial Attempts

  • Tactic: [Internal] Defense Evasion (TA0005 )

  • Technique: System Binary Proxy Execution (T1218)

  • Tags: [Password Spray;Dsacls]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — device internal IP address  
  • event_data.Image — process running dsacls for password cracking  
  • event_data.CommandLine — command used to run the tool  
  • event_data.OriginalFileName — actual file name that was executed  
  • computer_name — name of the Windows host

Use Case with Data Points

This alert is triggered if a Windows host (hostip) executes a dsacls.exe with a context that includes one or more flags (event_data.Image, event_data.CommandLine, or event_data.OriginalFileName including /user and /passwd as parameters). This indicates possible usage of Dcacls as a password spraying tool. The Interflow includes the IP address of the Windows host (hostip), the host name (computer_name), and the script image (event_data.Image) or the original file name (event_data.OriginalFileName), and script commandline (event_data.CommandLine).

Validation / Remediation

Check whether the usage was actually malicious. If so, consider quarantining the Windows host.

Potential False Positives

This alert could be triggered even if the use is a legitimate use of dsacls to bind to an LDAP session.

Potentially Malicious Windows Event

The Potentially Malicious Windows Event rules are used to identify suspicious activity with Windows Events. This is a generic rule name. Any one or more of these will trigger the Potentially Malicious Windows Event alert type.

Event Name

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

Key Fields and Relevant Data Points

  • event_id — Windows event ID associated with the activity 
  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Potentially Malicious Event Alert Type

PowerShell Remote Access

A Windows host executed a PowerShell script interacting with a remote host. Investigate the script and the remote host to determine whether the script is malicious. If so, consider quarantining the host.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Execution (TA0002 )

  • Technique: Command and Scripting Interpreter (T1059 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address of the Windows host 
  • remote_ip — IP address of the remote host involved in the script 
  • event_data.ScriptBlockText — contents of the PowerShell script

Use Case with Data Points

If a Windows host (srcip) executes a PowerShell script that includes potential communication (event_data.ScriptBlockText) with a remote host (remote_ip), an alert is triggered. The Interflow includes the IP address of the Windows host (srcip), the script body (event_data.ScriptBlockText), and the remote host IP address (remote_ip).

PowerShell Remote Access

A Windows host executed a PowerShell script interacting with a remote host. Investigate the script and the remote host to determine whether the script is malicious. If so, consider quarantining the host.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Execution (TA0002 )

  • Technique: Command and Scripting Interpreter (T1059 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address of the Windows host 
  • remote_ip — IP address of the remote host involved in the script 
  • event_data.ScriptBlockText — contents of the PowerShell script

Use Case with Data Points

If a Windows host (srcip) executes a PowerShell script that includes potential communication (event_data.ScriptBlockText) with a remote host (remote_ip), an alert is triggered. The Interflow includes the IP address of the Windows host (srcip), the script body (event_data.ScriptBlockText), and the remote host IP address (remote_ip).

Process Anomaly

A process has been launched an anomalously large number of times. Investigate the process and the user to see if this is expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: XDR EBA (XTA0001)

  • Technique: XDR Process Anomaly (XT1001)

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • process_name — name of the process 
  • hostip — host IP address
  • hostip_host — host name
  • actual — actual number of launches in the period
  • typical — typical number of launches in the period
  • process_user — user who launched the process

Use Case with Data Points

The number of times a process (process_name) has been launched is calculated periodically. If the volume (actual) is much larger than the typical volume (typical) of the command or other commands in any period, an alert is triggered. The Interflow includes the name of the user who launched the process (process_user).

RDP Port Opening

Netsh commands to open TCP port 3389 were detected. This could indicate Sarwent malware attempting to establish an RDP connection. Check the IP address and block if necessary.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Defense Evasion (TA0005 )

  • Technique: Impair Defenses (T1562 )

  • Tags: [RDP]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — source IP address that executes the command 
  • event_data.CommandLine — command that was executed
  • process_name — process name

Use Case with Data Points

Commands that open TCP port 3389 are monitored, and if netsh commands are seen, an alert is triggered. A sample Interflow includes the source IP address (hostip) and the command used (event_data.CommandLine).

RDP Registry Modification

Modifications of the property values of fDenyTSConnections and UserAuthentication to enable remote desktop connections were detected. Check the IP address and block if necessary.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Defense Evasion (TA0005 )

  • Technique: Modify Registry (T1112 )

  • Tags: [RDP]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address  
  • event_data.TargetObject — name of the registry key
  • event_data.Details — value of the registry

Use Case with Data Points

The property values of fDenyTSConnections and UserAuthentication are monitored, and if a possible malicious modification of the settings to enable remote desktop connections is observed, an alert is triggered. A sample Interflow includes the source IP address (hostip) and the registry name (event_data.TargetObject).

RDP Reverse Tunnel

An svchost hosting RDP termsvcs communicating with the loopback address on TCP port 3389 was detected. Check the IP address and block if necessary.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Command and Control (TA0011 )

  • Technique: Protocol Tunneling (T1572 )

  • Tags: [RDP]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address  
  • hostip_host — host name
  • event_data.Image — process communicating with the loopback address

Use Case with Data Points

If an svchost hosting RDP termsvcs communicating with the loopback address is found on TCP port 3389, an alert is triggered. A sample Interflow includes the host IP address (hostip) and host name (hostip_host).

RDP Session Hijacking

A suspicious RDP session using tscon.exe or MSTSC shadowing was detected. This could indicate a hijacked RDP session. Check the IP address and block if necessary.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: Lateral Movement (TA0008 )

  • Technique: Remote Service Session Hijacking (T1563 )

  • Tags: [RDP]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address that executes the command 
  • event_data.CommandLine — command executed
  • process_name — process name

Use Case with Data Points

If an RDP session redirect using tscon.exe or MSTSC is detected, an alert is triggered. A sample Interflow includes the host IP address (hostip), name of the process used (process_name), and command used (event_data.CommandLine).

RDP Settings Hijacking

Changes to RDP terminal services settings were detected. Check the IP address and block if necessary.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Defense Evasion (TA0005 )

  • Technique: Modify Registry (T1112 )

  • Tags: [RDP]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — IP of the host that made the setting change  
  • event_data.TargetObject — name of the registry key

  • event_data.EventType — event type on the registry key

  • event_data.Details — value of the registry

Use Case with Data Points

RDP terminal service settings are monitored, and if changes are found to these settings, an alert is triggered. A sample Interflow includes the source IP address (hostip) and the registry name (event_data.TargetObject).

RDP Suspicious Logon

An RDP logon with a local source IP address was detected. This could indicate a tunneled logon. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Command and Control (TA0011 )

  • Technique: Protocol Tunneling (T1572 )

  • Tags: [RDP]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address of the RDP server  
  • event_data.TargetDomainName — domain of the login account
  • event_data.TargetUserName — user name of the login account
  • hostip_host — host name of the RDP server

Use Case with Data Points

Remote desktop logins are monitored, and if a local source IP address is seen, an alert is triggered. A sample Interflow includes the source IP address (hostip) and host name (hostip_host).

RDP Suspicious Logon Attempt

An authenticated user who is not allowed to log on remotely attempted to connect through RDP. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] Credential Access (TA0006 )

  • Technique: Brute Force (T1110 )

  • Tags: [Internal; RDP]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address of the RDP server  
  • event_data.AccountDomain — account domain of the user trying to connect
  • event_data.ClientAddress — IP address of the user trying to connect
  • event_data.AccountName — account name of the user trying to connect
  • hostip_host — host name of the RDP server

Use Case with Data Points

Windows remote desktop logins are monitored, and if a user who is not allowed to remotely log in tries to log in with RDP, an alert is triggered. A sample Interflow includes the source IP address (hostip) and host name (hostip_host).

Sensitive Windows Active Directory Attribute Modification

The Sensitive Windows Active Directory Attribute Modification rules are used to identify suspicious activity with Sensitive Windows Active Directory Attribute Modification. Any one or more of these will trigger the Sensitive Windows Active Directory Attribute Modification alert type.

Event Name

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

Key Fields and Relevant Data Points

  • event_id — Windows event ID associated with the activity 
  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Sensitive Windows Active Directory Attribute Modification Alert Type

Sensitive Windows Network Share File or Folder Accessed

The Sensitive Windows Network Share File or Folder Accessed rules are used to identify suspicious activity with Windows Network Share File or Folder Access. Any one or more of these will trigger the Sensitive Windows Network Share File or Folder Accessed alert type.

Event Name

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

Key Fields and Relevant Data Points

  • event_id — Windows event ID associated with the activity 
  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Sensitive Windows Network Share File or Folder Accessed Alert Type

SMB Impacket Lateralization

The execution of wmiexec, dcomexec, atexec, smbexec or PSExec from the Impacket framework was detected. Check the source host. If malicious, consider blocking the host.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Execution (TA0002 )

  • Technique: Windows Management Instrumentation (T1047 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address  
  • srcip_host — host name of corresponding source IP address
  • event_data.CommandLine — command that was executed
  • event_data.ParentCommandLine — command line of the parent process

Use Case with Data Points

If a Windows host (srcip) executes a command (wmiexec, dcomexec, atexec, smbexec, or PSExec) from the Impacket framework, an alert is triggered. A sample Interflow includes the source IP address (srcip), source host (srcip_host), and the command executed (event_data.CommandLine).

SMB Specific Service Installation

A specific service installation used by the smbexec.py tool was detected. Check the source host. If malicious, consider blocking the host.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: Execution (TA0002 )

  • Technique: System Services (T1569 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address 
  • event_data.ServiceName — name of the service installed 
  • srcip_host — host name of corresponding source IP address

Use Case with Data Points

If a Windows host (srcip) installs a specific service installation that is used by the smbexec.py tool, an alert is triggered. A sample Interflow includes the source IP address (srcip), source host (srcip_host), and the service installed (event_data.ServiceName).

SMB Suspicious Copy

A suspicious copy command from a remote C$ or ADMIN$ share was detected. Check the source host. If malicious, consider blocking the host.

XDR Kill Chain

  • Kill Chain Stage: Exploration

  • Tactic: Collection (TA0009 )

  • Technique: Data from Network Shared Drive (T1039 )

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • srcip — source IP address  
  • srcip_host — host name of corresponding source IP address
  • event_data.CommandLine — copy command used

Use Case with Data Points

If a Windows host (srcip) uses the copy command to copy files from a remote C$ or ADMIN$ share, an alert is triggered. A sample Interflow includes the source IP address (srcip), source host (srcip_host), and the command executed (event_data.CommandLine).

Suspicious Access Attempt to Windows Object

The Suspicious Access Attempt to Windows Object rules are used to identify suspicious activity with Access Attempt to Windows Objects. Any one or more of these will trigger the Suspicious Access Attempt to Windows Object alert type.

Event Name

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

Key Fields and Relevant Data Points

  • event_id — Windows event ID associated with the activity 
  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Access Attempt to Windows Object Alert Type

Suspicious Activity Related to Security-Enabled Group

The Suspicious Activity Related to Security-Enabled Group rules are used to identify suspicious activity related to security-enabled groups. Any one or more of these will trigger the Suspicious Activity Related to Security-Enabled Group alert types.

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address 
  • event_id — Windows event ID associated with the activity 
  • hostip_host — host name
  • event_data.SubjectUserName — subject user name associated with the activity
  • event_data.SubjectUserSid — subject user SID associated with the activity
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Activity Related to Security-Enabled Group Alert Type

Suspicious Connection to Another Process

The Suspicious Connection to Another Process rules are used to identify suspicious activity with Suspicious Connection to Another Process. Any one or more of these will trigger the Suspicious Connection to Another Process alert types.

Event Name

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

Key Fields and Relevant Data Points

  • event_id — Windows event ID associated with the activity 
  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Connection to Another Process Alert Type

Suspicious Handle Request to Sensitive Object

The Suspicious Handle Request to Sensitive Object rules are used to identify suspicious activity with Handle Requests to Sensitive Objects. Any one or more of these will trigger the Suspicious Handle Request to Sensitive Object alert type.

Event Name

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

Key Fields and Relevant Data Points

  • event_id — Windows event ID associated with the activity 
  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Handle Request to Sensitive Object Alert Type

Suspicious Powershell Script

The Suspicious Powershell Script rules are used to identify suspicious activity relating to PowerShell scripts. Any one or more of these will trigger the Suspicious PowerShell Script alert types.

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address 
  • hostip_host — host name
  • wineventlog_user — Windows user who executed the script
  • event_data.ScriptBlockText — Powershell script block text
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Powershell Script Alert Type

Suspicious Process Creation Commandline

The Suspicious Process Creation Commandline rules are used to identify suspicious activity relating to command-line process creation. Any one or more of these will trigger the Suspicious Process Creation Commandline alert types.

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address 
  • event_data.CommandLine — process creation command line 
  • hostip_host — host name
  • wineventlog_user — Windows user who executed the command
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Process Creation Commandline Alert Type

Suspicious Windows Active Directory Operation

The Suspicious Windows Active Directory Operation rules are used to identify suspicious activity with Windows Active Directory Operation. Any one or more of these will trigger the Suspicious Windows Active Directory Operation alert type.

Event Name

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

Key Fields and Relevant Data Points

  • event_id — Windows event ID associated with the activity 
  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Windows Active Directory Operation Alert Type

Suspicious Windows Logon Event

The Suspicious Windows Logon Event rules are used to identify suspicious activity with Windows Logons. Any one or more of these will trigger the Suspicious Windows Logon alert types.

Event Name

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

Key Fields and Relevant Data Points

  • event_id — Windows event ID associated with the activity 
  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Windows Logon Event Alert Type

Suspicious Windows Process Creation

The Suspicious Windows Process Creation rules are used to identify suspicious activity associated with process creation. Any one or more of these will trigger the Suspicious Process Creation alert type.

Event Name

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

Key Fields and Relevant Data Points

  • hostip — host IP address 
  • process_name — process associated with the activity 
  • hostip_host — host name
  • wineventlog_user — Windows user associated with the activity
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Windows Suspicious Process Creation Alert Type

Suspicious Windows Service Installation

The Suspicious Windows Service Installation rules are used to identify suspicious activity with service installation. Any one or more of these will trigger the Suspicious Windows Service Installation alert type.

Event Name

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

Key Fields and Relevant Data Points

  • event_id — Windows event ID associated with the activity 
  • hostip — host IP address 
  • hostip_host — host name
  • stellar.rule_id — Stellar Cyber rule ID

Link to Rule-Based Alert Types

Rules Contributing to Suspicious Windows Service Installation Alert Type

Uncommon Process Anomaly

An asset launched a process that has never been observed by Stellar Cyber (or been seen very rarely). This could indicate a malware attack.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: XDR EBA (XTA0001)

  • Technique: XDR Process Anomaly (XT1001)

  • Tags: []

Event Name

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

Key Fields and Relevant Data Points

  • process_name — name of the process  
  • days_silent — number of days since this process was last seen
  • srcip — source IP address running the process
  • process_user — name of the user running the process

Use Case with Data Points

If a process (process_name) has never been observed by Stellar Cyber or been seen very rarely (days_silent), an alert is triggered. The Interflow includes the user (process_user) and host (srcip) that executed the process.

User Asset Access Anomaly

A user who typically uses a small, consistent number of assets logged in to a new asset. Investigate the asset and user to see if this was expected.

XDR Kill Chain

  • Kill Chain Stage: Propagation

  • Tactic: [Internal] XDR UBA (XTA0004)

  • Technique: XDR Asset Anomaly (XT4004)

  • Tags: [Internal; User Behavior Analytics]

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — source user ID  
  • srcip_host — host name of corresponding source IP address
  • dstip_host — host name of corresponding destination IP address
  • srcip_username — source user name
  • stability — score measuring the time since the last new asset was accessed
  • diversity — score measuring the number of assets that the user accessed
  • days_stable — time since the last new asset was accessed
  • child_count — number of assets that the user accessed

Use Case with Data Points

Users (srcip_usersid and srcip_username) with a small number of assets (diversity, child_count) who also have not used a new asset (srcip_host) for a long time (stability, days_stable) are examined. If a new asset appears on a host (srcip_host) with this user, an alert is triggered.

The user is identified with the scrip_userid and scrip_username fields. The asset is identified with the scrip_host field. Active Directory, which is identified from the dstip_host field, provides the relationship between the user and the asset. Stability is identified with the stability field and diversity is identified with the diversity field.

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.

User Process Usage Anomaly

A user who typically executes a small, consistent number of processes suddenly executed a new process. Investigate the process, to see if it is benign. Check with the user to see if this process was expected.

XDR Kill Chain

  • Kill Chain Stage: Persistent Foothold

  • Tactic: XDR EBA (XTA0001)

  • Technique: XDR Process Anomaly (XT1001)

  • Tags: [User Behavior Analytics]

Event Name

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

Key Fields and Relevant Data Points

  • srcip_usersid — non-Windows source user ID  

    or

  • user.identifier — Windows source user ID  

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

  • process_name — name of the process  
  • srcip_host — host name of corresponding source IP address
  • dstip_host — host name of corresponding destination IP address
  • srcip_username — source user name
  • stability — score measuring the time since the last new process was executed
  • diversity — score measuring the number of processes that the user executed
  • days_stable — time since the last new process was executed
  • child_count — number of processes that the user executed

Use Case with Data Points

Looks for a user (srcip_usersid or user.identifier and a srcip_username) with a small number of processes (diversity, child_count) who also has not used a new process for a long time (stability, days_stable). If a new process (process_name) appears on a host (srcip_host) with this user and connects to another host (dstip_host), an alert is triggered.

The user is identified with the scrip_userid or user.identifier and scrip_username fields. The process is identified with the process_name field. The host on which the user is running the process is identified with the srcip_host field. The destination of the traffic generated by the process is identified with the dstip_host field. Stability is identified with the stability field, and diversity is identified with the diversity field.

Volume Shadow Copy Deletion via WMIC

The wmic.exe utility was used to delete the Shadow Copy on an endpoint. Ransomware and other malware do this to prevent system recovery. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Exfiltration & Impact

  • Tactic: Impact (TA0040 )

  • Technique: Inhibit System Recovery (T1490 )

  • Tags: [Malware; Ransomware]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — IP address of the host where the Shadow Copy was deleted  
  • process_name — name of the process
  • event_data.CommandLine — command that was executed

Use Case with Data Points

If wmic.exe is used to delete the Shadow Copy on an endpoint, an alert is triggered. The Interflow includes the host IP address (hostip), process name (process_name), and command line (event_data.CommandLine).

Volume Shadow Copy Deletion via VssAdmin

The vssadmin.exe utility was used to delete the Shadow Copy on an endpoint. Ransomware and other malware do this to prevent system recovery. Check with the user.

XDR Kill Chain

  • Kill Chain Stage: Exfiltration & Impact

  • Tactic: Impact (TA0040 )

  • Technique: Inhibit System Recovery (T1490 )

  • Tags: [Malware; Ransomware]

Event Name

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

Key Fields and Relevant Data Points

  • hostip — IP address of the host where the Shadow Copy was deleted  
  • process_name — name of the process
  • event_data.CommandLine — command that was executed

Use Case with Data Points

If vssadmin.exe is used to delete the Shadow Copy on an endpoint, an alert is triggered. The Interflow ibncludes the host IP address (hostip), process name (process_name), and command line (event_data.CommandLine).