AN1295: Analytic 1295
Detection of binaries spawning encrypted sessions using OpenSSL or curl to external services with mismatched ports/protocols. Identifies behavior where internal services simulate trusted cloud service traffic patterns.
Analyst context for executives and security teams
This analytic is about spotting Linux binaries that create encrypted outbound sessions with OpenSSL or curl to external services where the port and protocol do not line up as expected. For leaders, the practical issue is not the tools themselves—OpenSSL and curl are common—but whether trusted-looking encrypted traffic is being used in a way that bypasses normal review, hides unauthorized communications, or imitates cloud-service patterns.
Executive priority
Prioritize this as a validation question for egress visibility and SOC readiness: can the organization explain which Linux systems are allowed to initiate encrypted external connections, on which ports, and for what business purpose? This matters for incident decision-making because encrypted outbound traffic with mismatched protocol/port behavior can reduce inspection value and complicate containment. It also supports audit and resilience discussions around outbound control, logging coverage, and exception governance.
Technical view
For SOC and detection engineering teams, validate Linux telemetry that can connect process execution to outbound network sessions. The supplied ATT&CK object identifies binaries spawning encrypted sessions using OpenSSL or curl to external services with mismatched ports/protocols, including behavior that simulates trusted cloud service traffic patterns. Because no official detection logic or tactic mapping is provided, teams should treat this as a detection design prompt: correlate process lineage, command execution, destination metadata, port/protocol expectations, and known-approved service patterns rather than alerting on curl or OpenSSL alone.
Likely telemetry
- Linux process execution telemetry, including binary name, command line, parent process, user, and host
- Outbound network connection telemetry from Linux hosts, including destination IP/domain, port, protocol, and timestamp
- Proxy, firewall, or egress gateway logs showing external service destinations and allowed ports
- TLS or encrypted-session metadata where available, such as SNI, certificate metadata, or protocol identification
- Asset and service inventory identifying which Linux systems are expected to contact external cloud or internet services
Detection direction
- Baseline legitimate OpenSSL and curl usage on Linux systems before creating high-severity alerts, because both tools are commonly used for administration, package workflows, scripts, and service checks.
- Look for mismatches between expected protocol and port usage, especially encrypted sessions over unusual or policy-inconsistent ports.
- Correlate process activity with network telemetry so the detection is tied to a specific binary and host, not just a network event.
- Review allowlisted cloud-service patterns carefully; the ATT&CK description notes behavior that simulates trusted cloud service traffic patterns, which can create blind spots if cloud destinations are broadly trusted.
- Tune using asset role and user context: developer systems, automation hosts, and monitoring jobs may generate legitimate curl/OpenSSL traffic, while unexpected use from production servers may deserve faster triage.
Mitigation priorities
- Confirm egress policy and logging coverage for Linux systems, especially systems that should not initiate arbitrary external encrypted sessions.
- Maintain an approved inventory of external services, expected ports, and systems authorized to use them.
- Reduce broad network allowlisting based only on destination reputation or cloud provider ownership; require business justification and review for exceptions.
- Harden and monitor privileged Linux hosts where unexpected outbound encrypted sessions would create higher operational risk.
- Use incident response playbooks that preserve process, command-line, user, and network evidence needed to determine whether the activity was approved administration, automation, or suspicious communication.
Analyst notes and limits
This is a detection analytic object, not a technique description. The most useful defensive takeaway is to validate whether the organization can join Linux process telemetry with outbound encrypted network activity and distinguish approved cloud/service traffic from mismatched or unusual port/protocol behavior.
The supplied ATT&CK fields provide a description, Linux platform, and external reference only. No official detection logic, tactics, related techniques, mitigations, data sources, or relationships were supplied. Local baselines, approved service inventories, and environment-specific network policy are required to turn this into reliable detection coverage.
Analytic 1295
Detection of binaries spawning encrypted sessions using OpenSSL or curl to external services with mismatched ports/protocols. Identifies behavior where internal services simulate trusted cloud service traffic patterns.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | b09a6690ec91… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1295Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.