When an attacker replaces the SSH client, a VPN appliance script or a system library with a backdoored copy, every legitimate use of that software runs their code and hands them credentials, with no new process, service or scheduled task to find. MITRE ATT&CK T1554 Compromise Host Software Binary covers adversaries modifying host software binaries, or their support files, to establish persistent access. ATT&CK v20 places it under Persistence (TA0003) on Windows, Linux, macOS and ESXi, maps one mitigation (M1045 Code Signing) and one detection strategy (DET0336), and records espionage groups, appliance implants and credential stealers using it. This guide is the technique view: the recorded cases, the integrity checks and telemetry that catch a modified binary, and how to remove one with confidence. It is for detection engineers, Linux and appliance owners and incident responders. Compromise of software before it reaches you is T1195; see the MITRE ATT&CK T1195 Supply Chain Compromise guide, which this page does not repeat.
Key takeaways
- Location, not delivery, defines it. T1554 is a change made on your host after compromise; T1195 is a change made before the software reached you. The detection and the fix differ.
- Credential-handling software is the favourite target. OpenSSH clients and libraries, TACACS+ daemons, VPN appliance scripts and browsers dominate the ATT&CK v20 procedures, because the modified binary sees passwords in clear text.
- Package and vendor hashes are the ground truth. Comparing installed files with package manager databases, vendor manifests and signatures finds a trojanised binary that looks normal in a process list.
- Appliances need their own approach. Several cases target edge appliances where you cannot run an agent; vendor integrity tools, external checks and forensic images are the options, and a single integrity check has been shown to miss compromise.
- Assume the credentials are gone. A trojanised SSH client, authentication daemon or VPN script means every credential that passed through it must be rotated, including service account and API credentials.
What the technique covers
ATT&CK v20 describes T1554 as adversaries modifying host software binaries, such as SSH clients, FTP clients, email clients, web browsers and other user or server applications, by replacing or infecting a legitimate application binary or its support files with a backdoor, so that routine execution gives persistent access. It also covers patching malicious functionality into an existing binary (for example IAT hooking or entry point patching) and notes that adversaries may then stop the binary from being updated, for example through the yum-versionlock command or the versionlock.list file on yum-based Linux systems. T1554 has no sub-techniques. The ATT&CK page shows version 2.2, last modified 3 November 2026, with 25 procedure examples.
| Related technique | How it differs from T1554 |
|---|---|
| T1195.002 Compromise Software Supply Chain | The software is altered before delivery; every customer receives the same modified build |
| T1505.003 Web Shell | A new server-side script is added; T1554 cases on appliances often insert web shell code into an existing legitimate file instead |
| T1574 Hijack Execution Flow | A legitimate binary loads attacker code (DLL search order, library path); the binary itself is unchanged |
| T1556 Modify Authentication Process | Changes authentication components specifically; trojanised authentication daemons can fit both |
| T1036 Masquerading | Malware named or placed to look legitimate; in T1554 the legitimate file really is modified |
How adversaries use it: real cases
The examples below are procedure entries in the ATT&CK v20 data, with the sources ATT&CK cites.
| Group, software or campaign | Platform | Recorded behaviour |
|---|---|---|
| Ebury | Linux | Modifies the keyutils library to add malicious behaviour to the OpenSSH client and the curl library (ESET) |
| Kessel, Bonadan, Kobalos | Linux | Maliciously altered OpenSSH binaries for backdoor access; Kobalos replaced the SSH client to steal credentials (ESET) |
| UNC3886 | Network appliances, Linux | Trojanised Fortinet firmware and replaced the TACACS+ daemon /usr/bin/tac_plus with a version containing credential logging; in campaign RedPenguin, patched the snmpd and mgd Junos OS daemons in memory (Mandiant, Juniper) |
| Cutting Edge campaign: WARPWIRE, LIGHTWIRE, WIREFIRE, BUSHWALK, FRAMESTING | Ivanti Connect Secure | Trojanised legitimate appliance files, for example embedding code in compcheckresult.cgi, querymanifest.cgi and visits.py (Mandiant, Volexity) |
| LITTLELAMB.WOOLTEA | Ivanti Connect Secure | Appends components to an archive inside the factory reset partition to persist after reset |
| APT5, SLOWPULSE | Pulse Secure | Modified legitimate binaries and scripts, including DSUpgrade.pm, to install a web shell |
| Sandworm Team (2016 Ukraine electric power attack, Industroyer) | Windows | Trojanised Windows Notepad as an additional backdoor persistence layer (ESET) |
| XCSSET; ThiefQuest | macOS | Replaced the browser with a malicious application; prepended code to executables in user folders |
| Mini Shai-Hulud; campaign C0064 | Developer environments | Planted AI coding agent configuration or instruction files that act as hooks for execution and persistence |
The Ebury case shows the scale this can reach: ESET reported in 2024 that about 400,000 Linux servers had been compromised by Ebury since 2009, with more than 100,000 still compromised as of late 2023. The developer-environment cases are a newer pattern: a file that an AI coding agent reads as instructions becomes a persistence point in the same way a modified binary does. See the AI Coding Agents Security Guide.
Ivanti Connect Secure, 2024
In the Ivanti Connect Secure Exploitation 2024 incident, attackers chained two zero-days, then inserted a credential-harvesting script into a legitimate appliance file and patched a legitimate binary to stop it redacting sensitive data in configuration dumps. CISA reported that the vendor's integrity checker had failed to detect compromise in some cases and warned that root-level persistence could survive a factory reset. The customer-side lessons are the ones this page builds on: run integrity checks, but do not rely on one; treat credentials, service account passwords, API keys and certificates stored on or passing through a modified appliance as stolen; and keep the ability to rotate them within hours. Hardening for that platform is in the Ivanti Connect Secure Hardening and Integrity Checking Guide.
What to detect and where
ATT&CK v20 detection strategy DET0336 "Detect Compromise of Host Software Binaries" has four analytics: unexpected modification of system or application binaries correlated with subsequent unsigned or anomalously signed execution, or with unexpected service behaviour. The log sources come from DET0336; the detection ideas are NHI Mgmt Group recommendations.
| Platform | Log sources in DET0336 | What to look for |
|---|---|---|
| Windows (AN0949) | Sysmon 11 (file create), Sysmon 2 (file creation time changed), Security 4688 | Writes to System32 or Program Files binaries by processes other than Windows Update, installers or software distribution agents; a binary that was signed now running unsigned or with a different signer; file timestamps changed on executables |
| Linux (AN0950) | auditd open and write on /usr/bin, /bin, /usr/sbin, library paths; execve | Writes to binaries and shared libraries outside a package manager transaction; sshd or ssh modified; new entries in yum versionlock.list that nobody requested |
| macOS (AN0951) | Unified log binary modification and execution events | Modified files in /Applications or system library paths executed without a valid signature or notarisation |
| ESXi (AN0952) | hostd binary or module replacement events; vmkernel module loads | Unexpected module loads or replaced binaries, followed by unusual service behaviour. See the ESXi Logs Detection Guide. |
Integrity checks that find what events miss
- Package verification: on RPM-based Linux,
rpm -Vacompares installed files with the package database; on Debian-based systems,debsumsdoes the same from package checksums. Run them from trusted media or a known-good host where possible, because a rootkit can hide from the local system. - Signature verification: on Windows, check Authenticode signatures of binaries in critical paths and alert on any unsigned or newly signed file; on macOS, check code signature and notarisation status.
- File integrity monitoring: baseline hashes for authentication and remote access binaries (
sshd,ssh,sudo, PAM modules,libkeyutils, TACACS+ and RADIUS daemons) and alert on any change outside a patch window. See the Linux File Integrity Monitoring Guide. - Appliance integrity: run the vendor's integrity tool on its schedule, and also compare against an external baseline, because an implant running as root can interfere with checks run on the same device.
- Behaviour of the binary: an SSH client or authentication daemon opening outbound connections to unusual hosts, or writing to unexpected files, is a strong signal even when hashes are not available.
Mitigations and hardening
ATT&CK v20 maps one mitigation to T1554: M1045 Code Signing, ensuring all application component binaries are signed by the correct developers. The other controls below are NHI Mgmt Group recommendations that make a modified binary either impossible to run or quick to find.
| Control | Mechanism | Effect on T1554 |
|---|---|---|
| Code signing enforcement (M1045) | Application control policies that allow only binaries signed by expected publishers; verify signatures before execution | A modified signed binary fails verification and is blocked. See M1045 Code Signing. |
| Read-only system partitions | Immutable or read-only operating system images where the platform supports them | Binaries cannot be modified in place without a visible remount |
| Least privilege for write access | Restrict who and what can write to binary and library paths; no routine root or administrator sessions | Fewer paths to modify a binary |
| File integrity monitoring | Hash baselines on critical binaries with alerting | Detects changes quickly. See the File Integrity Monitoring Guide. |
| Patch hygiene with lock auditing | Alert when version locks or update exclusions are added for security-relevant packages | Catches attempts to stop the trojanised binary being overwritten by updates |
| Rebuild over repair | Golden images and infrastructure as code, so hosts are redeployed rather than cleaned | Removes modified binaries without needing to find each one |
Where identity fits
Most T1554 cases exist to steal credentials: SSH passwords and keys through a modified client or library, administrator passwords through a trojanised TACACS+ daemon, and VPN user and service credentials through modified appliance scripts. That makes this technique a direct threat to non-human identities as well as people. Service accounts that authenticate through a compromised appliance or jump host, SSH keys used by automation, and API keys stored on the device all need rotation when a modified binary is found. Prefer short-lived, certificate-based or federated credentials for automation so a captured secret expires quickly. See How to Find ssh authorized keys across a server fleet.
Removing a compromised binary
- Preserve evidence: copy the suspect binary, its package metadata and memory if possible before changing anything; record hashes.
- Confirm against ground truth: compare with the vendor package or signed release of the same version; confirm what was changed.
- Scope: hunt for the same hash, the same modified library and the same persistence trick (version locks, factory reset partition changes) across the fleet.
- Rebuild, do not patch in place: redeploy the host or appliance from a trusted image; for appliances, follow the vendor's factory reset and upgrade guidance, and verify the result with an external integrity check.
- Rotate credentials: rotate every credential that passed through or was stored on the host, including service accounts, SSH keys, API keys and certificates.
- Close the entry point: fix the vulnerability or access path that allowed the modification, then monitor the rebuilt host closely for re-entry.
Roll back by keeping the previous image available until the rebuilt host is verified in service.
Small and large organisations
A small organisation should run package verification on Linux servers on a schedule, enable signature-based application control on Windows servers, and keep a short list of edge appliances with their vendor integrity checks. A large organisation adds FIM on critical binaries fleet-wide, DET0336 analytics per platform, external integrity checks for appliances, and automated credential rotation tied to incident response.
How to test your coverage
- Lab modification: on a test host, replace a non-critical binary with a different build of the same tool and confirm FIM, package verification and DET0336-style alerts fire.
- Signature test: run an unsigned copy of an allowed binary on a test server under application control and confirm it is blocked and logged.
- Version lock test: add a version lock for a security package on a test host and confirm the alert.
- Appliance drill: rehearse the rebuild and credential rotation for one edge appliance and time it.
- Record results: update the ATT&CK coverage map for T1554.
Metrics
- FIM coverage: share of servers with integrity baselines on authentication and remote access binaries.
- Verification cadence: share of Linux servers with a clean package verification in the last 30 days.
- Application control coverage: share of servers enforcing signature-based execution.
- Unexplained binary changes: count per month of binary modifications without a patch or change record.
- Rotation time: hours to rotate all credentials on an appliance after a confirmed compromise.
Framework mapping
| Framework | Relevant items |
|---|---|
| MITRE ATT&CK v20 | TA0003 Persistence; T1554; related T1195.002, T1505.003, T1574, T1556, T1036 |
| ATT&CK mitigation and detection | M1045 Code Signing; DET0336 |
| NIST SP 800-53 Rev. 5 | SI-7 Software, Firmware, and Information Integrity, SI-7(1) Integrity Checks, SI-7(15) Code Authentication, CM-14 Signed Components, CM-3 Configuration Change Control |
| NIST CSF 2.0 | PR.PS-05 (unauthorised software prevented), DE.CM-09 (computing hardware and software monitored), PR.PS-01 (configuration management) |
| CIS Controls v8.1 | Control 2 Inventory and Control of Software Assets (allowlisting), Control 4 Secure Configuration, Control 8 Audit Log Management |
Practitioner checklist
- Baseline and monitor hashes of SSH, sudo, PAM, authentication daemon and key library files on every server.
- Run package verification on Linux servers on a schedule and investigate every mismatch.
- Enforce signature-based application control on servers and alert on unsigned binaries in system paths.
- Alert on new package version locks or update exclusions for security-relevant software.
- Run vendor integrity checks on edge appliances and add an external check.
- Rebuild compromised hosts and appliances from trusted images rather than cleaning in place.
- Rotate every credential, key and certificate that passed through a modified binary.
- Rehearse the appliance rebuild and rotation at least once a year.
Standards and references
- MITRE ATT&CK: Compromise Host Software Binary (T1554)
- MITRE ATT&CK: Cutting Edge (C0029)
- MITRE ATT&CK: Code Signing (M1045)
- ESET WeLiveSecurity: Ebury is alive but unseen
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: ATT&CK Persistence Tactic · T1505 Server Software Component Defensive Guide · Code Signing Security Guide · Persistence Techniques Guide