Multiple Alerts Involving a User
This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2022/11/16"
3maturity = "production"
4updated_date = "2025/01/15"
5
6[rule]
7author = ["Elastic"]
8description = """
9This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts
10can use this to prioritize triage and response, as these users are more likely to be compromised.
11"""
12false_positives = [
13 """
14 False positives can occur with Generic built-in accounts, such as Administrator, admin, etc. if they are widespread
15 used in your environment. As a best practice, they shouldn't be used in day-to-day tasks, as it prevents the ability
16 to quickly identify and contact the account owner to find out if an alert is a planned activity, regular business
17 activity, or an upcoming incident.
18 """,
19]
20from = "now-24h"
21index = [".alerts-security.*"]
22interval = "1h"
23language = "kuery"
24license = "Elastic License v2"
25name = "Multiple Alerts Involving a User"
26risk_score = 73
27rule_id = "0d160033-fab7-4e72-85a3-3a9d80c8bff7"
28severity = "high"
29tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
30timestamp_override = "event.ingested"
31type = "threshold"
32
33query = '''
34signal.rule.name:* and user.name:* and not user.id:("S-1-5-18" or "S-1-5-19" or "S-1-5-20")
35'''
36note = """## Triage and analysis
37
38> **Disclaimer**:
39> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
40
41### Investigating Multiple Alerts Involving a User
42
43In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts.
44
45### Possible investigation steps
46
47- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user.
48- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions.
49- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations.
50- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points.
51- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
52- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks.
53- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised.
54
55### False positive analysis
56
57- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule.
58- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise.
59- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times.
60- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts.
61- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone.
62
63### Response and remediation
64
65- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity.
66- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise.
67- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system.
68- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications.
69- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed.
70- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns.
71- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied."""
72
73
74
75[rule.threshold]
76field = ["user.name"]
77value = 1
78[[rule.threshold.cardinality]]
79field = "signal.rule.rule_id"
80value = 5
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Multiple Alerts Involving a User
In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts.
Possible investigation steps
- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user.
- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions.
- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations.
- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points.
- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts.
- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks.
- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised.
False positive analysis
- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule.
- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise.
- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times.
- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts.
- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone.
Response and remediation
- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity.
- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise.
- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system.
- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications.
- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed.
- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns.
- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied.
Related rules
- GitHub UEBA - Multiple Alerts from a GitHub Account
- Multiple Alerts in Different ATT&CK Tactics on a Single Host
- Potential Buffer Overflow Attack Detected
- Potential Widespread Malware Infection Across Multiple Hosts
- Unusual Discovery Signal Alert with Unusual Process Command Line