S0487: Kessel

Kessel is an advanced version of OpenSSH which acts as a custom backdoor, mainly acting to steal credentials and function as a bot. Kessel has been active since its C2 domain began resolving in August 2018.[1]

EnterpriseS0487MalwareObject v1.1 Modified Apr 11, 2024, 01:48 UTC (UTC+00:00)

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.

Official MITRE ATT&CK definition

Kessel

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

Filter related techniques 14 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1027.013	Encrypted/Encoded File Sub-technique	Kessel's configuration is hardcoded and RC4 encrypted within the binary.[1]
Enterprise	T1105	Ingress Tool Transfer	Kessel can download additional modules from the C2 server.[1]
Enterprise	T1030	Data Transfer Size Limits	Kessel can split the data to be exilftrated into chunks that will fit in subdomains of DNS queries.[1]
Enterprise	T1059	Command and Scripting Interpreter	Kessel can create a reverse shell between the infected host and a specified system.[1]
Enterprise	T1140	Deobfuscate/Decode Files or Information	Kessel has decrypted the binary's configuration once the `main` function was launched.[1]
Enterprise	T1016	System Network Configuration Discovery	Kessel has collected the DNS address of the infected host.[1]
Enterprise	T1554	Compromise Host Software Binary	Kessel has maliciously altered the OpenSSH binary on targeted systems to create a backdoor.[1]
Enterprise	T1082	System Information Discovery	Kessel has collected the system architecture, OS version, and MAC address information.[1]
Enterprise	T1090	Proxy	Kessel can use a proxy during exfiltration if set in the configuration.[1]
Enterprise	T1556	Modify Authentication Process	Kessel has trojanized the ssh_login and `user-auth_pubkey` functions to steal plaintext credentials.[1]
Enterprise	T1132.001	Standard Encoding Sub-technique	Kessel has exfiltrated data via hexadecimal-encoded subdomain fields of DNS queries.[1]
Enterprise	T1560	Archive Collected Data	Kessel can RC4-encrypt credentials before sending to the C2.[1]
Enterprise	T1041	Exfiltration Over C2 Channel	Kessel has exfiltrated information gathered from the infected system to the C2 server.[1]
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.[1]

Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release: 19.1
Object version: 1.1
Created: Jul 16, 2020, 15:14 UTC (UTC+00:00)
Modified: Apr 11, 2024, 01:48 UTC (UTC+00:00)
Raw hash: 5a68f7997ddbcef9...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	Jun 3, 2026, 07:54 UTC (UTC+00:00)	1.1	Apr 11, 2024, 01:48 UTC (UTC+00:00)	Current bundle	`5a68f7997ddb…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

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 S0487
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use