Skip to content
Sign In
Learn

T1554

Compromise Host Software Binary

WindowsLinuxmacOS

What it is

Every host runs programs it trusts: remote access clients, authentication components, command-line utilities and the background tools that keep it managed. Compromising a host software binary means replacing or patching one of those programs so that it still does its normal job, and also does something the attacker wants.

Because the modified program is one the host already runs, the attacker's code runs with it, under its name, from its usual location. Nothing new has to be registered for the code to keep running, which is why ATT&CK files this technique as a way of staying resident.

How adversaries use it

The attacker needs write access to the program's file, which usually means administrative or root rights on the host. With that, they either swap the file for a look-alike build that carries their code, or patch the existing file in place.

The targets are chosen for reach and trust: a client that handles credentials, so it can quietly record them; a utility that runs often, so the code runs often; or a program that already runs with high privileges, so the code inherits them. The file keeps its name and path, so anything that checks only those sees nothing wrong.

Detect it in Elastic

Data source: Process-creation, file-write and module-load telemetry for programs already installed on the host, compared across hosts, with Windows Security auditing where Sysmon is absent

Key fields

There is rarely a single alert for this technique; the signal is an installed program that no longer matches the vendor's original. Four kinds of record show it, and they are strongest together. Not every environment collects all of them, so check which event codes are present before building a search around one.

Integrity across hosts. Sysmon Event ID 1 (event.code: "1") records process.executable and, with hashing enabled in the Sysmon configuration, process.hash.sha256 on every launch. The same program at the same path and version should hash identically on every host, so a host where that field differs for one path is the lead to follow. Windows Security Event ID 4688 also records process creation, and with command-line auditing enabled it adds the command line, but it carries no file hash: it shows that a program ran, not whether it was altered.

The change itself. Sysmon Event ID 11 records a file being created or overwritten; a file.path inside an installed product's folder, written by a process unrelated to that product, dates the change. Sysmon Event ID 29 records a new executable file being written, which narrows that to program files. Sysmon's file-creation-time event records a file's creation time being altered, a common way to make a replaced file look old. Where Sysmon is not deployed, Windows Security Event ID 4663, with object-access auditing on program folders, records the write and the process that made it.

What loads. Sysmon Event ID 7 records each module a process loads, with its code-signature fields, so a library the vendor normally signs loading unsigned stands out.

How it keeps running. A modified program often runs as a service so that it starts on its own. A new service appears as Windows Security Event ID 4697 or System log Event ID 7045; when the service's file path points at a program that also changed, the two signals together are far stronger than either alone.

Example event

{
  "host": {
    "name": "SRV04"
  },
  "event": {
    "code": "1",
    "action": "Process creation"
  },
  "process": {
    "hash": {
      "sha256": "3b1f9c...e07a"
    },
    "executable": "C:\\Program Files\\ExampleVendor\\Agent\\agent.exe"
  }
}

Hunt guidance

Compare each program with itself. A host runs the same binaries day after day, so record what each executable looked like on that host before: its hash, its signer, its size. A program that starts running with a hash that host has never seen for it is the lead, especially when nothing else about the host changed at the same time.

Process-creation telemetry is where this is cheapest to see, because it records the hash of the image every time a program starts. Group by host and executable path, and look for a path whose hash changes. Then ask what wrote the new file: which process modified it, under which account, and when.

Check the signature as well as the hash. A replaced program that was signed before and is now unsigned, or signed by someone else, has changed in a way a routine change does not explain.

Ruling out legitimate activity

Programs change legitimately all the time. Patches, version upgrades and reinstalls all produce a new hash for the same path, and a busy estate produces many of them every week.

What separates a routine change is its context. A legitimate new version is signed by the same publisher as before, was written by the process that normally manages that software, and lines up with a known change. A change that breaks the signature, was written by an unexpected process or account, or has no change behind it is the one to pursue.

Telemetry needed

The log events that help detect this technique, from the Telemetry reference: which log source to collect, which event in it, and how to enable each one.

References

Practice it

1 scenario in this catalog covers T1554. We don't name it, because identifying the technique is part of what a scenario grades. Explore the Range →