S0487: Kessel
Analyst context for executives and security teams
Kessel matters because it is described as a custom OpenSSH backdoor for Linux that can steal credentials and act as a bot. For leaders, the practical risk is not just malware on a server; it is compromise of a trusted remote administration path. If SSH or authentication binaries are altered, normal access, logging, and credential trust assumptions may be undermined, which can affect incident scope, privileged access decisions, and recovery confidence.
Executive priority
Prioritize Kessel-relevant readiness where Linux systems depend on SSH for administration or privileged operations. The key business question is whether the organization can prove the integrity of authentication components, detect suspicious SSH-related network behavior, and respond if credentials collected through a modified authentication process must be treated as compromised. This supports resilience, audit evidence, and incident decision-making around credential resets, host rebuilds, and trusted administrative access.
Technical view
ATT&CK lists Kessel for Linux and relates it to discovery, command execution, command-and-control, exfiltration, credential access, persistence, defense impairment, collection, and stealth behaviors. SOC and IR teams should validate Linux coverage for modified host software binaries and authentication processes, especially OpenSSH-related binaries and PAM/authentication paths where applicable. Detection engineering should also examine network evidence for proxying, encoded C2-like content, ingress tool transfer, chunked or C2-channel exfiltration, and unencrypted non-C2 exfiltration. Because MITRE provides no official detection text for this object, local baselining and integrity evidence are essential.
Likely telemetry
- Linux process execution and command-line telemetry for shells, discovery commands, archive utilities, decoding/deobfuscation activity, and file transfer tools
- File integrity and package integrity evidence for OpenSSH, SSH-related binaries, service files, and authentication components
- Authentication logs, SSH service logs, privileged access logs, and evidence of unexpected credential collection or authentication behavior
- Network flow, DNS, proxy, and firewall logs showing outbound C2-like connections, proxy behavior, tool transfer, unusual unencrypted protocols, or size-limited transfers
- Endpoint file creation/modification telemetry for encoded, encrypted, compressed, or archived data prior to transfer
Detection direction
- Validate whether Linux EDR, auditd, syslog, and file integrity monitoring cover SSH and authentication paths with enough fidelity to identify unauthorized binary or configuration changes.
- Tune for combinations rather than single events: modified authentication components plus unusual outbound traffic, encoded data, archive creation, discovery commands, or ingress tool transfer should raise priority.
- Baseline legitimate SSH package versions, hashes, service locations, and administrative maintenance windows to reduce false positives from normal patching or configuration management.
- Review egress monitoring for small or fixed-size transfers, exfiltration over existing C2-like channels, and unencrypted non-C2 protocols, recognizing that threshold-only data-loss rules may miss size-limited transfers.
- Include relationship-driven hunts for T1554, T1556, T1041, T1048.003, T1030, T1090, T1105, T1132.001, T1027.013, T1140, T1059, T1082, T1016, and T1560 where Linux telemetry exists.
Mitigation priorities
- Establish trusted software and package integrity validation for OpenSSH and Linux authentication components before relying on a host during incident response.
- Harden privileged remote administration: restrict SSH exposure, enforce strong access controls, and ensure credential rotation plans account for possible credential theft from authentication-path compromise.
- Improve egress controls and monitoring for Linux servers, including proxy use, unencrypted protocols, tool transfer, encoded content, and unusual transfer sizing.
- Maintain recoverability procedures that rebuild or reimage systems when authentication binaries or processes cannot be trusted, rather than assuming removal of a single artifact is sufficient.
- Use compliance and audit programs to require evidence of Linux logging, file integrity monitoring, privileged access governance, and incident response procedures for compromised authentication infrastructure.
Analyst notes and limits
The most decision-relevant aspect is Kessel’s relationship to OpenSSH and authentication trust. For Glexia-style prioritization, this should be treated as a Linux administrative-access integrity problem as much as a malware problem. The supplied relationships support hunting across persistence, credential access, C2, collection, exfiltration, discovery, and stealth behaviors, but local host roles and SSH exposure determine materiality.
MITRE provides no official detection guidance for Kessel in the supplied object, and the object lists only Linux as the platform. The description cites activity beginning when a C2 domain began resolving in August 2018, but no current activity, victim exposure, attribution, or guaranteed detection coverage is supplied. Defensive conclusions require local telemetry, software inventory, authentication architecture, and network baseline evidence.
Kessel
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1027.013 | Encrypted/Encoded File Sub-technique | Kessel's configuration is hardcoded and RC4 encrypted within the binary.CitationESET ForSSHe December 2018 |
| Enterprise | T1105 | Ingress Tool Transfer | Kessel can download additional modules from the C2 server.CitationESET ForSSHe December 2018 |
| Enterprise | T1030 | Data Transfer Size Limits | Kessel can split the data to be exilftrated into chunks that will fit in subdomains of DNS queries.CitationESET ForSSHe December 2018 |
| Enterprise | T1059 | Command and Scripting Interpreter | Kessel can create a reverse shell between the infected host and a specified system.CitationESET ForSSHe December 2018 |
| Enterprise | T1140 | Deobfuscate/Decode Files or Information | Kessel has decrypted the binary's configuration once the |
| Enterprise | T1016 | System Network Configuration Discovery | Kessel has collected the DNS address of the infected host.CitationESET ForSSHe December 2018 |
| Enterprise | T1554 | Compromise Host Software Binary | Kessel has maliciously altered the OpenSSH binary on targeted systems to create a backdoor.CitationESET ForSSHe December 2018 |
| Enterprise | T1082 | System Information Discovery | Kessel has collected the system architecture, OS version, and MAC address information.CitationESET ForSSHe December 2018 |
| Enterprise | T1090 | Proxy | Kessel can use a proxy during exfiltration if set in the configuration.CitationESET ForSSHe December 2018 |
| Enterprise | T1556 | Modify Authentication Process | Kessel has trojanized the |
| Enterprise | T1132.001 | Standard Encoding Sub-technique | Kessel has exfiltrated data via hexadecimal-encoded subdomain fields of DNS queries.CitationESET ForSSHe December 2018 |
| Enterprise | T1560 | Archive Collected Data | Kessel can RC4-encrypt credentials before sending to the C2.CitationESET ForSSHe December 2018 |
| Enterprise | T1041 | Exfiltration Over C2 Channel | Kessel has exfiltrated information gathered from the infected system to the C2 server.CitationESET ForSSHe December 2018 |
| Enterprise | T1048.003 | Exfiltration Over Unencrypted Non-C2 Protocol Sub-technique | Kessel can exfiltrate credentials and other information via HTTP POST request, TCP, and DNS.CitationESET ForSSHe December 2018 |
All related ATT&CK context
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.1 | Current bundle | 5a68f7997ddb… |
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]
ESET ForSSHe December 2018
Dumont, R., M.Léveillé, M., Porcher, H. (2018, December 1). THE DARK SIDE OF THE FORSSHE A landscape of OpenSSH backdoors. Retrieved July 16, 2020.
Open source URL -
[2]
mitre-attack S0487Open 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.