Openssl Client or Server Activity

This rule identifies when the openssl client or server is used to establish a connection. Attackers may use openssl to establish a secure connection to a remote server or to create a secure server to receive connections. This activity may be used to exfiltrate data or establish a command and control channel.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/07/30"
  3integration = ["endpoint", "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/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule identifies when the openssl client or server is used to establish a connection. Attackers may use openssl to
 13establish a secure connection to a remote server or to create a secure server to receive connections. This activity
 14may be used to exfiltrate data or establish a command and control channel.
 15"""
 16from = "now-9m"
 17index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "Openssl Client or Server Activity"
 21references = ["https://gtfobins.github.io/gtfobins/openssl/"]
 22risk_score = 21
 23rule_id = "ad5a3757-c872-4719-8c72-12d3f08db655"
 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: Execution",
 55    "Data Source: Elastic Defend",
 56    "Data Source: Elastic Endgame",
 57    "Data Source: SentinelOne",
 58    "Resources: Investigation Guide"
 59]
 60timestamp_override = "event.ingested"
 61type = "eql"
 62query = '''
 63process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 64  process.name == "openssl" and (
 65    (process.args == "s_client" and process.args : ("-connect", "*:*") and not process.args == "-showcerts") or
 66    (process.args == "s_server" and process.args == "-port")
 67  ) and
 68  not process.parent.executable in ("/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert")
 69'''
 70note = """## Triage and analysis
 71
 72> **Disclaimer**:
 73> 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.
 74
 75### Investigating Openssl Client or Server Activity
 76
 77OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to encrypt data transmissions. Adversaries may exploit OpenSSL to establish encrypted channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting atypical client-server interactions, while excluding known benign processes.
 78
 79### Possible investigation steps
 80
 81- Review the process execution details to confirm the presence of the "openssl" process with arguments indicating client or server activity, such as "s_client" with "-connect" or "s_server" with "-port".
 82- Check the parent process of the "openssl" execution to determine if it is a known benign process or if it is potentially suspicious, especially if it is not in the excluded list (e.g., "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert").
 83- Investigate the network connections established by the "openssl" process to identify the remote server's IP address and port, and assess whether these are known or potentially malicious.
 84- Analyze the timing and frequency of the "openssl" executions to determine if they align with normal operational patterns or if they suggest unusual or unauthorized activity.
 85- Correlate the "openssl" activity with other security events or logs to identify any related suspicious behavior, such as data exfiltration attempts or command and control communications.
 86
 87### False positive analysis
 88
 89- Known benign processes such as "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" are already excluded to reduce false positives. Ensure these paths are accurate and up-to-date in your environment.
 90- Regularly review and update the list of excluded parent processes to include any additional internal scripts or monitoring tools that frequently use OpenSSL for legitimate purposes.
 91- Monitor for any internal applications or services that may use OpenSSL in a similar manner and consider adding them to the exclusion list if they are verified as non-threatening.
 92- Implement logging and alerting to track the frequency and context of OpenSSL usage, which can help identify patterns that are consistently benign and warrant exclusion.
 93- Engage with system administrators to understand routine OpenSSL usage patterns in your environment, which can inform further refinement of the detection rule to minimize false positives.
 94
 95### Response and remediation
 96
 97- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities.
 98- Terminate the suspicious OpenSSL process identified by the alert to halt any ongoing unauthorized encrypted communications.
 99- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unusual network connections or unauthorized file access.
100- Review and update firewall rules to block unauthorized outbound connections from the affected system, focusing on the ports and IP addresses involved in the suspicious activity.
101- Reset credentials and review access permissions for accounts on the affected system to prevent unauthorized access.
102- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
103- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon."""
104
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107
108[[rule.threat.technique]]
109id = "T1059"
110name = "Command and Scripting Interpreter"
111reference = "https://attack.mitre.org/techniques/T1059/"
112
113[[rule.threat.technique.subtechnique]]
114id = "T1059.004"
115name = "Unix Shell"
116reference = "https://attack.mitre.org/techniques/T1059/004/"
117
118[rule.threat.tactic]
119id = "TA0002"
120name = "Execution"
121reference = "https://attack.mitre.org/tactics/TA0002/"
122
123[[rule.threat]]
124framework = "MITRE ATT&CK"
125
126[[rule.threat.technique]]
127id = "T1071"
128name = "Application Layer Protocol"
129reference = "https://attack.mitre.org/techniques/T1071/"
130
131[rule.threat.tactic]
132id = "TA0011"
133name = "Command and Control"
134reference = "https://attack.mitre.org/tactics/TA0011/"

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 Client or Server Activity

OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to encrypt data transmissions. Adversaries may exploit OpenSSL to establish encrypted channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting atypical client-server interactions, while excluding known benign processes.

Possible investigation steps

  • Review the process execution details to confirm the presence of the "openssl" process with arguments indicating client or server activity, such as "s_client" with "-connect" or "s_server" with "-port".
  • Check the parent process of the "openssl" execution to determine if it is a known benign process or if it is potentially suspicious, especially if it is not in the excluded list (e.g., "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert").
  • Investigate the network connections established by the "openssl" process to identify the remote server's IP address and port, and assess whether these are known or potentially malicious.
  • Analyze the timing and frequency of the "openssl" executions to determine if they align with normal operational patterns or if they suggest unusual or unauthorized activity.
  • Correlate the "openssl" activity with other security events or logs to identify any related suspicious behavior, such as data exfiltration attempts or command and control communications.

False positive analysis

  • Known benign processes such as "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" are already excluded to reduce false positives. Ensure these paths are accurate and up-to-date in your environment.
  • Regularly review and update the list of excluded parent processes to include any additional internal scripts or monitoring tools that frequently use OpenSSL for legitimate purposes.
  • Monitor for any internal applications or services that may use OpenSSL in a similar manner and consider adding them to the exclusion list if they are verified as non-threatening.
  • Implement logging and alerting to track the frequency and context of OpenSSL usage, which can help identify patterns that are consistently benign and warrant exclusion.
  • Engage with system administrators to understand routine OpenSSL usage patterns in your environment, which can inform further refinement of the detection rule to minimize false positives.

Response and remediation

  • Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities.
  • Terminate the suspicious OpenSSL process identified by the alert to halt any ongoing unauthorized encrypted communications.
  • Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unusual network connections or unauthorized file access.
  • Review and update firewall rules to block unauthorized outbound connections from the affected system, focusing on the ports and IP addresses involved in the suspicious activity.
  • Reset credentials and review access permissions for accounts on the affected system to prevent unauthorized access.
  • Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
  • Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon.

References

Related rules

to-top