How T1112 Modify registry hides changes in Windows configuration
T1112 Modify Registry lets an adversary change Windows registry values so that configuration security tools, startup behavior or policy depend on is altered. For a SOC lead, the difficulty is that registry writes are routine on Windows. Installers, updates, management agents and users all write to the registry every day, so a single modifying write rarely stands out on its own. The technique appears in intrusions where an attacker needs to weaken a control, keep code running after a reboot, or change how a host applies policy. Because the change is a configuration edit rather than a new binary, it can slip past alerting that focuses on files and processes.
ATT&CK v19, released April 28, 2026, split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, which carries ID TA0112. Defense Impairment (TA0112) covers attempts to break the security mechanisms, pipelines and tooling that defenders rely on so they cannot see or trust what is happening. Modify Registry fits here because one configuration value can switch off logging, alter a monitoring agent's settings or weaken a policy, and each change reduces visibility without any new malware. This page targets ATT&CK Enterprise version 20.0, released October 13, 2026. Detection mappings should name that version, because releases can rename, deprecate or revoke techniques.
Before you tune any detection, confirm three things. First, identify which registry locations your endpoint agents, SIEM collectors and policy baselines depend on, and ask each vendor to document those dependencies in writing. Second, verify that your Windows telemetry captures registry modification events for those locations, since the ATT&CK data component Windows Registry Key Modification must be enabled and scoped correctly. Third, confirm which ATT&CK version your detection library maps to, and check it against v20.0 before you rely on its coverage claims. These checks decide whether the detections you build will fire on the changes that matter.
Which Windows telemetry reveals registry modification
This table compares the Windows data sources that expose registry changes made under T1112, along with the signal to look for and the open-source collector that gathers it. Read each row as a question to answer in your own environment: is the source enabled, is it forwarded, and does it carry enough context to tie a change to a process. The main takeaway is that registry change events are only as useful as the audit policy and collector configuration behind them, so confirm both before writing detections.
| Data source | Signal to look for | Open-source collector |
|---|---|---|
| Windows Registry Key Modification (DC0063), primary signal | Value writes or key changes under Run, RunOnce, Services, Winlogon and security provider paths | Sysmon registry events forwarded to Wazuh, or Windows Security events collected by a Wazuh agent |
| Windows Registry Key Creation, related signal | New keys created under sensitive hives, including keys that later hold executable paths or settings | Sysmon registry events forwarded to Wazuh, reviewed alongside Velociraptor hunts |
| Process Creation (DC0032), actor context | The process image, parent process, command line and user that made the registry change | Sysmon Event ID 1 or Windows Security process creation events, forwarded to Wazuh |
| File Modification (DC0061), linked configuration | Changes to .reg files, exported hive copies, or configuration files that the registry change depends on | Sysmon file events or Wazuh file integrity monitoring on agreed paths |
| Velociraptor collections, point-in-time state | Current values of autorun and policy keys, to confirm whether a change persisted on a host | Velociraptor artifacts run on endpoints during triage or scheduled hunts |
| Audit policy and object access settings | Whether registry auditing is enabled on the keys you intend to monitor, and whether the system audit subcategory is set | Windows audit policy configuration managed through group policy, checked by Wazuh configuration assessment |
| Log forwarding and retention | Whether the events arrive at the manager with timestamps and host identity intact, and how long they are kept | Wazuh agents and manager, with retention settings confirmed for the client environment |
Detection logic for registry changes that matter
Registry writes are common on Windows, so a useful T1112 detection narrows the field to changes that touch security tooling, startup behavior, or unusual actors. The cards below describe four logic patterns, the thresholds to tune for your environment, and the benign sources that will trigger them first.
Keys tied to security tooling
Alert on value creation, modification or deletion under keys that control endpoint agents, logging, Defender settings or event forwarding. Scope the rule to a short list of keys your team owns, such as the agent install path and audit-related policy keys, so the rule stays readable. Expect false positives from endpoint agent upgrades, group policy refreshes and vendor installers, so tag known change windows and exclude signed management processes only after validating them. Tune the key list before the thresholds.
Startup and autorun key writes
Watch writes to Run, RunOnce and Winlogon-style startup keys, then correlate each write with the process that made it and the value data written. Most software installers and updaters create these entries legitimately, so the signal is an entry that points to a user-writable directory or an unsigned binary. Confirm the baseline on a clean reference image first, because the same keys are used by many approved desktop applications.
Writes from unexpected parent processes
Compare the process that performed the registry write with the process family expected for that key. A scripting host, office application or archive utility writing to a security or startup key is a stronger lead than the write itself. Build an allow list per key from observed Process Creation lineage, and review entries that appear only on a few hosts. Installers and management agents will appear here, so document each approved parent before you enable blocking.
Bulk and rapid modifications
Count registry modifications per host over a short sliding window and alert when the count crosses a baseline you measure from normal activity. Bursts are typical during patching, Group Policy processing and software deployment, so the threshold should be set per host group and paired with the parent process and time of day. Treat a burst that follows a new or rare process as higher priority than one that follows a known deployment job.
Changes outside maintenance windows
Flag security-relevant registry changes that occur outside approved change windows, and especially those on servers or privileged workstations with no scheduled activity. Maintenance calendars, change tickets and endpoint management schedules must feed the rule as context, or every legitimate after-hours patch becomes an incident. Confirm with your change management system which time zones and maintenance groups apply, since mismatched clocks can produce false alerts.
How to validate that registry detections fire
The detection team runs the registry modification scenario in the private cyber range before anyone else sees it. Because the operators know the expected outcome, the run measures whether the pipeline from endpoint telemetry to alert works end to end, and it creates a clean baseline for later comparison. Pin the run to the ATT&CK version the rule targets, so the expected behavior is documented against a fixed reference.
- Timestamps: Record when the scenario starts, when the registry change is written, when the event reaches the collector, when the rule fires and when the alert opens. The gaps between these points show where latency sits.
- Host and identity: Note the endpoint name, the account that performed the action and the agent version, so later findings can be traced to the exact sensor state.
- Process lineage: Capture the parent and child processes that touched the key, as the Process Creation and Windows Registry Key Modification telemetry presents them.
- Alert ID: Store the rule identifier and the alert identifier in the run log so the result can be repeated and audited.
- Time to triage: Have the analyst record how long it takes to open the alert, classify it and reach a decision.
Before closing the run, confirm that every step in the log has a timestamp and that the expected alert ID appears in the case system.
In a purple team exercise, detection engineers and the SOC work the same scenario together, but the analysts do not know which step is coming. The goal is to test the human workflow as well as the rule: whether the alert reaches the queue, whether the analyst reads the right fields, and whether the escalation path works at the hour the exercise runs. A facilitator holds the master timeline and records what each side observed.
- Shared timeline: The facilitator logs each action time and the matching analyst acknowledgment time, so the delay is measured instead of estimated.
- Pivot fields: Record which fields the analyst used to investigate, such as host, parent process and key path, and note any field that was missing or unclear.
- Alert and case IDs: Tie each alert ID to the case ID and the ticket the analyst opened, so the trail from detection to action is complete.
- Triage duration: Measure the time from alert creation to first analyst action and from first action to a documented decision.
- Outcome labels: Mark each step as detected and triaged, detected but not triaged, or not detected, using the same labels in every exercise so results compare across runs.
Before closing the exercise, confirm the SOC has a written record of each decision and that the facilitator's timeline matches the platform timestamps.
A step that produces no alert is not automatically a broken rule. Separate two cases: a missed detection, where the telemetry arrived but the logic did not match, and a tuning gap, where the logic matched but the alert was suppressed, scored too low or excluded by an allow list. Each case has a different owner and fix, so the record has to show which one occurred.
- Confirm telemetry arrival: First check whether the registry modification event reached the collector and was indexed. If it did not, the problem sits in collection, not in detection logic.
- Check the rule match: Replay the stored event against the rule. If the event does not match, the logic or field mapping is the likely cause of a missed detection.
- Check suppression: If the rule matches but no alert opened, look for exclusions, thresholds or deduplication settings that hid the result.
- Record the version: Note the ATT&CK version and rule revision used for the mapping, since releases can change technique details and detection mappings. The ATT&CK updates page lists the release history to check against.
- Assign the fix: Missed detections return to rule engineering. Tuning gaps go to the owner of the exclusion, with a documented risk decision.
After any change, re-run the same step and keep both runs in the record so the improvement can be shown to auditors and to the SOC.
Steps to test a T1112 detection before relying on it
This sequence confirms that a T1112 Modify Registry detection sees the telemetry it depends on, fires on a scoped and approved emulation, and produces a documented record of what was caught, what was missed and which ATT&CK version the mapping targets. Each step ends with a check that the next one can rely on.
Confirm registry and process telemetry on a test host
Before any emulation, the detection engineer and the platform team confirm that the test Windows host forwards Windows Registry Key Modification and Process Creation events to the SIEM, such as Wazuh or Security Onion. Check that the audit policy for registry changes is enabled on the monitored keys, that the event fields (process, user, key path, value name and value data) arrive intact, and that the timestamps match the host clock. The step is done when a manual, harmless change to a test key appears in the SIEM with every expected field populated.
Agree the emulation scope in writing
The red team or testing partner, the system owner and the SOC lead agree in writing which registry paths, which test accounts, which hosts and which emulation behaviors are in scope, along with the stop conditions and who may halt the test. Exclude production hosts and any keys that control security tooling unless the owner has approved the test explicitly. The output is a signed scope document that names the ATT&CK version targeted and the technique and sub-technique IDs under test.
Prepare the isolated lab and baseline
The team builds or confirms a private cyber range or isolated test network with no route to production systems. They capture a baseline of the registry state and of the detection rules and alerting configuration, so every later change can be compared against it. The step is complete when the lab snapshot is recorded and the team can restore the test host to that snapshot.
Run the scoped emulation in the isolated lab
The testing team runs the agreed emulation against the test host, keeping a timestamped log of each action, the account used and the expected detection outcome for that action. The SOC observes without tipping off the operators unless the exercise design calls for it. The step produces a run log that lists every action performed, so that the detection results can be matched to specific events later.
Verify the alert in the SIEM
The detection engineer checks whether the expected rule or analytic fired in the SIEM for each logged action, and whether the alert contains the process, user, key path and value data needed for triage. Confirm that the alert reached the case queue or notification channel the on-call analyst actually watches. The step is done when each action is marked as detected, partially detected or missed, with the alert identifier attached.
Record results against the targeted ATT&CK version
The team writes a validation record that names the ATT&CK version used for the mapping, the technique and sub-technique IDs, the data components relied on, the rule identifiers and the outcome for each action. Store the record with the detection rule in version control so auditors and future engineers can trace what was tested. Recheck the mapping when MITRE releases a new ATT&CK version, since releases can rename, deprecate or revoke techniques.
Log gaps and tune the detection
Each missed or partial action becomes a tracked gap with an owner, a root cause (missing telemetry, narrow rule logic, noisy exclusions, or alert routing) and a proposed fix. Tuning should widen coverage without adding exclusions that hide the emulated behavior. The step is done when every gap has a recorded decision: fixed, accepted with a documented reason, or deferred to a named owner.
Re-test after tuning and retain evidence
After tuning, the team reruns the same emulation from the same baseline and compares the results with the first run. The retest confirms that fixes work and that no earlier detections regressed. Retain both run logs, both validation records and the final results as evidence of the detection's behavior at a stated point in time, and schedule the next retest whenever the telemetry pipeline, the rule or the ATT&CK mapping changes.
Mitigations that reduce registry tampering
Mitigations for T1112 Modify Registry work at different layers: who can write to registry keys, which privileged accounts can change them, which accounts exist to begin with, and whether changes leave a record. The cards below cover the ATT&CK mitigations most relevant to this technique, plus related controls to confirm in your own environment.
Restrict registry permissions
This is the primary mitigation ATT&CK maps to T1112 through M1024. Access control lists on sensitive keys, such as those controlling services, startup behavior, security providers and authentication packages, determine which accounts and processes can write to them. Review the keys that matter most for your estate, remove write access from broad groups, and confirm that changes to those permissions are themselves logged. Test each change against your software and backup agents, since some vendors expect write access to their own keys.
Privileged account management
Privileged Account Management (M1026) limits how many accounts can change the registry in the first place. Most registry tampering that succeeds depends on an administrator or SYSTEM-level context, so reducing standing administrative rights, using separate admin accounts and time-bound elevation shrinks the set of identities that can make the change. Confirm which groups hold local administrator rights on your Windows fleet and which service accounts run with elevated privileges.
Audit registry changes
The Audit mitigation (M1047) addresses visibility rather than prevention. Enable object access auditing on the keys you have chosen to protect, and make sure Process Creation events with command-line content reach your SIEM. Without this, a registry change may succeed and leave no usable trace. Ask your Windows and SIEM teams to confirm which keys are audited, the retention period on those logs, and how alerts reach an analyst.
User account management
User Account Management (M1018) covers how accounts are created, reviewed, disabled and removed. Stale accounts, shared logons and unmanaged service accounts give an attacker a route to write to the registry under a legitimate name. Review dormant and orphaned accounts on a set schedule and tie account lifecycle to your identity provider so that access removed centrally also loses its local rights.
Restrict file and directory permissions
Restrict File and Directory Permissions (M1022) is a related control rather than a registry control. Many persistence and tampering paths write both a registry value and a file on disk, so tightening file permissions on program and configuration directories can block half of a change. Confirm with your endpoint team which directories are writable by non-administrative users and whether any exceptions are documented.
Software configuration
Software Configuration (M1054) is a related control to confirm in your environment. Security-relevant settings in Windows components, endpoint agents and third-party software can be hardened through configuration baselines, which reduces the number of keys an attacker has a reason to touch. Ask your platform team which baseline is applied to Windows endpoints, how deviations are approved and how baseline drift is detected.
Triage and response when a registry alert fires
Confirm the change before anything else. A registry alert for T1112 Modify registry can come from a legitimate patch, an application installer, a group policy refresh or a configuration management run, so the first task is to check whether the modified value is expected. Pull the key path, the old and new data, and the time of the write from your Windows Registry Key Modification telemetry, then compare it with change tickets and deployment logs. Next, identify the writing process and the account behind it from the Process Creation event that preceded the write. Note the parent process, the image path, the signer and the logon context. A write by a signed installer under a change window is a very different case from a write by a script launched from a user profile directory. Record both identifiers in the incident record before anyone starts reversing changes, because the answer determines whether you are looking at administration or intrusion. Then decide what the key controls. Registry values are often used to disable security tooling, alter logging, or start code at logon, so check whether the modified path sits under service configuration, Run or RunOnce keys, Winlogon, security provider settings, or the configuration of your endpoint protection and log forwarding agents. If it does, treat the alert as an active defense impairment until proven otherwise. Isolate the host from the network if the writing process is unknown, if the key governs security tooling, or if the same account shows activity elsewhere. Isolation should be a documented decision with a named owner, and it should not wipe the host. Before any cleanup, preserve the current registry state with an exported hive or a forensic collection, and retain the Security and Sysmon event logs, along with the forwarded copies in your SIEM. Confirm the retention window of those logs with your platform team, since local rotation can erase the evidence first. Escalate to the incident commander and the security operations lead when the key is tied to security controls, when the writing process is unsigned or unexplained, when the account is privileged, or when the same key or process appears on more than one host. Recovery is a separate decision: restore the value only after the entry point is understood, and verify the restored state against your baseline. Keep a timeline that lists the first observed write, the alert time, each triage decision with its time and owner, isolation and preservation steps, and any restoration. Use the timestamps from your collection tools rather than memory, and state the ATT&CK version you mapped the detection to, so that the record remains interpretable after future releases.
Rehearsing T1112 detection in a private cyber range
The range should mirror the production Windows estate closely enough that registry telemetry behaves the same way. Build a small domain with a few Windows endpoints in different roles, such as a workstation, a member server and a jump host, and place a Wazuh manager or Security Onion sensor where it can receive events from all of them. Confirm the agent or log shipper version on each endpoint, because registry auditing depends on how the host is configured and what the collector forwards. Keep the range isolated from any corporate network, and record the exact OS build and collector versions so results can be repeated.
- Endpoint mix: Include at least one endpoint that matches a standard build and one that reflects a legacy or exception build used in your environment.
- Audit configuration: Document which registry paths are audited through the Windows audit policy and which are watched by the agent, since gaps usually come from there.
- Log forwarding path: Confirm the route from each endpoint to the manager, including time synchronization and any queueing, so timestamps can be compared.
- Baseline capture: Record normal registry activity from installers and updates before any inject runs, so benign noise is known.
- Rule deployment: Load the detection rules targeting the ATT&CK version you have mapped, and confirm they are active before the exercise starts.
Before the exercise, ask your platform team to confirm which registry data components and audit settings your collector can produce on each OS version in scope.
Injects are scripted changes the facilitator makes to the range so the blue team can practice detection without learning the exercise plan in advance. Three injects cover the main decision points: an unexpected change to a security-relevant registry value, a benign installer change that should be recognized and closed, and a repeated modification that should be escalated as a pattern. Write each inject as a scenario card with the expected telemetry, the expected analyst decision and the time window, and keep the actual change method out of the shared plan so the exercise tests detection rather than memorization.
- Unexpected change: A security-relevant value changes on a server with no matching change ticket, which should raise an alert and start triage.
- Benign installer change: A signed software update writes expected keys, which tests whether analysts can separate known-good activity from suspicious activity.
- Repeated modification: The same value changes several times across endpoints within a short window, which tests correlation and escalation.
- Silent gap: Include one change that the rules should not catch, so the team records the coverage gap instead of assuming it is covered.
- Inject log: Keep the facilitator log with exact times, so each alert can be matched to the inject that caused it.
Illustrative example: a facilitator schedules the repeated-modification inject for one afternoon and checks whether the team correlates it with the earlier unexpected change.
Scoring should measure what the team did with the signal, not only whether an alert fired. Define criteria before the exercise and apply the same rubric to every inject. Useful measures include time from change to alert, whether the alert contained enough context to triage, whether the analyst classified the event correctly, and whether the response followed the documented runbook. Ask the team to record decisions in a shared timeline so reviewers can see where knowledge or tooling was missing.
- Detection coverage: Record which injects produced an alert, which produced none, and which produced alerts that were too noisy to act on.
- Latency: Compare the timestamp of the change with the timestamp of the alert, and record any delay caused by forwarding or queueing.
- Triage quality: Check whether the analyst identified the host, the key, the prior value and the user or process context.
- Response accuracy: Confirm whether the team reverted or contained the change where the runbook called for it, and whether benign changes were closed with a reason.
- Documentation: Require a short after-action note listing rule changes, data gaps and owners.
Check with your SOC lead whether your team's response targets and escalation thresholds are written down, since scores are only meaningful against an agreed standard.
A good exercise ends with changes to detection content, configuration and runbooks, not just a score. Good response means the team confirmed the change, decided whether it was authorized, restored the expected value where appropriate, and preserved enough evidence for later review. Lessons should be assigned to owners and retested in the range, so the next run shows whether the fix worked. Where the exercise exposed a mitigation gap, such as permissions that allowed unexpected writers, link the finding to the ATT&CK mitigation Restrict Registry Permissions and to the platform team's access review.
- Evidence preservation: Confirm that the team kept the relevant event records and did not overwrite them while investigating.
- Permission review: Identify which accounts and processes could write to the monitored keys, and whether that access is still needed.
- Rule tuning: Adjust rules to reduce false positives from the benign installer inject without suppressing the unexpected change.
- Retest: Rerun the same injects after changes and compare results against the baseline.
- Management summary: Report coverage, gaps and owners in plain language for the security steering group.
Before scheduling a retest, ask the platform team to confirm that the configuration change is captured in version control and that the owner has signed off.
How to keep registry detections accurate over time
Registry detections for T1112 Modify Registry decay quickly unless someone owns their tuning. Modifications to Windows Registry keys are routine: software installers, endpoint agents, group policy refreshes and management tools all write values constantly. Review the false positives from your Windows Registry Key Modification and Process Creation rules on a fixed weekly cadence, and record each decision with the key path, the writing process, the account and the reason it was judged benign. Allowlist known software and management tools only with a documented owner, a stated business purpose and an expiry or review date. An allowlist entry without an owner is a blind spot that an attacker can later reuse, so treat every exception as a control change that goes through your normal change process.
Track coverage against the ATT&CK version your team actually uses. Each detection should name the ATT&CK version it targets, the technique and any sub-techniques it maps to, and the data components it depends on, so that a reviewer can see which parts of T1112 have analytics and which do not. Because ATT&CK releases can rename, deprecate or revoke techniques, re-validate your mappings after each release. The recent ATT&CK releases are listed on the MITRE ATT&CK updates page, and you should confirm what changed for T1112 and its related detection strategies before you update your rules. Re-run your cyber range validation after any change that touches the mapping, the telemetry source or the allowlist, and keep the results with the rule version so that an auditor can trace a detection to the evidence behind it.
Questions SOC leads ask about detecting T1112
How do I separate malicious registry changes from normal installer activity?
Start by treating installers as expected noise and baselining them rather than suppressing whole categories of events. Pair each registry write with the process that made it, its parent, its signer and the path it ran from, then alert when a write to a sensitive run key, service key or security policy key comes from an unsigned binary, a script host or a user-writable directory. Installers usually write to a predictable set of keys during a known change window, so a change ticket or software deployment tag in your asset inventory lets you suppress only matching events. Review the allowlist on a schedule, because a broad exception for one vendor can hide the same behavior from any other binary.
Is Windows registry auditing enough without process creation telemetry?
Registry auditing alone shows what changed but usually not who or what made the change, which makes triage slow and false positives hard to clear. Process Creation telemetry supplies the actor, command context and parent chain that link a registry write to a specific execution, so the two data components work best together. Without process telemetry, you can still catch changes to high-value keys, but expect to spend more analyst time correlating events by timestamp and host. Confirm which audit subcategories and object access settings your Windows fleet actually enables, because registry auditing is off by default and noisy when applied broadly to the whole hive.
How do I validate T1112 detections in a lab without risking production?
Build the detection in an isolated cyber range that mirrors your logging pipeline, endpoint agents and Windows build, with no route to production identity or data. Run controlled, benign test activity that writes to the same classes of keys your rules watch, then confirm the events reach your SIEM with the expected fields and that alerts fire with the right severity. Record what fired, what was missed and what was noisy, and retest after every rule change. Keep the test scripts, timestamps and results as evidence so the validation can be repeated when you upgrade agents or change the rule logic.
Which ATT&CK data components should a SOC prioritize for T1112?
Prioritize Windows Registry Key Modification and Process Creation, since ATT&CK detection strategies for Defense Impairment techniques most often reference these two data components alongside Command Execution and File Modification. Registry Key Modification gives you the change itself, while Process Creation gives you the actor, which is what turns an event into an investigation lead. Add Command Execution where your endpoint platform can capture it reliably, and confirm which fields each sensor actually populates before writing rules that depend on them. The ATT&CK data component pages on the MITRE site are the authoritative place to check these mappings.
How should our team handle ATT&CK version changes that affect T1112 mappings?
Pin every detection to the ATT&CK version it was written against, and record that version in the rule metadata and your detection inventory. ATT&CK releases can rename, deprecate or revoke techniques and sub-techniques, and v18 moved detections into detection strategies and analytics, so a rule that cites an old analytic may no longer match the current guidance. Review the MITRE ATT&CK updates pages at each release, then diff the Enterprise STIX bundle for the technique and its mitigations. Schedule a regression run in your cyber range after any change so you know whether the detection still fires as expected.
Can our own team build and run T1112 detections, or do we need outside help?
A capable detection engineering team with access to Wazuh, Sigma-based rule tooling and a SIEM can build and tune T1112 detections in-house, provided it has time to test them. Outside help is most useful for scoping the work, designing the cyber range, rehearsing response and producing repeatable validation evidence for an assessment. DeployOpen implements, hardens and supports self-hosted open-source platforms inside the client's own environment, and runs security testing and private cyber ranges, under a fixed scope agreed in writing before work starts. Ask any provider to state which deliverables they produce and who keeps the rules and evidence after the engagement ends.
What does a T1112 detection project cost, and what drives the price?
The main cost components are the people building and tuning rules, the telemetry infrastructure that collects registry and process events, the cyber range used for validation and the time spent on triage and allowlist maintenance. Most of the upfront effort is one-time work such as building the lab, writing and validating rules and documenting the process, while log storage, sensor licensing where applicable, rule tuning and periodic regression testing recur. Volume of endpoints, retention requirements and the number of ATT&CK version updates to track all push costs up. No specific figure is given here, so ask any provider for a fixed-scope quote that itemizes deliverables, testing hours, infrastructure and ongoing support separately.
How DeployOpen builds registry detections and range exercises
DeployOpen approaches T1112 Modify Registry as a scoped piece of detection engineering inside your own Windows environment, with the telemetry, rules and exercises agreed in writing before work starts. The result is a detection you can test, hand over and maintain.
How we scope
- Confirm which Windows host groups, registry hives and keys are in the written scope for T1112 Modify Registry.
- Inventory whether Process Creation and Windows Registry Key Modification events already reach your SIEM or Wazuh manager.
- Record the ATT&CK version the detection targets so mappings stay valid after future releases.
How we build
- Write detection logic in Sigma and translate it to your Wazuh or Security Onion query language inside your environment.
- Tune exclusions for known software updaters and management agents so alerts stay tied to suspicious registry changes.
- Configure audit policy and registry auditing where the telemetry gap is confirmed, then verify events arrive as expected.
How we hand over
- Deliver rule files, data source requirements, tuning notes and a mapping to the ATT&CK technique and its mitigations.
- Document the validation steps, expected event samples and known blind spots so your team can rerun them.
- Provide a runbook for triage and response, agreed with your security operations team before handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- Retainers can cover rule updates when ATT&CK releases change technique or data component mappings.
- Ask any provider to confirm in writing which environments, owners and response steps the support covers.
