External Alerts

Elastic Stack Serverless Security

Generates a detection alert for each external alert written to the configured indices. Enabling this rule allows you to immediately begin investigating external alerts in the app.

Rule type: query

Rule indices:

• apm--transaction
• traces-apm*
• auditbeat-*
• filebeat-*
• logs-*
• packetbeat-*
• winlogbeat-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: None (https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html#date-math[Date Math format], see also Additional look-back time)

Maximum alerts per execution: 10000

References: None

Tags:

• OS: Windows
• Data Source: APM
• OS: macOS
• OS: Linux
• Resources: Investigation Guide

Version: 104

Rule authors:

• Elastic

Rule license: Elastic License v2

Triage and analysis

[TBC: QUOTE]
Investigating External Alerts

External alerts are crucial for identifying potential threats across diverse environments like Windows, macOS, and Linux. These alerts are generated from various sources, excluding specific modules like endpoint or cloud defend, to focus on broader threat landscapes. Adversaries may exploit vulnerabilities in these systems to execute unauthorized actions. The External Alerts detection rule filters and highlights such activities by focusing on alert events, enabling analysts to swiftly investigate and mitigate risks.

Possible investigation steps

• Review the alert details to identify the specific event.kind:alert that triggered the detection, ensuring it is not associated with the excluded modules (endgame, endpoint, or cloud_defend).
• Examine the source and context of the alert by checking the associated tags, such as OS: Windows, OS: macOS, or OS: Linux, to understand the environment affected.
• Gather additional context by correlating the alert with other logs or events from the same time frame or system to identify any related suspicious activities.
• Assess the risk score and severity level to prioritize the investigation and determine the potential impact on the organization.
• Investigate the origin of the alert by identifying the source IP, user account, or process involved, and check for any known vulnerabilities or exploits associated with them.
• Consult threat intelligence sources to determine if the alert corresponds to any known threat actors or campaigns targeting similar environments.

False positive analysis

• Alerts from benign third-party applications may trigger false positives. Review and identify these applications, then create exceptions to exclude them from future alerts.
• Routine system updates or patches can generate alerts. Monitor update schedules and create exceptions for known update activities to reduce noise.
• Network monitoring tools might produce alerts due to their scanning activities. Verify these tools and exclude their activities if deemed non-threatening.
• Alerts from internal security testing or penetration testing exercises can be mistaken for threats. Coordinate with security teams to whitelist these activities during scheduled tests.
• Certain administrative scripts or automation tasks may trigger alerts. Evaluate these scripts and exclude them if they are part of regular operations and pose no risk.

Response and remediation

• Isolate affected systems immediately to prevent further unauthorized actions and contain the threat.
• Conduct a thorough review of the alert details to identify any specific vulnerabilities or exploits used by the adversary.
• Apply relevant patches or updates to the affected systems to remediate any identified vulnerabilities.
• Restore systems from a known good backup if unauthorized changes or actions have been detected.
• Monitor network traffic and system logs closely for any signs of further suspicious activity or attempts to exploit similar vulnerabilities.
• Escalate the incident to the appropriate security team or management if the threat appears to be part of a larger attack campaign or if additional resources are needed for remediation.
• Enhance detection capabilities by updating security tools and configurations to better identify similar threats in the future.

Setup

This rule is configured to generate more Max alerts per run than the default 1000 alerts per run set for all rules. This is to ensure that it captures as many alerts as possible.

IMPORTANT: The rule’s Max alerts per run setting can be superseded by the xpack.alerting.rules.run.alerts.max Kibana config setting, which determines the maximum alerts generated by any rule in the Kibana alerting framework. For example, if xpack.alerting.rules.run.alerts.max is set to 1000, this rule will still generate no more than 1000 alerts even if its own Max alerts per run is set higher.

To make sure this rule can generate as many alerts as it’s configured in its own Max alerts per run setting, increase the xpack.alerting.rules.run.alerts.max system setting accordingly.

NOTE: Changing xpack.alerting.rules.run.alerts.max is not possible in Serverless projects.

event.kind:alert and not event.module:(endgame or endpoint or cloud_defend)