Detecting T1554 Compromise host software binary

How T1554 compromise host software binary keeps an attacker in place

A host looks normal, services start on schedule and the binaries on disk carry the names your team expects, yet one of those trusted binaries may have been altered to keep an adversary's foothold alive. T1554 Compromise host software binary is the ATT&CK technique for that situation: the adversary modifies software the host already runs so that the malicious behavior rides along with legitimate execution. It sits under the Persistence tactic (TA0003) because, as MITRE describes the tactic, the adversary is trying to maintain their foothold, and a modified binary survives reboots, logons and routine operations without needing a new dropped file to be launched.

In intrusions, this technique usually shows up after an adversary already has elevated access on a system, often on servers, hypervisors, network appliances or developer workstations where administrators have legitimate write rights to application or management binaries. The key distinction from a new binary dropped elsewhere is that the altered file already has a trusted path, a trusted name and a trusted place in the startup or execution chain, so allow lists based on file name or location may not raise an alert. Your SOC lead should expect detection to depend on integrity, provenance and change history rather than on whether a new executable appeared.

Mapping work should name the ATT&CK version it targets. These pages use Enterprise ATT&CK v20.0, and your detection content, Sigma rules and coverage reports should cite that version explicitly, because releases can rename, deprecate or revoke techniques and sub-techniques. Confirm with your team which version your SIEM content and detection strategies were written against, and check the MITRE ATT&CK updates page before you reuse mappings from older reports.

Which telemetry reveals a tampered host binary

This table maps the three telemetry sources ATT&CK links to T1554 detection (Process Creation, File Modification and File Creation) to the signal each one gives, and to open-source collectors on ESXi, Linux, macOS and Windows. Read each row as a question: what changed, where, and whether the change is expected. Coverage differs by platform, so confirm each collector in your own environment before relying on it.

Telemetry (ATT&CK data component)	Signal to look for	Open-source collectors and platform notes
Process Creation (DC0032)	Executables launched from system paths whose signature, publisher or hash does not match the expected baseline	Sysmon-style process logging on Windows; auditd or Wazuh process telemetry on Linux; confirm macOS and ESXi coverage in your environment
File Modification (DC0061)	Changes to existing binaries in system directories such as /usr/bin, /sbin, C:\Windows\System32 or ESXi system partitions	Wazuh file integrity monitoring on Linux, macOS and Windows; confirm which ESXi paths can be monitored through your logging pipeline
File Creation (DC0039)	New executables or replaced files appearing in trusted binary locations outside a patch or change window	Wazuh file integrity monitoring; Velociraptor artifacts that enumerate binary directories on Linux, macOS and Windows
Hash drift against a known baseline	Current hashes of monitored binaries differ from the recorded baseline taken after a verified install or patch	Velociraptor hunts that compare file hashes to a baseline; confirm baseline storage and update workflow with your team
Unsigned or mismatched executables	Binaries that run from trusted locations but lack a valid code signature or carry a signature from an unexpected signer	Velociraptor artifacts for signature status on Windows and macOS; confirm equivalent checks for Linux package verification
Signing and trust policy	Execution attempts blocked or flagged for unsigned binaries, linked to the ATT&CK mitigation Code Signing (M1045)	Platform-native enforcement features vary by OS; confirm what your Windows, macOS and Linux builds support before writing detections

Detection logic for binary tampering that SOC teams can tune

The four to six ideas below combine file integrity, execution context, signature validation and management-plane activity into one picture of binary tampering. No single signal is conclusive on its own, because patching and configuration management also change binaries. Each card names the logic, the threshold to start with and the false positive sources to exclude before alerting.

Baseline hash and signature drift

Build a known-good inventory of hashes and signer details for protected system binaries, captured after each approved patch cycle. Alert when a monitored file's hash or signature changes outside a registered change window. Start with a narrow set of high-value binaries such as authentication, remote access and logging components, then widen the set as tuning matures. Expect false positives from OS patches, package manager upgrades and configuration management runs, so feed change tickets and package manager events into the suppression logic. Use auditd or Wazuh file integrity monitoring to collect the events, and confirm the agent's real-time coverage with your vendor documentation.

Modified binary then executed by a service account

Correlate a file modification event on a system binary with a later process creation event for the same path, where the executing account is a service account. Service accounts rarely run interactively, so an unexpected run from a modified binary deserves priority. Use a time window you define in your own environment, starting with a short window such as a few hours, and review hits where the parent process is a shell or an unfamiliar scheduler. Common false positives include scheduled maintenance jobs and newly installed packages, so tie the rule to change records and to the service account's expected command set.

Code signature validation failures

On Windows and macOS, alert when a system executable fails signature validation or carries a signer that differs from the expected publisher. Also flag executables in system directories that are unsigned while their neighbors are signed. Set the first threshold at any failure on a protected binary, then review the rate per host during the first weeks. Expected sources of noise include third-party software that replaces system components, legitimate re-signing after a vendor update, and stale certificate chains on hosts that missed updates. Confirm how your endpoint tooling reports validation results before writing rules against them.

ESXi host binary changes with management logins

On ESXi hosts, correlate modifications to host binaries or boot-related files with management-plane logins from vCenter or direct host sessions in the same window. The pairing matters because an administrator login followed by an unexplained binary change is a stronger signal than either event alone. Start with a window in the range of the change process your team already uses, and exclude updates pushed through the approved lifecycle tooling. Expect false positives from host patch remediation, maintenance mode operations and vendor-supplied image changes, so confirm which of these produce logs in your environment before tuning.

Unexpected change on Linux package-managed files

Compare modified binaries under package-managed paths against the package database, and alert when a file's content no longer matches the package it belongs to. Package verification reports a mismatch whenever a file changes after installation, so treat mismatches on binaries that no package update touched as the high-priority set. Pair the check with a review of recent package operations on the same host. Expect noise from configuration files that administrators are expected to edit, from kernel and library updates that are still staged, and from containers with overlay file systems. Confirm the verification behavior for your distribution in its own documentation.

How to validate that the T1554 detection fires

This sequence proves that a T1554 detection fires on a benign, controlled modification of a host software binary, and that the alert reaches the SOC queue with the fields analysts need. It produces a dated evidence record that shows the detection works, how quickly it works, and what was tuned along the way.

Define the benign test scope
The detection owner and the platform team agree on a small set of non-production hosts across the platforms the rule covers, such as ESXi, Linux, macOS and Windows where they exist in the range. They also agree on test binaries that are harmless, clearly named and created only for this exercise, so no production software is touched. Written sign-off from the system owner and the SOC lead closes this step. Confirm that the range snapshots can restore every test host before anything changes.
Agree the change window and rollback
The team sets a change window with the range operators and the SOC, and records who may approve a stop if the range behaves unexpectedly. The SOC is told that alerts in this window are expected, so analysts can label them without losing the test result. Rollback steps and snapshot identifiers are written into the change record. The step is done when the change ticket lists the hosts, the test binaries, the window and the rollback owner.
Record baseline hashes and state
Before any change, the test owner records cryptographic hashes of each test binary and the expected file metadata, such as owner, permissions and modification time, on every host in scope. The same is captured from the file integrity monitoring or endpoint telemetry source so the baseline exists in the SIEM as well as on the host. The step closes when each host has a baseline record that can be compared later.
Run the planned modification in the range
A designated operator performs the planned modification to the benign test binaries exactly as the scope describes, and nothing beyond it. The operator notes the start and end times in the change record and does not alter other files. The range should be checked for unexpected side effects during the window. The step is complete when the operator confirms the modification in writing and the hashes differ from the baseline as expected.
Confirm the alert reaches the SOC queue
The SOC checks that an alert for each affected host appears in the case queue within the time the rule is designed to take. Analysts confirm the expected fields are populated, including host name, file path, process or actor context where the telemetry provides it, timestamps, and the ATT&CK technique reference. Missing fields are logged as gaps for the platform team. The step closes when each host has a matching alert or a documented reason why it did not fire.
Record the evidence for each run
The test owner writes an evidence record for the run that includes the hosts, the timestamps of the change and the alert, the hashes before and after, the alert latency, the rule identifier and version, and the ATT&CK version the mapping targets. Screenshots or exported alert records are stored with the change ticket. This record is what auditors and internal reviewers will ask to see, so it should be stored in the evidence repository the organization already uses.
Tune the rule and rerun the test
If the alert was late, missing fields, noisy with unrelated changes, or absent, the detection engineer adjusts the rule logic, its data source mapping or its thresholds and records the change in version control. The same benign modification is then rerun in the same range and window rules, and the new evidence record is compared with the previous one. The loop closes when the rerun meets the agreed criteria, and the tuning change and both records are kept together.

Preventive controls that make binary tampering harder

Preventive controls do not detect T1554 on their own, but they narrow the set of binaries an adversary can modify and make tampering more visible when it happens. The four mitigations below work together: signing establishes what a trusted binary should look like, write restrictions limit who can change it, auditing records attempts, and privilege management limits who holds the rights to make changes in the first place.

Code signing as a baseline

Code Signing (M1045) lets a host reject or flag binaries whose signature is missing, invalid or from an unexpected publisher. A modified vendor binary usually breaks its signature, so signature verification gives you a comparison point that does not depend on guessing what the file should contain. Confirm which platforms in your estate enforce signature checks at load time, which only report on mismatches, and which cannot verify signatures for your in-house or open-source builds. Also confirm how revocation and key rotation are handled for each publisher.

Restricted write access to binaries

Restrict File and Directory Permissions (M1022) keeps ordinary users and service accounts from writing to directories that hold system binaries, interpreters, libraries and daemons. Most T1554 activity needs write access to a path that a host later executes, so removing that right from non-administrative identities removes a common route. Check ownership and mode settings on binary directories, shared library paths and container base images, and test that package managers and patch tooling still work under the restricted model.

Audit of binary changes

Audit (M1047) means enabling the operating system or platform logging that records changes to binaries and the processes that make them. Without audit policy, a replaced binary can look identical to a legitimate update in your logs. Decide which paths and events are in scope, confirm that the audit configuration is enforced by configuration management, and check that events reach your Wazuh or other collection pipeline with enough retention to investigate. Confirm the audit capabilities of each ESXi, Linux, macOS and Windows build in your environment, since event names and coverage vary.

Privileged account management

Privileged Account Management (M1026) limits which accounts can write to system binaries, install packages or change host-level configuration. Most binary tampering requires administrative or root rights, so tight control over those accounts reduces the number of paths an adversary can use. Review standing administrative group membership, require separate privileged accounts for administration, and rotate or remove credentials that no longer have a use. Confirm how privileged sessions are recorded and whether break-glass accounts are monitored for binary changes.

Triage and response when a binary tampering alert fires

Start by deciding whether the change was authorized, because a modified binary on an ESXi host, Linux server, macOS endpoint or Windows server is either a planned update or a possible compromise, and the first hour of triage separates the two. Ask the change owner whether a patch, vendor package or configuration deployment was scheduled for that host and window, then compare the file's hash and digital signature against a known-good source such as the vendor's signed release, your internal golden image or the package manager's recorded digest. A valid signature from the expected publisher on a binary that changed during a maintenance window is a very different finding from an unsigned or self-signed binary with no change ticket. Preserve the binary itself, a forensic copy of the relevant logs and any memory or volatile data your runbook calls for before anyone reboots or reinstalls, and record the collection time and the person who collected it.

Once the change is classified as unauthorized or unexplained, work outward from the file. Pull process creation records for the binary and its parent process from the period after the modification, check which network connections that process opened, and identify which accounts wrote to or modified the file, using file modification and audit records from the host or your central logging platform. Note that the signal you confirm here, such as the account, parent process or first execution time, is what the detection rule should be tuned against later. For containment, decide per platform: isolating the host from the network while keeping it powered is usually the first step; on ESXi, consider whether the affected host must be placed in maintenance mode and whether virtual machines on it need to be moved; on Windows, Linux and macOS, disable affected accounts and block the relevant hash or path at the endpoint control layer. Rebuild the host from trusted media or a verified golden image rather than cleaning the binary in place, then rotate any credentials the binary could have read.

Record the decision in the incident ticket so an auditor can follow it later: the alert, the evidence reviewed, who approved the containment and rebuild, the hash values compared and the source they were compared to, and the time each step finished. Confirm with your compliance lead which evidence format and retention period your framework expects, since DeployOpen does not set those requirements and the answer depends on your own obligations. After recovery, run the detection again against the rebuilt host to confirm the alert clears only for the intended reason, and feed the confirmed indicators into the rule's tuning notes. Your post-incident review should also check whether the golden image, signing process or change-record process allowed the tampering to go unnoticed, because the mitigation Code Signing only helps if your hosts enforce signature checks and your team knows which signatures to trust.

How to rehearse T1554 detection in a private cyber range

Build a small isolated segment with one Linux host and one Windows host, both enrolled with a Wazuh agent or an equivalent endpoint collector, and a mirrored traffic sensor such as Zeek or Suricata watching the segment. Keep the range off production networks and use only test images that no business system depends on. The exercise should cover file modification and file creation events on the paths where software binaries and service executables live, plus process creation events that show which binary ran and from where.

Benign injects: Replace a test utility with a modified copy on one host, then stage a patch-like update that changes the binary and its version string through the normal package or installer path.
Unsigned test executable: Drop an unsigned, harmless test binary into a monitored directory and launch it, so the team can see how signature state appears in the telemetry.
Good detection: Alerts fire on binary changes outside an approved change window, the patch-like update is correlated with a change record, and the unsigned binary is flagged on first execution.
Good response: Analysts reach a triage decision within a time target the team sets in advance, and evidence includes the file hash before and after, the writing process, and the account involved.

Confirm the agent and sensor versions your team will use in the range, and record them so results can be repeated.

Questions SOC leads ask about detecting T1554

How do I separate legitimate patching from binary tampering on hosts?

Treat a change to a host software binary as suspicious until a known change record explains it. Patching usually arrives through a managed channel, from a known package or update process, inside a maintenance window, and is followed by the expected service restarts. Tampering tends to show a binary changed outside those channels, with a signature that no longer validates, a parent process that is not the package manager or update agent, or changes on a host that has no pending update. Build an allowlist of approved update processes and change windows, then alert on binary modifications that fall outside them. Compare file hashes against the vendor's published values where available, and confirm the signing chain on Windows and macOS before closing an alert.

Is file integrity monitoring enough without process telemetry?

File integrity monitoring is a strong starting point because it reports that a binary changed, but it rarely explains who or what changed it. Without Process Creation telemetry, an analyst cannot tell whether the change came from an update, an administrator, or a foreign process, so triage takes longer and false positives rise. Pair file integrity signals with process lineage, command execution records and signature validation where the platform supports them. Confirm in your own environment which events your agents and log pipeline actually capture before assuming coverage, since file modification events vary by operating system and configuration.

How should we handle ESXi host coverage for this technique?

ESXi hosts are often the hardest part of T1554 coverage because standard endpoint agents may not run on them. Start by inventorying which hypervisor logs, syslog streams and host configuration changes reach your central pipeline, and confirm whether your collection method exposes file modification or process events at all. Where direct binary telemetry is limited, rely on centralized log forwarding, configuration baselines and change tracking at the vendor management layer, and document the gap explicitly. Confirm with your hypervisor vendor which audit events are available and how they are retained before you write rules that depend on them.

Which ATT&CK version should a detection rule cite?

Cite the exact ATT&CK version your rule was written against, because releases can rename, deprecate or revoke techniques and change how detections are structured. ATT&CK v18 replaced technique-level detections with detection strategies and analytics and deprecated some data sources, so a rule mapped to older data source names may need re-mapping. Record the version, the technique ID and any sub-technique ID in the rule metadata, and review the mapping whenever a new release appears. The current release history is listed on the MITRE ATT&CK updates page.

How often should we rerun validation after tuning detections?

Rerun validation after every change that could alter detection behavior, including rule edits, agent upgrades, log source changes, host image rebuilds and tuning that adds exclusions. Many teams also schedule a periodic regression run so that silent drift is caught between changes. The right cadence depends on how often your environment changes and how much exclusion tuning you do, so agree it with your SOC and change management owners. Keep each run's results with the rule version so auditors and responders can see what was tested and when.

Can we run these detections and exercises ourselves?

Many teams can build and operate T1554 detections in-house if they already run a log pipeline and an open-source SIEM or EDR stack, and they have staff who understand the platforms involved. The effort concentrates in source coverage, hypervisor telemetry, tuning and validation, which need ongoing ownership. DeployOpen implements and documents open-source platforms inside a client's own infrastructure and runs cyber range exercises under fixed-scope agreements, so a written scope can cover the detection build, the rehearsal or both. Ask any partner to state in writing which log sources, platforms and rules are in scope and what evidence you will receive.

What evidence should a detection for this technique keep for auditors?

Keep the rule source, its ATT&CK version and technique mapping, the log sources it depends on, and the date of the last successful validation run. Auditors also want proof that alerts were triaged, including the change record used to judge whether a binary change was approved. Store validation results from the cyber range alongside tuning notes so that each exclusion has a documented reason. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors and certification bodies decide whether that evidence is sufficient.

How DeployOpen builds T1554 detections and range exercises

DeployOpen approaches T1554 Compromise Host Software Binary as a fixed-scope engagement inside your own infrastructure, covering detection content, telemetry and cyber range rehearsal. Each step is agreed in writing so your team knows what is delivered, how it is tested and who maintains it afterward.

How we scope

Confirm which hosts in scope run ESXi, Linux, macOS or Windows, and which software binaries are critical to your operations.
Agree in writing which telemetry sources exist today, such as process creation, file creation and file modification logs, and which must be added.
Record the ATT&CK version the detections will target, so mappings stay accurate as technique pages change between releases.

How we build

Map detection logic for T1554 and its sub-techniques to open-source tooling such as Wazuh, Sigma rules, Zeek or Velociraptor, as scoped.
Configure file integrity monitoring and code signing verification checks on the binaries and platforms you agreed to cover.
Build a private cyber range replica of your hosts so detection logic can be tested against controlled, non-production binary changes.

How we hand over

Deliver detection documentation that explains each rule's data sources, expected alerts, known false positives and tuning notes.
Provide a range exercise report with the test scenarios run, the alerts observed, the gaps found and the remediation owner for each.
Hand over runbooks for triage and response to a suspected host software binary compromise, written for your own analysts.

How we support

Engagements are fixed-scope, so changes after handover are handled as written change requests with agreed deliverables.
Ongoing support, detection tuning and repeat range exercises are available as a retainer, scoped separately from the initial build.
Ask for a quote based on the written scope, including which platforms, telemetry sources and retention periods are covered.

T1554 Compromise host software binary