OpenSSL Password Hash Generation

This rule detects the usage of the openssl binary to generate password hashes on Linux systems. The openssl command is a cryptographic utility that can be used to generate password hashes. Attackers may use openssl to generate password hashes for new user accounts or to change the password of existing accounts, which can be leveraged to maintain persistence on a Linux system.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/01/16"
  3integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_version = "8.13.0"
  6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  7updated_date = "2025/01/22"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the usage of the `openssl` binary to generate password hashes on Linux systems. The `openssl` command is a
 13cryptographic utility that can be used to generate password hashes. Attackers may use `openssl` to generate password hashes
 14for new user accounts or to change the password of existing accounts, which can be leveraged to maintain persistence
 15on a Linux system.
 16"""
 17from = "now-9m"
 18index = ["logs-endpoint.events.process*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
 19language = "eql"
 20license = "Elastic License v2"
 21name = "OpenSSL Password Hash Generation"
 22risk_score = 21
 23rule_id = "f4b857b3-faef-430d-b420-90be48647f00"
 24setup = """## Setup
 25
 26This rule requires data coming in from Elastic Defend.
 27
 28### Elastic Defend Integration Setup
 29Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 30
 31#### Prerequisite Requirements:
 32- Fleet is required for Elastic Defend.
 33- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 34
 35#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 36- Go to the Kibana home page and click "Add integrations".
 37- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 38- Click "Add Elastic Defend".
 39- Configure the integration name and optionally add a description.
 40- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 41- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
 42- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 43- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
 44For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 45- Click "Save and Continue".
 46- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
 47For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 48"""
 49severity = "low"
 50tags = [
 51    "Domain: Endpoint",
 52    "OS: Linux",
 53    "Use Case: Threat Detection",
 54    "Tactic: Persistence",
 55    "Data Source: Elastic Endgame",
 56    "Data Source: Elastic Defend",
 57    "Data Source: Auditd Manager",
 58    "Data Source: Crowdstrike",
 59    "Data Source: SentinelOne",
 60    "Resources: Investigation Guide",
 61]
 62timestamp_override = "event.ingested"
 63type = "eql"
 64query = '''
 65process where host.os.type == "linux" and event.type == "start" and
 66event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and process.name == "openssl"
 67and process.args == "passwd"
 68'''
 69note = """## Triage and analysis
 70
 71> **Disclaimer**:
 72> 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.
 73
 74### Investigating OpenSSL Password Hash Generation
 75
 76OpenSSL is a robust cryptographic toolkit used for secure communications and data protection, including generating password hashes. Adversaries may exploit OpenSSL to create hashes for unauthorized user accounts or modify existing ones, aiding in persistent access to Linux systems. The detection rule identifies suspicious OpenSSL executions by monitoring specific process actions and arguments, flagging potential misuse for further investigation.
 77
 78### Possible investigation steps
 79
 80- Review the process execution details to confirm the presence of the "openssl" command with the "passwd" argument, as this indicates an attempt to generate a password hash.
 81- Identify the user account associated with the process execution to determine if the action was performed by a legitimate user or a potential adversary.
 82- Check the system logs and user activity around the time of the alert to identify any suspicious behavior or unauthorized access attempts.
 83- Investigate any recent changes to user accounts on the system, focusing on new account creations or password modifications that coincide with the alert.
 84- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise.
 85- Assess the risk and impact of the detected activity by considering the context of the system and its role within the organization, as well as any potential data exposure or system access implications.
 86
 87### False positive analysis
 88
 89- Routine administrative tasks may trigger the rule when system administrators use OpenSSL to generate password hashes for legitimate user account management. To handle this, create exceptions for specific administrator accounts or processes that are known to perform these tasks regularly.
 90- Automated scripts for user account provisioning or maintenance that utilize OpenSSL for password hashing can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule.
 91- Security tools or compliance checks that periodically verify password strength or integrity using OpenSSL might be flagged. Review these tools and whitelist their operations to prevent unnecessary alerts.
 92- Development environments where OpenSSL is used for testing password hashing functions can generate alerts. Exclude these environments or specific test accounts from monitoring to reduce noise.
 93- Scheduled tasks or cron jobs that involve OpenSSL for password management purposes should be identified and excluded if they are part of regular system operations.
 94
 95### Response and remediation
 96
 97- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
 98- Terminate any suspicious OpenSSL processes identified by the detection rule to halt ongoing unauthorized password hash generation.
 99- Conduct a thorough review of user accounts on the affected system to identify any unauthorized accounts or changes to existing accounts, and revert any unauthorized modifications.
100- Change passwords for all user accounts on the affected system, especially those with elevated privileges, to ensure that any compromised credentials are no longer valid.
101- Implement additional monitoring on the affected system to detect any further unauthorized use of OpenSSL or similar tools, focusing on process execution and command-line arguments.
102- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, and to assess potential impacts on other systems.
103- Review and update access controls and authentication mechanisms to enhance security and prevent similar incidents in the future, ensuring that only authorized users can perform sensitive operations."""
104
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107
108[[rule.threat.technique]]
109id = "T1136"
110name = "Create Account"
111reference = "https://attack.mitre.org/techniques/T1136/"
112
113[[rule.threat.technique.subtechnique]]
114id = "T1136.001"
115name = "Local Account"
116reference = "https://attack.mitre.org/techniques/T1136/001/"
117
118[rule.threat.tactic]
119id = "TA0003"
120name = "Persistence"
121reference = "https://attack.mitre.org/tactics/TA0003/"

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 OpenSSL Password Hash Generation

OpenSSL is a robust cryptographic toolkit used for secure communications and data protection, including generating password hashes. Adversaries may exploit OpenSSL to create hashes for unauthorized user accounts or modify existing ones, aiding in persistent access to Linux systems. The detection rule identifies suspicious OpenSSL executions by monitoring specific process actions and arguments, flagging potential misuse for further investigation.

Possible investigation steps

  • Review the process execution details to confirm the presence of the "openssl" command with the "passwd" argument, as this indicates an attempt to generate a password hash.
  • Identify the user account associated with the process execution to determine if the action was performed by a legitimate user or a potential adversary.
  • Check the system logs and user activity around the time of the alert to identify any suspicious behavior or unauthorized access attempts.
  • Investigate any recent changes to user accounts on the system, focusing on new account creations or password modifications that coincide with the alert.
  • Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise.
  • Assess the risk and impact of the detected activity by considering the context of the system and its role within the organization, as well as any potential data exposure or system access implications.

False positive analysis

  • Routine administrative tasks may trigger the rule when system administrators use OpenSSL to generate password hashes for legitimate user account management. To handle this, create exceptions for specific administrator accounts or processes that are known to perform these tasks regularly.
  • Automated scripts for user account provisioning or maintenance that utilize OpenSSL for password hashing can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule.
  • Security tools or compliance checks that periodically verify password strength or integrity using OpenSSL might be flagged. Review these tools and whitelist their operations to prevent unnecessary alerts.
  • Development environments where OpenSSL is used for testing password hashing functions can generate alerts. Exclude these environments or specific test accounts from monitoring to reduce noise.
  • Scheduled tasks or cron jobs that involve OpenSSL for password management purposes should be identified and excluded if they are part of regular system operations.

Response and remediation

  • Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
  • Terminate any suspicious OpenSSL processes identified by the detection rule to halt ongoing unauthorized password hash generation.
  • Conduct a thorough review of user accounts on the affected system to identify any unauthorized accounts or changes to existing accounts, and revert any unauthorized modifications.
  • Change passwords for all user accounts on the affected system, especially those with elevated privileges, to ensure that any compromised credentials are no longer valid.
  • Implement additional monitoring on the affected system to detect any further unauthorized use of OpenSSL or similar tools, focusing on process execution and command-line arguments.
  • Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, and to assess potential impacts on other systems.
  • Review and update access controls and authentication mechanisms to enhance security and prevent similar incidents in the future, ensuring that only authorized users can perform sensitive operations.

Related rules

to-top