How T1553 Subvert trust controls undermines detection on Linux, macOS and Windows
A SOC lead's alerts are only as useful as the trust decisions beneath them. T1553 Subvert trust controls lets an adversary weaken the mechanisms that tell a system what to trust, such as code signing, certificate validation and security tooling, so that malicious activity can pass as legitimate. In MITRE ATT&CK, this falls under the Defense Impairment tactic (TA0112), which describes adversaries breaking security mechanisms, pipelines and tooling so defenders cannot see or trust what is happening. The technique appears in the Enterprise matrix in ATT&CK version 20.0, so mappings in your detection content should name that version explicitly. In intrusions, T1553 usually matters less as a standalone event and more as a reason a later event looks benign. An operator who changes what a host accepts as trusted may then run tooling whose signatures, certificates or provenance no longer raise concern, and the alert that would have fired never does. The six sub-techniques cover different trust surfaces across Linux, macOS and Windows, so a single control check will not cover them all. Treat any change to trust configuration as a security event in its own right, and ask your team which trust stores, signing policies and endpoint protection settings are monitored today.
Practically, the first decision is scope: which trust controls on your estate are important enough to baseline and alert on when they change. Confirm with your endpoint and platform teams where each trust decision is recorded, and whether those records are retained long enough to reconstruct a timeline. Then confirm that the sub-techniques map to telemetry you already collect, such as process and command execution logs, file changes and registry changes on Windows, rather than assuming coverage. The MITRE ATT&CK technique knowledge base is the natural starting point for reviewing the sub-technique list against your environment before you write any detection.
Which telemetry reveals subverted trust controls
This table maps the five telemetry sources most useful for T1553 Subvert Trust Controls to the signal each one carries, the open-source collector that gathers it, and the ATT&CK v18 or later caveats to check. Read it as a coverage checklist: a source only helps if your environment actually collects it for the platform in question.
| Telemetry source | Signal for T1553 and sub-techniques | Open-source collection approach |
|---|---|---|
| Command Execution | Shell or tool invocations that install, remove or modify certificates, trust stores or code signing settings on Linux and macOS hosts | Wazuh agent log collection and auditd rules on Linux; confirm command capture depth for your distribution |
| Process Creation | Processes that call trust-store, signing or certificate utilities, or that run with unexpected parents during trust configuration changes | Sysmon-style Windows logging forwarded to Wazuh or Security Onion; auditd execve records on Linux and macOS where supported |
| File Modification | Changes to system certificate bundles, trust anchors, keychains or signing configuration files that alter what a host accepts as trusted | Wazuh syscheck (FIM) on defined trust paths; auditd file watches on Linux; confirm paths against your own OS baseline |
| Windows Registry Key Modification | Writes to registry locations that govern trusted root or publisher stores, certificate trust settings and code integrity behavior on Windows | Sysmon registry events forwarded to Wazuh; Wazuh Windows event collection; scope keys to the trust-related hives you have approved |
| Network Traffic Content | Certificate exchanges and TLS handshakes showing unexpected issuers, weakened trust validation or certificates presented to hosts that should not see them | Zeek SSL and X.509 logs or Suricata TLS metadata sent to Security Onion; confirm inspection coverage for encrypted and pinned traffic |
Detection logic for T1553 that SOC teams can tune
T1553 Subvert Trust Controls covers adversaries weakening the mechanisms that tell a system what to trust, such as certificate stores, code signing and package integrity. The cards below describe detection ideas in words, with the thresholds and benign sources your analysts should tune before alerting.
Windows trust store changes
Watch for process creation and registry writes that alter trusted root or publisher stores, since these changes often precede trust abuse. Tune by allowlisting the signed Windows Update, Group Policy and enterprise certificate deployment agents, and by alerting on any change made by an unsigned or user-writable binary. Confirm with your MDM or configuration management team which change windows they use, so scheduled certificate rollouts do not flood the queue. Write the rule in Sigma and name the ATT&CK version it targets.
Code signing validation failures
Look for executables or scripts that launch after a signature check fails, or after a signing certificate is replaced or marked untrusted. On Windows and macOS, correlate command execution events with the validation outcome recorded by the endpoint. Common false positives include developer builds, unsigned internal tools and software updaters that briefly re-sign binaries. Tune with an approved list of internal publishers and a short grace period after known update events, and confirm the thresholds in a cyber range before production.
Linux trusted repository tampering
On Linux, focus on file modifications to CA bundle directories, package repository definitions and GPG keyrings, followed by package manager invocations that accept the new trust material. Treat a repository key change outside a configuration management run as higher risk. Expected noise comes from configuration management agents, container image builds and distribution upgrades, so keep a maintained list of those parent processes and their change windows. Alert on modifications that are not paired with a ticket or pipeline run.
macOS keychain and profile trust edits
On macOS, monitor command execution that modifies trust settings for certificates or installs configuration profiles that add trusted roots. Legitimate sources include MDM enrollment, managed software installers and endpoint security agents, which often perform these changes with system privileges. Separate MDM-originated events from user-initiated ones by checking the parent process and the enrollment state. Ask your MDM vendor which events are logged locally and which only appear in the MDM console.
Privileged change correlation
A trust change made by an account that does not normally administer certificates is more useful as a signal than the change alone. Correlate trust-related events with privileged logons, recent group membership changes and off-hours activity. Tune the rule by listing the service accounts used by MDM, Group Policy and endpoint security tooling, and review that list when those tools change. This approach relies on the Privileged Account Management and Audit controls being in place, so check that privileged logs are retained.
How to validate a T1553 detection before you trust it
This sequence shows whether a T1553 detection fires on the systems that matter, with the expected alerts, the actual alerts and the time to alert written down. It ends with a documented list of gaps and a retest, so the detection is trusted on evidence rather than assumption.
Scope the emulation with the asset owner
The detection engineer and the owner of each test system agree in writing which hosts, operating systems and user accounts are in scope, which sub-technique families will be exercised, and which change windows apply. The owner also confirms how the range is isolated from production and who can stop the exercise. The step is done when the signed scope lists every system, the telemetry sources expected to record activity, and a named contact for stopping the test.
Select benign emulation tooling and test assets
The team chooses emulation tooling that produces harmless, documented artifacts and that the owner has approved for use in the range. Test assets are built from images that match production baselines for Linux, macOS and Windows, where those platforms are in scope. Nothing is run against production. The step is complete when each tool choice is recorded with its version, its intended effect and the assets it will touch, and when the team can rebuild the test assets from a known state.
Write expected alerts for each test
Before any test runs, the team writes down what each detection should produce, in plain terms: which data components should record the activity (such as Process Creation, Command Execution or Windows Registry Key Modification), which rule or analytic should fire, and what severity and fields the alert should carry. Each expectation is tied to the ATT&CK version the detection targets. The step is done when every planned test has a written expected outcome that a reviewer can check against the results.
Run each sub-technique family in the range
The team runs the benign emulation for each sub-technique family in the agreed scope, one family at a time, with a log of start and end times and the operator performing each action. Analysts stay on the monitoring console and do not tune rules during the run. The step is complete when every planned family has a timestamped run record and the range snapshot is preserved for later comparison. Confirm the sub-technique list against the ATT&CK version you target, since releases can rename or deprecate entries.
Record expected and actual alerts side by side
For each test, the reviewer compares the written expectation with what the SIEM or Wazuh alert queue actually shows. Each row records whether an alert fired, which rule produced it, which fields were populated and whether the alert named the correct host and account. Partial matches are recorded as partial, with the reason. The step produces a single results table that anyone on the review panel can reproduce from the stored logs.
Measure time to alert for each test
The team calculates the interval between the recorded start of each test action and the first matching alert timestamp, using clock-synchronized sources across the range. Where an alert never fired, the field is marked as none rather than left blank. Results are grouped by data source so that slow log forwarding is separated from slow rule logic. The step is done when every test has a time-to-alert value or a documented absence, with the clock source named.
Document gaps and decide on fixes
The review panel lists each missed or weak detection, the telemetry gap behind it (for example, a missing audit policy or an unforwarded log source) and the owner of the fix. Each gap gets a decision: tune the rule, add a data source, accept the risk in writing, or retire the test. The step is complete when every gap has a named owner, a decision and a retest requirement, signed off by the asset owner.
Retest and freeze the validation evidence
After fixes are applied, the team reruns the affected tests against the same range baseline and compares the new results with the original table. The final evidence pack contains the scope, tool records, expected and actual alerts, time-to-alert measurements, gap decisions and retest results. The step is complete when the pack is stored under change control and the detection owner states in writing which sub-techniques are trusted and which remain on the gap list.
Why trust-control tampering is hard to see in logs
Trust-control tampering is hard to see because it targets the systems that would normally record it. MITRE's Defense Impairment tactic describes adversaries trying to break security mechanisms, pipelines and tooling so defenders cannot see or trust what is happening. Treat a missing event as a signal in its own right. Detection engineers should expect three symptoms: events that never arrive, events that arrive after the activity they describe, and events that contradict each other across sources. A quiet agent or a sensor that stopped forwarding is not evidence of calm, so alerts on silence must sit beside alerts on activity. Confirm which hosts should emit telemetry at all, and document the expected reporting cadence for each source.
Correlation is the practical answer, because any single source can be degraded. The detection logic should join process creation, command execution, file modification, Windows registry key modification and network traffic content on host, user and time, using the data components DC0032, DC0064, DC0061, DC0063 and DC0085 as the reference set. Contradictions are often the most useful evidence: a command execution record with no matching process creation, a file change on a host whose process telemetry is missing, or a network sensor that sees traffic no endpoint reports. As an illustrative example, a Linux host may record a command that no endpoint process record mentions, and that mismatch should open an investigation before anyone trusts either source. Build a coverage table per host class that shows which of these components each host provides, and treat every empty cell as a known blind spot.
The six sub-techniques differ by platform, so the detection set should be split the same way. Windows logic typically draws on registry and process data, while Linux and macOS logic leans more on command execution and file changes, and each platform needs its own check that the sources it depends on are enabled. Ask your platform team which audit configuration, agent version and log forwarding path each host class uses, and record those answers in the test notes for each detection. Pair these checks with the ATT&CK mitigations Software Configuration (M1054), Privileged Account Management (M1026) and Audit (M1047), which reduce how easily trust controls can be changed and make changes easier to notice.
Mitigations that reduce T1553 exposure
T1553 Subvert Trust Controls works by changing the mechanisms that decide which software, certificates and security settings a system trusts. Two ATT&CK mitigations address that exposure directly: restricting who holds privileged rights and controlling how software is configured. The cards below describe each control, who should own it and the evidence an assessor would expect to see.
Privileged Account Management (M1026)
Privileged Account Management limits who can change trust settings, including certificate stores, code signing policy, security tooling configuration and security modules that load at boot. Privileged rights should sit with named accounts that are separate from everyday user accounts, be granted through approval, and be reviewed on a schedule. Confirm that changes to trust stores and security configuration can only be made by named privileged roles. Also check for local administrator rights that exist outside the central directory, since these are often missed in reviews.
Privileged Account Management evidence
The owner is usually the identity and access team, with security governance approving the privileged role model. An assessor will look for a current register of privileged accounts and groups, approval records for each grant, and periodic review sign-offs that show removed access. Logs of privileged logons and of changes to trust stores should be retained and sampled to confirm that the register matches what happened on the systems. A register that does not match the logs is a finding in itself. Ask the platform team which accounts they believe hold these rights and compare the answer with the directory export.
Software Configuration (M1054)
Software Configuration covers setting security-relevant options in software so that users and local processes cannot quietly weaken trust controls. Typical examples include enforcing signature and integrity checks, locking the settings of endpoint protection and logging agents, and controlling which certificate authorities and extensions are accepted, where the product supports these options. Confirm which settings are enforced centrally, which can be overridden locally, and which exceptions have been approved in writing.
Software Configuration owners and evidence
Platform engineering usually owns the configuration baselines, with security approving the required settings and the exception process. Evidence should include baselines kept under version control with change approvals, reports showing configuration drift on managed hosts, results from configuration management runs, and a dated register of exceptions with an owner and expiry for each one. Drift reports are the most useful artifact, because they show whether the baseline is enforced in practice and not only documented.
Check mappings against the ATT&CK version
Mitigation mappings change between releases, and ATT&CK can rename, deprecate or revoke techniques, so each control mapping should record the ATT&CK version it was checked against. The Enterprise content referenced on this page is version 20.0. Before reporting coverage, reconcile each mitigation against the version your assessor uses, and note any mapping that changed. Keep the release notes with your evidence so the mapping can be traced later.
What the SOC does when a T1553 detection fires
The sequence moves a T1553 alert from first look to a documented decision on containment, evidence and trust in earlier alerts from the same host or identity. Each step ends with an output the next step depends on.
Confirm the alert against raw telemetry
The on-duty analyst opens the alert and pulls the underlying events from the source system, not only the rule summary. For a T1553 sub-technique, that means the process creation or command execution record, the file modification or registry change that triggered the rule, and the user and parent process context. The analyst records whether the activity matches the detection logic and whether a benign explanation exists, such as a documented change ticket or a package update. The step closes with a written verdict of confirmed, benign or inconclusive, with the event identifiers attached to the case.
Check changes to trust configuration
Next, the analyst compares the current state of trust controls on the affected host or tenant with a known-good baseline. On Linux and macOS this usually covers certificate stores, package signing keys and trust settings files. On Windows it covers certificate stores, trusted root and publisher entries, and related registry keys. The analyst also checks whether the same change appears on other hosts through configuration management or endpoint inventory. The step closes with a list of trust settings that changed, when they changed, and which account made the change.
Isolate the affected host or identity
If the verdict is confirmed or the trust change cannot be explained, the incident lead decides on containment. Options include network isolation of the host through the endpoint platform, disabling or suspending the account, and revoking active sessions and tokens. Containment should be scoped so that business-critical systems are handled through a documented change process with the system owner. The step closes when containment actions are logged with the time, the approver and the scope, and the analyst confirms that the isolation took effect.
Preserve evidence before remediation
Before anyone removes a certificate, reverts a setting or reimages a machine, the team collects volatile and persistent evidence. This typically includes a memory capture where the platform allows it, copies of the modified trust stores and configuration files, relevant logs from the endpoint and identity provider, and hashes of collected artifacts. Chain of custody is recorded in the case file. The step closes when the evidence set is stored in a location with restricted access and its integrity has been verified against the recorded hashes.
Decide whether prior alerts are trustworthy
The team reviews alerts and logs from the same host or identity dated before the trust change was detected. The question is whether an attacker with the ability to alter trust controls could also have altered the telemetry pipeline, the agent, or the audit configuration. If the agent was tampered with, or log forwarding stopped or changed, earlier silence cannot be read as clean. The analyst classifies prior telemetry as trusted, partially trusted or untrusted, and documents the reasoning. The step closes with a decision on whether earlier investigations or closed alerts need to be reopened.
Eradicate and recover with verified trust
Eradication removes the unauthorized trust entries, reverts the configuration to the approved baseline and rotates any credentials or keys that may have been exposed. Recovery restores the host or identity only after the baseline comparison is clean and monitoring for the affected data sources is confirmed working. Where the integrity of the host cannot be established, the team rebuilds it from a known-good image instead. The step closes when the analyst records the restored baseline, the rotated secrets and the date monitoring was verified.
Document the outcome and tune detections
The incident record is completed with the timeline, the root cause as far as it is known, the control gaps and the decision on prior alerts. The detection engineer reviews whether the rule fired on the right telemetry, whether false positives or missed variants were seen, and whether the mitigation owners need to act on privileged account management or software configuration findings. Any rule change is versioned against the ATT&CK release it targets. The step closes with a reviewed case record and, where needed, a tracked change to the detection content.
Rehearsing T1553 detection in a private cyber range
The Windows range is an isolated Active Directory domain with a domain controller, one or two workstations joined to it, and a Wazuh manager receiving events from Sysmon-instrumented agents. Keep the network segment separate from production, with no routed path out, and snapshot each host before every exercise so the team can reset between runs.
- Range topology: one domain controller, two Windows workstations, a Wazuh manager and a log path that carries Windows event data into the manager.
- Benign injects: illustrative exercises include adding a lab-only test certificate to a workstation trust store and opening a file downloaded from a lab web server to observe Mark-of-the-Web handling.
- Detection signals: look for Process Creation events for certificate utilities and Windows Registry Key Modification events on trust store keys, and check that a Sigma rule covering the Root store fires on the expected change.
- Response checks: the analyst should confirm the change matches the inject, compare the certificate thumbprint with the exercise record, and remove the test certificate from the store.
- Scoring: record time to alert and whether the runbook was followed, not only whether an alert appeared.
Confirm that the injects match your own software distribution and trust policies before treating any result as a measure of your detection.
The Linux range uses a small set of hosts with auditd enabled, a Wazuh agent on each host, and a Zeek sensor on the lab segment to observe outbound fetches. The topology should include one host that mirrors your standard server build and one that acts as a lab package mirror, so the team can exercise both local trust stores and repository signing.
- Range topology: two or three Linux hosts from your standard image, a lab package mirror, a Wazuh manager and a Zeek sensor on the lab segment.
- Benign injects: illustrative exercises include adding a lab certificate authority to the system trust bundle on a test host and changing the signing key configuration for the lab package mirror.
- Detection signals: use Wazuh file integrity monitoring on certificate directories and package manager configuration, auditd records of commands that alter trust, and Command Execution telemetry to tie changes to a user session.
- Response checks: the responder should identify the account and session, restore the trust bundle from the known-good baseline, and confirm the package mirror is back on its approved keys.
- Evidence: keep the auditd output and file integrity records together so the exercise shows how the timeline was reconstructed.
Check that your file paths and package managers match the distributions you run in production, because the detection logic depends on them.
The macOS range uses managed test endpoints enrolled in a lab device management service, with a Wazuh agent or another endpoint collector that your team has validated on the chosen macOS version. Keep the endpoints unmanaged from production identity systems and reset them from a clean image between exercises.
- Range topology: two or three managed macOS endpoints, a lab device management service, a log collector and a Wazuh manager, all on an isolated segment.
- Benign injects: illustrative exercises include installing a lab-only configuration profile that changes a trust setting and launching a lab-signed test application to observe Gatekeeper prompts.
- Detection signals: look for Process Creation and Command Execution events for the tools that install profiles or change trust, and File Modification events on the system keychain and profile locations.
- Response checks: the responder should confirm the profile identifier, remove the test profile through the device management service, and verify the trust settings return to the baseline.
- Coverage gaps: confirm with your vendor and collector documentation which macOS events are available to your agent, because coverage differs across versions.
Verify the inject list against the macOS versions and management tools you actually run before relying on the results.
Questions SOC leads ask about T1553 detection
How should we handle noisy baselines when detecting trust control changes?
Start by separating expected trust changes, such as certificate renewals, endpoint management pushes and approved root store updates, from unexpected ones. Build an allowlist from change tickets and configuration management records, then review the top sources of alerts each week. Tune by narrowing the match to the specific file, key or process involved rather than muting whole data components, and record every suppression with an owner and a review date.
Which MITRE ATT&CK version should our detection mappings target?
Pin every detection to one named ATT&CK version and record it in the rule metadata, because releases can rename, deprecate or revoke techniques. Note that ATT&CK v19, released April 28, 2026, created the Defense Impairment tactic (TA0112) by splitting it from Defense Evasion, so mappings written against older versions may list T1553 under a different tactic. Review your mapping when you upgrade, and confirm the current technique and sub-technique IDs against the MITRE ATT&CK tactic page and the release notes before you publish coverage.
How do we test T1553 detections without disrupting production?
Test in a private cyber range or staging environment that mirrors your endpoint fleet, trust stores and logging pipeline, and never run trust-altering activity against production hosts. Use a controlled change in a lab, confirm the expected events reach your SIEM with the right fields, and check that the alert fires and routes to the correct queue. Keep a written test plan with the ATT&CK version, sub-technique tested, expected telemetry and rollback steps, so the test can be repeated after every logging or agent change.
How can we tell a legitimate trust change from tampering?
Correlate the change with an approved request, a known deployment or a change ticket, and check who or what made it, from which host and at what time. Legitimate changes usually come through managed channels such as configuration management, MDM or a scheduled certificate process, while tampering often comes from an interactive session, an unusual parent process or a host outside the normal management path. Treat an unmatched change to a trust store as an incident until someone confirms otherwise, and preserve the affected file or key for review.
Which data sources should we log first to detect T1553 well?
Prioritize Process Creation, Command Execution and Windows Registry Key Modification, since these are among the data components most often referenced by ATT&CK detection strategies for Defense Impairment techniques. Add File Modification for trust store files on Linux and macOS, and confirm that your agents, such as Wazuh agents or Velociraptor clients, capture the fields you need, including command lines, hashes and user context. Verify field coverage on each operating system you run, because telemetry available on Windows may not map directly to Linux or macOS.
How should we measure T1553 detection coverage over time?
Track coverage per sub-technique rather than as one percentage, and record which operating systems each rule covers, which cyber range test validated it and when it was last run. Re-run the validation after each major ATT&CK release, logging change or agent upgrade, and watch for rules that silently stop firing because a data source changed. Use the mitigations that ATT&CK maps to this area, such as Privileged Account Management and Software Configuration, as a second view to confirm that preventive controls and detections are both in place.
Can our own team run this program, or do we need outside help?
Many teams can run a detection program in-house if they already operate a SIEM, endpoint telemetry and a change management process, and the main gaps are usually test environments and review time. Outside help is most useful for scoping the first set of detections, building a private cyber range to rehearse them and documenting evidence for compliance reviews. DeployOpen plans, implements and documents open-source detection stacks inside your own environment under a written, fixed scope, and ongoing tuning can be covered by a retainer if you want continuity.
How DeployOpen builds T1553 detections and range exercises
DeployOpen approaches T1553 Subvert trust controls as a fixed-scope engagement inside the client's own infrastructure, covering the platforms, telemetry and sub-techniques agreed in writing before work starts. Detection content, validation and cyber range rehearsal are delivered as documented artifacts the client's own team can run and maintain.
How we scope
- Confirm which of the six T1553 sub-techniques apply to the platforms in your environment, such as Linux, macOS and Windows.
- Agree in writing which telemetry sources, including Process Creation and Windows Registry Key Modification, are in place or must be enabled.
- Record the ATT&CK version targeted, such as v20.0, so detection mappings stay traceable when techniques change.
How we build
- Implement open-source collection and detection content, such as Sigma rules, in the client's Wazuh, Security Onion or Zeek stack.
- Map detections to the Privileged Account Management and Software Configuration mitigations and document any gaps found.
- Test detection logic against the agreed telemetry and tune false positives with the client's operations team.
How we hand over
- Deliver written detection logic, data source requirements and validation results for each in-scope sub-technique.
- Run a cyber range rehearsal of the detection and response workflow so responders can practice on realistic-looking but isolated systems.
- Provide runbooks and an ownership map so the client's team can maintain rules after the engagement closes.
How we support
- Engagements are fixed-scope, so changes to platforms or ATT&CK versions are handled through a written scope amendment.
- Ongoing support, upgrades and continuous testing of T1553 detections are available as a retainer.
- Confirm with DeployOpen during scoping which review cadence and support channels apply to your environment.
