Successful SSH Authentication from Unusual User

 1[metadata]
 2creation_date = "2025/02/21"
 3integration = ["system"]
 4maturity = "production"
 5updated_date = "2025/04/07"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10This rule leverages the new_terms rule type to detect successful SSH authentications by a user
11who has not been authenticated in the last 10 days. This behavior may indicate an attacker
12attempting to gain access to the system using a valid account.
13"""
14false_positives = [
15    """
16    This rule may trigger in cases where a user has routine work patterns that result in infrequent authentications.
17    """,
18]
19from = "now-9m"
20index = ["logs-system.auth-*", "filebeat-*"]
21language = "kuery"
22license = "Elastic License v2"
23name = "Successful SSH Authentication from Unusual User"
24note = """ ## Triage and analysis
25
26> **Disclaimer**:
27> 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.
28
29### Investigating Successful SSH Authentication from Unusual User
30
31SSH (Secure Shell) is a protocol used to securely access and manage Linux systems. Adversaries may exploit valid user accounts to gain unauthorized access, bypassing traditional security measures. The detection rule identifies unusual SSH logins by flagging users who haven't logged in for over 10 days, indicating potential misuse of credentials. This proactive approach helps in early detection of unauthorized access attempts.
32
33### Possible investigation steps
34
35- Review the specific user account involved in the alert to determine if the login is expected or authorized, considering the user's typical login patterns and responsibilities.
36- Check the source IP address of the SSH login to see if it is recognized or associated with previous legitimate access, or if it appears unusual or suspicious.
37- Analyze the timing of the login event to see if it coincides with any known maintenance windows or scheduled activities that could explain the access.
38- Investigate any recent changes to the user's account, such as password resets or modifications to permissions, that could indicate potential compromise.
39- Correlate the SSH login event with other logs or alerts from the same timeframe to identify any additional suspicious activities or patterns that could suggest a broader security incident.
40
41### False positive analysis
42
43- Users returning from extended leave or vacation may trigger the rule. To manage this, create exceptions for users with known absence periods.
44- System administrators or service accounts that log in infrequently for maintenance tasks can be excluded by identifying and documenting these accounts.
45- Automated scripts or processes that authenticate sporadically might be flagged. Review and whitelist these processes if they are legitimate and necessary for operations.
46- Temporary contractors or consultants with limited access periods may cause alerts. Ensure their access is documented and create exceptions for their accounts during their engagement period.
47- Accounts used for testing or development purposes that are not regularly active can be excluded by maintaining a list of such accounts and updating it as needed.
48
49### Response and remediation
50
51- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
52- Terminate the active SSH session associated with the unusual login to cut off the attacker's access.
53- Reset the password for the compromised user account and any other accounts that may have been accessed using the same credentials.
54- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional compromised accounts.
55- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been affected.
56- Implement multi-factor authentication (MFA) for SSH access to enhance security and prevent similar unauthorized access attempts in the future.
57- Update and enhance monitoring rules to detect similar unusual login patterns, ensuring early detection of potential threats.
58"""
59risk_score = 21
60rule_id = "5b8d7b94-23c6-4e3f-baed-3a4d0da4f19d"
61severity = "low"
62tags = [
63    "Domain: Endpoint",
64    "OS: Linux",
65    "Use Case: Threat Detection",
66    "Tactic: Initial Access",
67    "Data Source: Elastic Defend",
68    "Resources: Investigation Guide",
69]
70timestamp_override = "event.ingested"
71type = "new_terms"
72query = '''
73event.category:authentication and host.os.type:linux and event.action:ssh_login and event.outcome:success
74'''
75
76[[rule.threat]]
77framework = "MITRE ATT&CK"
78
79[rule.threat.tactic]
80id = "TA0001"
81name = "Initial Access"
82reference = "https://attack.mitre.org/tactics/TA0001/"
83
84[[rule.threat.technique]]
85id = "T1078"
86name = "Valid Accounts"
87reference = "https://attack.mitre.org/techniques/T1078/"
88
89[rule.new_terms]
90field = "new_terms_fields"
91value = ["related.user"]
92
93[[rule.new_terms.history_window_start]]
94field = "history_window_start"
95value = "now-10d"