Registry Symbolic Links: The Quiet Redirect Sysmon Can Still See

Most defenders use registry symbolic links every day and never notice, because HKEY_CURRENT_USER and HKEY_CLASSES_ROOT are themselves links resolved by the kernel on your behalf. That invisibility is the whole reason the feature is interesting from a defense-evasion angle. A symbolic link lets one registry key transparently resolve to another, and if a tool reads the source key by its path it can end up looking at a target it never intended to. ATT&CK parks the general behavior under Modify Registry (T1112), and we treat registry links as a niche but real hiding technique worth having a rule for.

What a registry symbolic link actually is

The mechanics are small and worth getting exactly right, because the detection hangs on one specific artifact. A symbolic link is a key created with the option REG_OPTION_CREATE_LINK. Under that source key sits a single value with a fixed name, SymbolicLinkValue, and its type is REG_LINK. The data in that value is the object-manager path of the target key, something like the fully qualified path beginning at the REGISTRY root, and importantly it is not null-terminated. When anything opens the source key, the kernel follows SymbolicLinkValue and hands back the target. One more quirk that trips analysts: the graphical Registry Editor generally refuses to open a link key and throws an error, so poking at it by hand tells you almost nothing. We had that confuse a triage for a bit longer than we’d like to admit before the mechanics clicked.

Why an attacker would bother

Honestly, most intrusions never touch this, and I want to be upfront about that rather than oversell it. Where it shows up is when someone wants a redirect that survives casual inspection. Point a benign-looking autorun or COM-related key at a target elsewhere in the hive, and a security tool that enumerates the expected path may read straight through to the attacker’s chosen key without flagging that a redirect happened. It’s also a neat way to make one location’s contents appear under another name, which muddies both live response and offline registry-hive parsing. It isn’t loud, it isn’t common, and that combination is exactly why it’s worth a cheap standing detection rather than a hunt you run once and forget.

The SymbolicLinkValue tell

Every symbolic link, without exception, requires that SymbolicLinkValue value to exist under the source key. That’s not an implementation detail we can tune around, it’s how the feature works, and it hands us a fixed string to anchor on. Any registry value being written whose name is SymbolicLinkValue is, by definition, the creation or modification of a registry symbolic link. There is no way to make a link without it. So the detection question stops being “how do we recognize a redirect” and becomes the much easier “who just wrote a value named SymbolicLinkValue, and is that a name we expect them to write.”

Sysmon coverage

This is where Sysmon does the job cleanly if you’ve enabled registry monitoring. Event ID 12 covers registry key create and delete, so the initial CreateKey with the link option surfaces there. Event ID 13 covers value-set operations, and that’s the one that matters, because the write of SymbolicLinkValue lands as an Event ID 13 whose TargetObject ends in that value name. Event ID 14 covers key and value renames and rounds out the picture. In our lab, Sysmon 15 on Windows 11 23H2 with registry events turned on logged the sequence as an Event ID 12 CreateKey immediately followed by an Event ID 13 setting the SymbolicLinkValue on the new key. Two events, back to back, from whatever process created the link. Worth one honest caveat: Sysmon abbreviates registry paths and its handling of the REG_LINK value data has varied across versions, so I lean on the TargetObject name for the match rather than trusting the logged data to always contain a clean target path. A recent Sysmon build with a config that actually includes registry value-set events is the prerequisite, and plenty of deployments quietly leave those off to save volume.

The detection we run

The core rule is almost embarrassingly short: alert on Sysmon Event ID 13 where TargetObject ends with SymbolicLinkValue. That single condition catches the technique’s mandatory artifact. We enrich it with the Image field so the analyst immediately sees which process created the link, and we pair it with the preceding Event ID 12 CreateKey for the same key path to confirm the full create-then-link sequence rather than an isolated value write. Because the underlying event is rare in most environments, we don’t need clever thresholds or correlation windows here. It’s close to a binary signal, and the alert that reaches a person carries the process, the source key, and the timestamp, which is enough to make a keep-or-drop call fast.

Tuning notes

The feature does have legitimate users, and the biggest one is Windows itself. The operating system stands up several registry links during boot and session setup: the CurrentControlSet mapping to a numbered control set, the per-user HKCU projection, and a handful of others, and those are created very early by trusted system processes like the session manager, not by an interactive user’s tool three days into an intrusion. So the tuning is mostly about Image and timing. We exclude the known system processes that create OS-level links at startup, we exclude our own approved management tooling if any of it legitimately builds links, and we treat a SymbolicLinkValue write coming from a user-mode process in a user session as the thing worth reading. After those exclusions the false-positive rate on this rule has been about as low as any detection we run, which is the payoff for a technique this specific: narrow behavior, narrow artifact, narrow rule.

For the registry-monitoring config this rule depends on, our 2026 Sysmon baseline covers which Event ID 12, 13, and 14 sources to keep on without drowning the pipeline, and if you want another example of squeezing high-signal detections out of the same telemetry, the token-theft detection using Sysmon writeup works the same narrow-artifact angle on a different technique.