---
{
  "title": "Modify Registry",
  "summary": "Registry modification changes Windows settings that can affect startup, security, or application behavior.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1112"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1112: Modify Registry",
      "url": "https://attack.mitre.org/techniques/T1112"
    }
  ],
  "editorialVersion": 2
}
---

## A settings database can support many behaviors

The Windows Registry stores settings used by the operating system and applications. Unauthorized modification can affect startup, application behavior, security configuration, or other functions. The significance comes from the particular key or value, its interpretation by software, and the authority used to change it.

Registry modification is routine. Installers, updates, user preferences, and administrators all make changes. An alert about a registry write needs the object, old and new values where available, actor, process, timing, and business context before it can support an incident conclusion.

## A value redirects an application action

In a fictional endpoint case, a registry value changes shortly before a trusted application begins launching an unexpected program. The analyst preserves the relevant configuration and examines the modifying process, account, referenced path, and subsequent execution.

An approved upgrade or integration may explain the change. Compare with deployment records and the application's expected configuration. A familiar registry location does not make every value safe, while an unfamiliar value may belong to legitimate software.

The team establishes whether the setting was actually consumed. A write event shows a configuration action; process or application evidence may show its effect. If the program never used the setting, report the change without claiming completed execution.

## Review scope and permissions

Some settings affect one user, while others affect the system or several services. Access requirements vary by registry location. Determine the actual scope and effective permissions instead of assuming every write required administrative authority.

[[boot-or-logon-autostart-execution]] may be relevant to startup-related values. [[hijack-execution-flow]] may explain altered code selection. A registry change should receive those mappings only when its purpose and effects support them.

Preserve relevant values and surrounding context before remediation where practical. An export can help document the configuration but does not replace the event trail showing when and by whom it changed.

## Restore the intended setting

Revert unauthorized values through an approved process and address the access that allowed the modification. Coordinate with the software owner because deleting broad registry areas can damage application or operating-system behavior.

Verify both the corrected setting and the resulting application behavior. A successful write of the intended value does not establish that every running process has reloaded it or that other related changes are absent.

For practice, compare a documented application preference update with a fictional value redirecting execution to an unexplained file. Identify change, provenance, permission, and runtime evidence. [[logs-and-telemetry]] supports interpretation, while [[incident-reporting]] keeps a configuration observation distinct from a confirmed harmful effect.

## Related concepts

- [[mitre-attack]]
- [[incident-response]]
- [[obfuscated-files-or-information]]
- [[valid-accounts]]
- [[remote-services]]