How T1525 implant internal image detection starts with your image pipeline
T1525 lets a persistent adversary plant a foothold inside an image that your cloud or container estate reuses, so the access returns whenever a new instance or container is launched from that image. In MITRE ATT&CK, the technique sits under the Persistence tactic (TA0003), which ATT&CK describes as the adversary trying to maintain its foothold. Technique IDs take the form T#### (here T1525), and this page targets Enterprise ATT&CK version 20.0. Golden images and base images are attractive because many workloads inherit from them, so one altered artifact can reach far more systems than a single compromised host.
For most platform teams, the first detection decision is not a rule in a SIEM but an inventory question: which images, templates and base layers are approved, who can publish them, and where they are stored. Start by mapping each image family to its build pipeline, its registry or image library, and the accounts and service principals allowed to create, modify or share it. Then confirm that every published image carries a traceable build record, such as a pipeline run identifier, a source commit and a checksum or digest that is recorded at publication time. Ask your cloud and container platform teams to confirm which of these records their platform keeps and for how long, because the answer determines what you can later compare against.
Once that baseline exists, you can judge a change against it. A modified image with no matching pipeline run, or an image shared with an unexpected account, is a signal worth investigating before any workload launches from it. Treat the baseline as a living control: review it after each ATT&CK release, since releases can rename or deprecate techniques and detection mappings should name the version they target. Record which ATT&CK version your image-pipeline detections were written against so the mapping stays auditable.
Which telemetry reveals implanted images and where it comes from
This table maps the three image-centric events for T1525 to where they originate and the open-source collectors that can gather them. The cloud control plane is usually the authoritative source for image and launch events, while host-side telemetry covers the build and capture steps before an image is recorded. ATT&CK v18 replaced data sources with data components, so confirm each mapping against the ATT&CK version your detection content targets.
| Telemetry | Where it originates | Open-source collection | ATT&CK data component to confirm |
|---|---|---|---|
| Image Modification | Cloud control plane audit records for changes to a machine image or template | Cloud audit log forwarding into Wazuh or a SIEM, with a parser for your provider | Application Log Content (DC0038), to confirm for your ATT&CK version |
| Instance Start | Control plane event recording a launch from a custom or unfamiliar image ID | Cloud audit log forwarding, with Wazuh rules correlating image ID to launch events | Application Log Content (DC0038), to confirm; event names vary by provider |
| Image Creation | Control plane event recording a new image or snapshot taken from a running instance | Cloud audit log forwarding, plus Velociraptor on the source instance for host-side artifacts | Application Log Content (DC0038), to confirm for the source platform |
| File changes on build or source hosts | File creation and modification in build directories or on an instance before capture | Wazuh file integrity monitoring and Velociraptor file collection | File Modification (DC0061) and File Creation (DC0039) |
| Process and command activity | Process launches and commands run during image build, configuration or capture | Wazuh and auditd on Linux hosts, Velociraptor for live process records | Process Creation (DC0032) and Command Execution (DC0064) |
| Network-side visibility | Traffic from build hosts to cloud APIs or image registries | Zeek or Suricata on mirrored egress, limited where API traffic is encrypted | Confirm whether a network component applies to T1525 in your ATT&CK version |
Detection logic for implanted image changes
T1525 Implant Internal Image is hard to see in runtime telemetry because the malicious change happens before a workload starts. The detections below work upstream, at image creation, promotion and launch, and they connect because each compares what is running or published against an approved build record. Tune every threshold against your own pipeline, since scheduled patching and legitimate rebuilds generate most of the noise.
Image lineage drift from baseline
Compare each image's layer history, base image reference and installed package manifest against the approved baseline for its image family. The logic flags any image whose lineage no longer traces to a known base digest or whose layer count and added files change without a matching change ticket. Tune the alert on which layers are allowed to differ, such as the application layer, and ignore differences in build timestamps. False positives come from scheduled base image refreshes and security patch rebuilds, so route those through an approved baseline update rather than suppressing the alert. Check first whether the drift includes new entrypoints or startup scripts.
Image creation outside the pipeline identity
Alert when an image is pushed or registered by any identity other than the build pipeline's service principal, or when a build runs outside the approved CI runner. This is the signal most likely to catch an implant inserted by a person or tool that bypassed the pipeline. Scope the rule to the image registry and the IaaS image service, and record the calling identity, source address and time. Expected noise comes from break-glass rebuilds and platform team tests, so require those to carry a ticket reference that the rule can match. Confirm which audit events your registry and cloud provider emit for image creation before relying on this logic.
Instance starts from unapproved images
Correlate every instance or container start with the approved build record for the image digest it uses. The detection raises an alert when a workload starts from an image that has no build record, has an unapproved signature or was created outside the pipeline window. Thresholds to tune include the grace period between image publication and first approved use, and which environments are in scope, since development sandboxes may legitimately run unreviewed images. False positives often come from emergency hotfix images and from restores of older backups. Ask the cloud or platform team which start events carry the image identifier, because some services only log the image name.
Digest changes after promotion
Once an image is promoted to a production tag, its digest should never change. Alert when a production tag resolves to a different digest than the one recorded at promotion, or when a tag is re-pushed with a new digest. This catches modification of an image after review, which is the core of T1525 Implant Internal Image. Tune the rule so that it compares digests, not tag names, and exempt only tags that a documented rebuild process updates. Common false positives are routine patch cycles that re-tag images without a new approval, which should be treated as a finding in their own right until the process is documented.
How to confirm the detection fires before you trust it
This sequence proves that a T1525 detection fires on a controlled image change, with the expected telemetry, alert and timing recorded. It turns a rule that looks correct on paper into evidence the team can defend to auditors and leadership.
Define the test image change and its scope
The detection owner writes down one controlled change to a private test image in the cyber range, such as a modification to a golden image or a new image registered from a test instance. The change is limited to a non-production account and a named image ID so that no production image is touched. The step is done when the change is written as a short test card with the target platform, account, image identifier and the person who will approve the run.
Write the expected telemetry and alert before the run
Before anything runs, the team records which events should appear for the change, drawn from the Image Modification, Image Creation and Instance Start telemetry on the platform. The expected alert, its severity and the routing target are written next to them. Writing these first keeps the team from fitting the result to the rule afterward. The step is done when the test card lists each expected event type, its source log and the alert name.
Set the observation window and record the start time
The team agrees on an observation window that runs from the moment the test change is made until the alert should have reached the analyst queue, and records the clock source used for it. Clocks on the cloud control plane, the log pipeline and the SIEM or Wazuh manager can differ, so the reference source is named in the test card. The step is done when the window start, the reference clock and the owner of the time check are on record.
Execute the controlled change under observation
A tester who is not the rule author performs the approved image change in the range while a second engineer watches the log pipeline. The executor stops after the change and does not run follow-on activity beyond the test card. The step is done when the change is complete, the time it happened is noted, and both people have confirmed the test was made on the agreed image only.
Record event IDs, pipeline identities and detection latency
Using the window, the team captures the raw event identifiers, the cloud or platform identity that made the change, the service or pipeline identity that made the change if one was used, and the time the event was ingested and the time the alert fired. Latency is the gap between the change and the alert, and it is compared with the target agreed in the test card. Any mismatch between the event actor and the expected identity is flagged for review. The step is done when a results sheet holds these fields for every expected event.
Confirm the rule targets the intended ATT&CK version
The rule author checks the rule metadata against the ATT&CK version the detection was written for, and confirms that the technique ID, sub-technique and data component references still match the current ATT&CK release on the MITRE updates pages. ATT&CK releases can rename, deprecate or revoke techniques, so a rule mapped to an older version may need a mapping update. The step is done when the rule metadata names the target version and the reviewer has signed off that the mapping is current.
Compare results with the test card and decide
The reviewer compares the recorded events, identities, alert name and latency with the expected values written in the test card. Each gap is classified as a rule defect, a log source gap, a pipeline delay or a test card error, and assigned an owner. The rule is only treated as validated when all expected events are present and the alert fired inside the agreed window. The step is done when the signed test record is stored with the rule so the result can be repeated on the next ATT&CK version.
How image persistence fits into the Persistence tactic
The Persistence tactic, TA0003, exists because an adversary who loses a foothold has to be able to get it back, and ATT&CK defines the goal as trying to maintain that foothold. For T1525 Implant internal image, the practical consequence is that the foothold lives in the platform's own build inputs rather than on a running host. Read this way, the tactic definition tells a detection program what to protect: not only live systems, but the templates, machine images and container images from which new systems are created. A program that monitors running workloads and their logins but ignores the image catalog and its change history leaves this persistence path unwatched.
Set against its siblings in this group, T1525 behaves differently from most of them. T1098 Account manipulation and T1136 Create account persist through identities, so a reviewer checks accounts, role grants and key material. T1543 Create or modify system process and T1547 Boot or logon autostart execution persist through services and startup paths on a single system. T1525 persists through the artifact that produces systems. Those techniques share a common control set, including Privileged Account Management and Audit, so the same owners and logging pipelines can cover them together. The image-specific gap is that an image change may not trigger any of the identity or process alerts that the sibling techniques depend on, which is why image-level telemetry needs its own review.
An implanted image survives instance rebuilds because the rebuild process itself reproduces the change. If a team terminates a compromised instance and launches a new one from the same image, the new instance starts from the same content and the foothold returns. Incident responders should therefore ask a specific question early: which image, template or container base was used to create the affected systems, and when was it last modified? Confirm with your cloud or platform provider how image version history, sharing permissions and launch records are retained in your environment, and confirm that the retention window covers the period you need to investigate. Rebuilding without reviewing the source image can restore the adversary's access, so image provenance belongs in every recovery checklist.
Preventive controls that limit image tampering
T1525 works when an attacker can change a machine image or template that new workloads later boot from. The controls below reduce who can make those changes, make changes visible, and make unauthorized images harder to run, so that detection has a narrow, well-logged set of events to watch.
Audit image and template changes
Audit (M1047) means your platform records who creates, modifies, shares and launches images, snapshots and templates, and keeps those records somewhere the image administrators cannot edit. For T1525, the useful records are image creation, image modification and instance start events from your cloud control plane or hypervisor. Confirm in your own environment that these events are enabled in every account and region, that they are forwarded to your SIEM, and that alerts fire on changes made outside the build pipeline. Test this by making an approved change and checking that the event arrives.
Limit privileged image administrators
Privileged Account Management (M1026) restricts and monitors the accounts that can change images, launch templates and image sharing settings. In image pipelines this usually means separating the people who build images from the people who approve and publish them, using just-in-time elevation for administrative roles, and reviewing standing access on a fixed schedule. Ask your team which identities can publish an image to a shared catalog and whether any of them are long-lived service credentials with no owner.
Restrict write access to image stores
Restrict File and Directory Permissions (M1022) applies when image artifacts live on file systems, network shares or object storage that a build host or hypervisor reads from. Write access should belong only to the build service, and read access should be limited to the systems that consume the images. Check whether build directories, golden image repositories and template folders inherit broad permissions from a parent path, since an inherited write right is a common gap.
Require signed image provenance
Code Signing (M1045) lets consumers verify that an image or artifact came from an approved build and has not been altered since. Signing the image digest or the build attestation, and having the deployment pipeline reject unsigned or mismatched images, turns a silent swap into a failed deployment. Confirm which signing keys exist, who can use them, where they are stored, and whether revocation is tested. Signing is only as strong as the key custody behind it.
Gate images through a reviewed pipeline
Image changes should enter through one versioned build pipeline with peer review before publication, so that an unexpected change is visible as a diff against a known baseline. This is a process control that draws on the audit and privileged access controls above. Ask whether your pipeline records the base image version, package list and build inputs for each release, and whether a rebuild from the same inputs reproduces the same artifact.
What to do when an image change alert fires
When an image change alert fires for T1525 Implant internal image, the first decision is whether the change came from an approved pipeline run. Compare the modified image digest and build provenance against the record of your image build system and registry, and check whether a scheduled or authorized build matches the timestamp. If no approved run explains the change, treat the image as suspect and freeze promotion immediately so that no new instances or containers are launched from it while the investigation is open. Then identify every running instance, autoscaling group, node pool and container workload that was started from that image or from any tag that now points to it. Confirm the scope with the people who own those workloads, because a stale tag or a shared base layer can extend the blast radius beyond the image you first looked at.
Preserve evidence before anything is rebuilt or deleted. Keep the original image manifest, layer list, registry audit entries, image creation and modification events, and the logs from the instances that started from the suspect image. Record who held the privileges to push, tag or modify images during the window, and review those privileged identities and their recent sessions, including service accounts used by build tooling. Store copies in write-protected storage with hashes recorded at collection time, and document each handoff in a chain of custody record. Escalate to the incident response lead, the cloud or platform owner and, where regulated data may be exposed, legal and privacy contacts. Agree the severity and notification thresholds in your incident response plan before the first alert fires, not during it.
Rebuild from a known-good source rather than repairing the suspect image in place. Pin the base image to a digest you have verified from your own registry or an upstream source you trust, rebuild through the controlled pipeline, and redeploy with the new digest. Confirm which open-source tooling in your stack, such as your image scanner or admission controller, is set to block unsigned or unexpected digests, and confirm that its rules are what you intend. Before closing the incident, validate that the detection itself fired on the change and that the alert reached the responders, and record the outcome against the ATT&CK version your detection mapping targets. Ask your platform team to confirm the exact recovery steps for your cloud provider or orchestrator, since these vary by platform.
How to rehearse T1525 detection in a private cyber range
In the IaaS tab, the range mirrors a small cloud account with an image pipeline, an instance group that launches from approved machine images, and a logging path into the SIEM. Use a non-production account whose audit logging, retention and forwarding match production as closely as your platform allows. Exercise injects are illustrative: an approved machine image is altered and re-registered under its original name, then an instance launches from it outside the change window. The blue team must connect the image modification, the image creation and the instance start, and open an incident before the altered image spreads.
- Range setup: Forward the provider's native audit events to Wazuh or Security Onion, and confirm that image lifecycle events arrive with the identity, source address and image identifier.
- Inject design: Script one unapproved image change and one instance start from that image, and document both in the range runbook so the platform team knows they are expected.
- Good detection: A correlated rule fires on the image change and the launch within a defined window, and the alert names the image, the launching identity and the affected instance group.
- Good response: The SOC declares an incident, the platform team freezes the image pipeline, and affected instances are isolated while their disks and image metadata are preserved for review.
- Handoffs: Agree in advance who may terminate instances, and set the escalation time from SOC to platform team in the runbook before the exercise starts.
Before closing the exercise, confirm the alert reached the on-call queue, the image lineage was recorded, and the rollback to the approved image was tested end to end.
In the container tab, the range includes a private registry, a build pipeline that pushes approved images, and a small orchestrated cluster that pulls from the registry on deployment. The most useful inject is a rebuilt base image pushed under an existing tag, so that workloads which reference the tag pull changed content without any change request. Keep the registry audit log, the cluster admission events and the node-level pull records in scope, because the detection depends on connecting them. Injects should be recorded in the runbook with their intended outcome.
- Range setup: Enable registry audit logging, including push and tag events, and forward it to the SIEM alongside cluster audit events so both sources share a time base.
- Inject design: Rebuild a base image, push it over an approved tag, then roll a deployment that references that tag so the change reaches a running workload.
- Good detection: The analyst sees a push to a tag already in use, a digest change that no pipeline run explains, and a deployment rollout that pulled the new digest, all within one case.
- Good response: The platform team pins the workload to the last known digest, blocks the rogue push at the registry, and records which clusters pulled the altered image.
- Handoffs: Assign one owner for registry permissions, since the Privileged Account Management mitigation depends on who can push and retag, and confirm that owner can act during the exercise.
Check that the digest history for the affected tag can be reconstructed from logs and that every cluster which pulled the image appears in the case record.
The scoring tab explains how to turn the rehearsal into evidence that a control worked. Score each inject against the expected alert, the expected containment step and the expected record, and keep the scoring sheet separate from the runbook so that the blue team cannot tune the answers after the fact. Map each detection to the ATT&CK version you target, and name that version in the detection record. Sigma rules, Velociraptor collections and case notes should all reference the same exercise identifier. Timing targets should be agreed before the exercise and written down, not inferred from the outcome.
- Expected outcomes: For each inject, record the alert that should fire, the owner who should receive it and the containment action that should follow.
- Timing targets: Set detection and containment targets in advance, and measure them from the first logged event rather than from when an analyst opened the case.
- Version mapping: Tag each detection with the ATT&CK version it targets, using the enterprise-attack 20.0 bundle as the reference, and note any sub-technique changes.
- Evidence capture: Preserve the raw events, the case timeline, the rule version and the change record so that an assessor can trace each claim.
- Gap register: Log every missed alert or slow handoff as a finding with an owner and a retest date.
Before sign-off, confirm that the scoring sheet, the case records and the gap register all reference the same exercise identifier and that each open gap has a retest scheduled.
Questions SOC leads ask about T1525 detection
How do we separate a legitimate image rebuild from tampering?
Compare the change against an approved build record, not against the image itself. A legitimate rebuild normally comes from a pipeline run with a known commit, an authorized principal and a sanctioned build account, and it produces a new image identifier that is registered in your image catalog. Tampering tends to show a modified image with no matching pipeline run, a principal outside the build team, or a change made directly to a running or stored image. Build a baseline of who may create, modify and launch images, then alert on exceptions. Confirm the exact event names and fields your cloud provider records for image changes before writing rules, because they differ between platforms.
Are image digests enough evidence that an image was not implanted?
No. A digest proves that an image matches a specific byte sequence, which is useful for detecting drift from a known good artifact, but it does not prove the artifact was clean when it was built. If the build pipeline itself was compromised, the digest will faithfully record a malicious image. Pair digests with signed provenance, verified signatures at deployment time, and records showing which pipeline and approver produced each digest. Treat digest mismatches between the registry and running instances as high-priority signals, and document how you verify the chain for auditors.
What should we do with images that were never registered?
Treat an unregistered image as an unexplained asset until its origin is established. Start by identifying the instances, containers or launch templates that reference it, then check the creating principal, the creation time and any related activity in your audit logs. If no legitimate owner can account for it, isolate affected workloads according to your incident response plan and preserve the image and its metadata before deleting anything. Some unregistered images come from manual experimentation or vendor tooling, so the response should confirm ownership first and escalate only when ownership cannot be shown.
How do ATT&CK version changes affect our T1525 detection mappings?
Each ATT&CK release can rename, deprecate or revoke techniques and update data components, so a mapping written against one version may need review after the next. ATT&CK v18 replaced detections on technique pages with detection strategies and analytics and deprecated some data sources, which means older rule documentation may point to retired references. Record the ATT&CK version each detection targets, review mappings when a new version is published, and use the STIX bundles in the official repository to check for changes to T1525 and its mitigations. Confirm the current status of the technique in the release you target.
Which logs should we retain to investigate image implantation?
Retain the cloud or platform audit trail for image creation, modification, sharing, deletion and instance launch, because these events show who changed what and when. Keep registry logs for pushes, pulls and tag changes, and retain build pipeline logs that tie each artifact to a commit and approver. Add instance start records and configuration history for the workloads that launched the image. Set retention to cover your investigation and audit windows, and confirm with your compliance owner how long each source must be kept. Ship these logs to a store that the workload administrators cannot edit.
Can our own team run T1525 detection and response without outside help?
Many teams can, provided they already operate centralized logging, image registries with access control, and a tested incident process. The harder parts are building a trusted baseline of image activity, tuning alerts against normal rebuild traffic, and rehearsing the response across cloud, platform and security teams. DeployOpen implements and integrates open-source platforms inside your own infrastructure and runs cyber range exercises, so an engagement can focus on the detection and response gaps you identify. Scope and deliverables are agreed in writing before work starts, and the quote follows from that scope.
What drives the cost of building this detection?
The main drivers are the number of cloud accounts, registries and image pipelines in scope, how much logging already exists, and how many rebuild patterns you must baseline before alerts become reliable. One-time work includes mapping events to detections, building the baseline and rehearsing response in a cyber range. Recurring work includes tuning alerts, reviewing mappings against new ATT&CK versions and retaining logs. Ask for a quote that separates these items and states which systems and retention periods it covers.
How DeployOpen builds T1525 detections and range scenarios
DeployOpen starts every T1525 engagement by mapping the organization's own image pipelines before writing a single rule. The useful question is which build systems, registries, golden image catalogs and cloud accounts can create, modify or launch machine images and container images, and who is allowed to do each of those actions. For IaaS, that means listing the image creation and sharing paths in each account and the roles that hold them. For containers, it means identifying which registries accept pushes from which pipelines and which clusters pull from them. The output is a written inventory of trusted image sources, the expected change windows for each, and the owner who approves an image change. Without that baseline, a modified image looks like any other image event and the alert queue fills with noise.
Collection is then built around the telemetry named for this technique: image modification, image creation and instance start events from the cloud control plane, plus registry push and pull logs for containers. DeployOpen maps these sources into the organization's existing Wazuh or Security Onion pipeline where the platform supports them, and records which fields are available in each environment, since field coverage varies by provider and log configuration. Detection logic is written as Sigma rules tied to the ATT&CK version in use. Each rule compares a change event against the approved baseline, such as an image created outside the build pipeline's service identity or a launch from an image that was never published through review. Rules are tuned in a test tenant before they reach production, and every rule records the ATT&CK version it targets so it can be re-checked after future releases.
Validation is where DeployOpen tests whether the rules fire. In a purple team exercise, the client's responders and DeployOpen's testers agree on a set of image-change scenarios in advance, run them against a non-production account, and record which events were logged, which rules matched and how long the alert took to reach an analyst. Those scenarios are then rehearsed in a private cyber range, so that the same triage and rollback steps can be practiced without touching live images. Deliverables are fixed in writing before work starts, usually including the baseline inventory, the rule set with test evidence, the exercise report and a list of open gaps. Ask any provider to confirm the exact deliverables, timelines and the access they need to your cloud accounts. DeployOpen does not issue audit reports or certifications. Where compliance evidence is needed, independent auditors or certification bodies make that determination.
