Home/ATT&CK Technique/Compromise Host Software Binary
ATT&CK Technique

Compromise Host Software Binary

T1554 · persistence

Adversaries may modify host software binaries to establish persistent access to systems. Software binaries/executables provide a wide range of system commands or services, programs, and libraries. Common software binaries are SSH clients, FTP clients, email clients, web browsers, and many other user or server applications.

Adversaries may establish persistence though modifications to host software binaries. For example, an adversary may replace or otherwise infect a legitimate application binary (or support files) with a backdoor. Since these binaries may be routinely executed by applications or the user, the adversary can leverage this for persistent access to the host.

An adversary may also modify a software binary such as an SSH client in order to persistently collect credentials during logins (i.e., Modify Authentication Process). An adversary may also modify an existing binary by patching in malicious functionality (e.g., IAT Hooking/Entry point patching) prior to the binary’s legitimate execution. For example, an adversary may modify the entry point of a binary to point to malicious code patched in by the adversary before resuming normal execution flow.

After modifying a binary, an adversary may attempt to impair defenses by preventing it from updating (e.g., via the yum-versionlock command or versionlock.list file in Linux systems that use the yum package manager).

ESXiLinuxmacOSWindows
▣

Mitigations

1
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1045Code Signing

Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks.

Enforce Signed Code Execution
  • Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute.
  • Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.
Vendor-Signed Driver Enforcement
  • Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded.
  • Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.
Certificate Revocation Management
  • Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code.
  • Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.
Third-Party Software Verification
  • Implementation: Require software from external vendors to be signed with valid certificates before deployment.
  • Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.
Script Integrity in CI/CD Pipelines
  • Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release.
  • Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers. Key Components of Code Signing.
  • Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity.
  • Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists.
  • Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts.
  • Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.
◈

Detection Coverage

1/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) 5
Analytics (MITRE CAR) none
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none
▣

Comply & Defend

NIST 800-53CM-02, CM-05, CM-06, IA-09, SI-03, SI-07, SR-04, SR-05, SR-11
D3FEND4 defensive techniques
Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
MITRE ATT&CKAtomic Red Teamcar (MITRE)
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin