Registry Parser
← All articles

Detecting T1112: Modify Registry, fileless storage and tampering

8 min read

T1112, "Modify Registry", is the technique that gets used in almost every intrusion and noticed in almost none of them. It is the catch-all bucket in ATT&CK for the moment an adversary changes registry data to further an objective: turn off a defense, weaken a setting, hide configuration where defenders do not look, stash a payload, or scrub the traces of what they did. Persistence keys get the attention because they have famous names. The quiet T1112 edits — the flipped DWORD that disables a protection, the oversized binary value holding a stage-two payload — get walked past. This post is about catching them, and the centerpiece of fileless registry detection is the same handful of disk-level signals every time.

T1112 is deliberately broad. It overlaps with persistence, with credential access, with collection. The unifying observation MITRE makes is mechanical: the change lands in a hive, and the hive remembers more than the live registry shows you.

What "modify registry" covers

In casework the malicious modifications fall into five recurring categories.

Disabling security features. The single most common T1112 action. Set HKLM\SOFTWARE\Microsoft\Windows Defender\DisableAntiSpyware to 1, set \Real-Time Protection\DisableRealtimeMonitoring to 1, push exclusion paths into \Exclusions\Paths. Add a DisableTaskMgr or DisableRegistryTools under the Policies\System key to lock out the user. Each is a one-DWORD edit. None of them creates a file.

Weakening settings. Lower the bar rather than disable outright. Enable RestrictedAdmin or DisableRestrictedAdmin to change RDP credential behavior, set LocalAccountTokenFilterPolicy to 1 to defeat UAC remote-token filtering, flip EnableLUA to 0, drop SMB signing requirements, or set WDigest's UseLogonCredential to 1 so plaintext credentials land back in LSASS memory. These are the edits that make the next stage of the intrusion possible.

Hiding configuration and data. Malware needs somewhere to keep its C2 address, its campaign ID, its encryption key, its install timestamp. The registry is an ideal hiding spot: structured, writable without touching the filesystem, and ignored by most file-centric tooling.

Storing payloads as fileless storage. The serious case. The malware writes its own executable code — a PE, a shellcode blob, an encoded PowerShell stage — into a registry value, then a small launcher reads it back and executes it in memory. The payload never exists as a file on disk.

Clearing tracks. MRU lists (RecentDocs, RunMRU, TypedPaths, OpenSavePidlMRU, the UserAssist and shellbag trails), the value the attacker set and then deleted, the command history surfaces. Wiping these is itself a T1112 action, and one that — as covered below — frequently fails to actually erase the data.

Fileless storage in the registry

Why the registry, specifically. A file on disk gets an MFT record, an AmCache entry on first execution, often a Prefetch file, and a YARA-scannable footprint that EDR watches in real time. A value buried under HKLM\SOFTWARE\Classes\CLSID\{guid} gets none of that. File-integrity monitoring does not watch it. Antivirus on-access scanning does not parse it. To the casual eye it is one more opaque blob among the tens of thousands a normal hive already contains.

The classic pattern is a two-part split. The payload lives in one value — frequently a REG_BINARY or an oversized REG_SZ of base64 — while a tiny launcher lives in a Run key, a WMI subscription, or a scheduled task, doing nothing but reading the blob and handing it to a script host. Defenders who find the launcher and miss the storage value have removed the trigger and left the weapon. The payload value can be megabytes; the registry happily stores large data by spilling it across multiple cells in a "big data" db record, which is its own forensic tell (see the big data record deep-dive).

Detection: timestamps, anomalous values, recovery

There is no single signature for T1112 because the technique is "any edit". You detect it by reasoning about what a normal hive looks like and surfacing the deviations. Four signals carry most fileless registry detection work.

Key LastWrite timestamps. Every nk (key) cell carries a LastWrite time, updated whenever the key or its value set changes. This is the registry's only built-in temporal evidence, and it is the first thing to sort by. A Windows Defender policy key whose LastWrite falls inside your suspected intrusion window — when the surrounding keys all date to OS install — is a lead even before you read the values. Build a timeline of LastWrite times across the hive and look for clusters: a burst of modifications at 03:14 on a workstation that nobody touched at 03:14 is the shape of an automated tampering routine.

Be precise about what LastWrite can and cannot tell you, because it is routinely over-read. The timestamp lives on the key, not on the value. If an attacker changes one value under a key with twenty values, the key's LastWrite advances and you cannot tell from the timestamp alone which value changed. You get when the key last changed, not what changed and not how many times. Each write overwrites the previous timestamp, so a key edited ten times shows only the tenth. And it is writable: an attacker who can call RegSetKeyValue cannot trivially backdate it, but tooling exists that does, so treat a too-clean timestamp on a suspicious key as suspicious in itself. LastWrite narrows the window. It does not close the case. Corroborate with the transaction logs, VSS, and EVTX.

Anomalous, oversized, or type-mismatched values. Fileless payload storage is loud once you know the shape. Sort every value in the hive by data length and look at the top of the list — a value holding tens of kilobytes to megabytes under an application or CLSID key is abnormal; legitimate configuration is small. Carve the largest binary values and check for an MZ header, a base64 alphabet, or high-entropy ciphertext. Equally telling is a value whose declared type does not match its content: a REG_SZ or REG_EXPAND_SZ carrying raw binary, a REG_BINARY that decodes cleanly to a PE, a name with a null embedded to hide it from naive enumerators. The on-disk type field and the actual bytes are independent, and malware abuses the gap — the value types on disk write-up covers exactly how the vk record encodes this and why the mismatch is detectable.

Recovering deleted and cleared values. Track-clearing is a T1112 action that usually fails at its actual goal. When Windows deletes a value or key it does not zero the bytes; it flips the cell's size field to mark the space free, and the old nk/vk/db bytes sit in unallocated cells of the hive until a later allocation reuses them. A parser that walks free cells the same way it walks allocated ones reconstructs the deleted value — name, type, and data intact — long after the attacker "removed" it. The same applies to a cleared MRU: the entries are gone from the live view and recoverable from the slack. The full method — unallocated-cell carving, transaction-log replay, and VSS diffing as a four-source ensemble — is in the recovering deleted registry keys deep-dive. For T1112 the headline is simple: the edit the attacker reverted, and the data they wiped, are frequently still there.

Investigate it in your browser (tool + Findings)

You can run all four of these passes without standing up a forensic VM. Drop a hive into the parser and analyze the hive in your browser — nothing leaves your machine; parsing, log replay, and deleted-cell recovery happen client-side.

The workflow:

  1. Sort by LastWrite. Build the modification timeline and find the clusters. Pivot straight to keys whose timestamp sits in your incident window.
  2. Sort values by size. Surface the oversized binary and string values that signal fileless storage, then inspect the bytes for MZ, base64, or high entropy.
  3. Check type against content. Flag REG_SZ values carrying binary and REG_BINARY values that decode to executables.
  4. Run recovery. Replay the .LOG1/.LOG2 and carve unallocated cells to resurrect deleted values and cleared MRUs.
  5. Read the Findings tab. The built-in ruleset flags the well-known T1112 edits — Defender disablement, WDigest UseLogonCredential, UAC weakening, suspicious oversized values — so the boring tampering surfaces without a manual sweep. Treat it as the first pass, not the last word, and corroborate each hit against the timeline and the EVTX record.

Findings catches the catalogued edits fast. The timestamp, size, and type passes catch the ones nobody has catalogued yet.

Related techniques

T1112 rarely travels alone. The launcher half of a fileless payload is usually Boot or Logon Autostart Execution — a Run key or IFEO debugger entry pointing at the script that reads the registry-stored blob. Disabling Defender or weakening UAC is T1112 in service of Impair Defenses (T1562). Stashing C2 config is T1112 supporting collection or command-and-control. Clearing MRUs overlaps with Indicator Removal (T1070). For how these map across the catalog and how the registry threads through the matrix, see MITRE ATT&CK and the registry, and read the technique page itself: MITRE T1112, Modify Registry.

The registry is attractive to attackers for the same reason it is valuable to analysts: it remembers. Every modification leaves a timestamp, every payload leaves an oversized value, every "cleared" track leaves bytes in a free cell. Modify Registry is a quiet technique only against analysts who read the live hive and stop. Read all four sources and it is one of the loudest techniques there is.