Some persistence does not add anything new to a machine. It changes something already trusted. MITRE ATT&CK technique T1554, Compromise Host Software Binary, covers modifying legitimate application binaries to keep access. The tactic is persistence, and the platforms are ESXi, Linux, macOS and Windows.
How attackers use it
MITRE explains that common binaries include SSH clients, FTP clients, email clients, web browsers and many other user or server applications. An adversary can replace or infect a legitimate binary, or its support files, with a backdoor. Because the binary is run routinely by users or other applications, it gives persistent access.
A modified SSH client is the example MITRE gives for collecting credentials at each login, which overlaps with Modify Authentication Process (T1556). Another approach is patching malicious functionality into an existing binary, such as IAT hooking or entry point patching, so the malicious code runs before the program continues normally.
After modification, adversaries may stop the binary from being updated and overwritten. MITRE's example is the yum-versionlock command or the versionlock.list file on Linux systems that use the yum package manager.
How to detect it
MITRE lists no data sources. The description points to integrity as the key signal:
- Hash or signature differences between installed binaries and the vendor package. A version pin on a security relevant package that nobody approved is a clue.
- Binaries modified outside a patch window, or modified by an account that is not your package manager or deployment tool.
- Unsigned or differently signed copies of programs that are normally signed.
- Unexpected outbound connections from tools such as SSH clients or mail clients.
File integrity monitoring on key directories gives a clear alert when a binary changes. Pair it with a record of what your patching tools did, so you can explain every legitimate change.
How to reduce the risk
MITRE lists one mitigation: code signing. Ensure all application component binaries are signed by the correct application developers, and verify the signatures before trusting them.
For software you build, the same idea extends further back. The more you can prove about where a binary came from, the easier it is to notice when the one on disk is not that binary. Signed artifacts and provenance records help here, and the demo walks through them. If your products include open source dependencies, you can also check them for known issues with the free in-browser scan at gold.safeguard.sh/scan. It needs no login, the file never leaves your machine, and it accepts up to 100 dependencies.
Click through it at your own pace, or open it full screen.
Check your own environment
Read-only verification commands:
# RPM based Linux: verify files of an installed package against the package database
rpm -V openssh-clients
# Debian or Ubuntu: verify an installed package (dpkg is read only here)
dpkg --verify openssh-client
# yum based Linux: list version locks
yum versionlock list
# Windows: check the signature on a binary
Get-AuthenticodeSignature "C:\Windows\System32\OpenSSH\ssh.exe"
Any file reported as changed needs an explanation. Version locks you did not create deserve a ticket.
Quick check
Why might an attacker pin a package version after modifying a binary?
To stop updates from overwriting the modified file. MITRE gives the yum-versionlock command and the versionlock.list file as examples on Linux.
