---
{
  "title": "Compromise Host Software Binary",
  "summary": "Host software binary compromise replaces or modifies an existing executable to retain access or introduce unauthorized behavior.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1554"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1554: Compromise Host Software Binary",
      "url": "https://attack.mitre.org/techniques/T1554"
    }
  ],
  "editorialVersion": 2
}
---

## Familiar software can contain changed behavior

Compromise of a host software binary modifies or replaces an existing executable or related software component so it performs unauthorized actions. The affected program may still carry out its normal function, making the additional behavior less obvious to users. Regular execution of the familiar application can then provide repeated access or collection opportunities.

This differs from merely placing a new suspicious file nearby. The investigator needs to establish that software already expected on the host was changed, which version should have been present, and how the altered component was used.

## A trusted client behaves unexpectedly

In a fictional company, a routinely used client application begins making an unexplained connection during ordinary work. The analyst checks its installed path, version, hash, signature information, package provenance, and recent modification history. They compare it with an independently trusted installation source for the same version.

A legitimate update can change a binary's hash and behavior, so a difference alone is not enough. Verify whether the change matches an approved release and deployment. Avoid comparing unrelated versions and declaring the newer file malicious merely because the bytes differ.

The team examines whether the program still performs its expected function and what additional actions occur. Process, file, authentication, and network records can help connect execution of the altered component with the observed effects.

## A signature is one piece of evidence

Signature validation can establish information about signing and integrity under the relevant trust model. It does not prove that every behavior of a program is appropriate for the environment. Conversely, an unsigned internal application may be legitimate. Use signature results alongside provenance, version, configuration, and observed behavior.

Preserve the suspect artifact through controlled handling before replacement where practical. Record its location and metadata, and do not execute it casually to compare behavior. [[digital-forensics]] provides the discipline for evidence preservation.

## Restore a trusted software state

Replace or rebuild affected software using a verified source and review the access that allowed modification. Check whether the same artifact was distributed to other hosts or whether a local change affected only one installation. The software supply path and deployment history determine the likely scope.

If the altered program could access credentials or sensitive information, investigate those consequences separately. Reinstalling the application does not automatically invalidate exposed credentials or revoke sessions.

For practice, compare a legitimate vendor update, an unauthorized local replacement, and a changed configuration file. Identify the evidence that distinguishes each and explain which comparison source you would trust. [[incident-response]] coordinates restoration, while [[incident-reporting]] should separate confirmed file changes from unproven claims about collected data.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[modify-authentication-process]]