Test your SOC · about a minute

Can your SOC see one value quietly written?

One real attacker move, a safe way to run it on a machine you own, and the detection that closes the gap — in that order, so you leave with better coverage than you arrived with.

technique T1112 · Modify Registryseen in APT41where any Windows box

What this is about

Can your SOC see a registry value change?

The registry is where Windows keeps the settings that decide what starts, what is trusted and what gets logged. An intruder who can write one value can change any of those, and the quietest way to do it is not to type the key at all — it is to drop a small .reg file somewhere writable and import it in one line.

The detection watches for exactly that shape: reg.exe import reading from a temp or user folder. An administrator importing a settings file usually does it from a managed location; a .reg file that arrived in a temp directory minutes ago is a different story.

The detection watches one thing: reg.exe importing a registry file from a temporary or user-writable folder.

This is not hypothetical

The group tracked as APT41 is documented modifying the registry on the systems it compromises. Registry writes are how an intrusion becomes durable and how logging quietly stops being complete — both things that are far cheaper to catch at the moment of the write than to discover later.

It needs no exploit. A normal account can write its own part of the registry, and one built-in command applies the file. The same command you are about to run.

The actor above is named in MITRE ATT&CK’s own Procedure Examples for this technique; the link is where you can read it. Nothing on this page discloses a move an attacker does not already have — it just makes sure the defender has it too.

One value changes behaviour

Startup, trust, and what gets logged all live in the registry. A single value is enough to change any of them.

The import hides the intent

Typing the key on the command line shows what was written. Importing a file shows only a filename — which is why the source folder matters so much.

Your own hive needs no admin

An attacker does not need to reach the machine-wide settings to be effective. The per-user hive is writable by the user, and that is plenty.

The test

Run the real thing. Safely. On a box you own.

Write one harmless value the way an intruder writes it, then delete it — the script cleans up after itself.

01

Build a one-value registry file

The script writes a small .reg file into your own temp folder. It sets a single marker value under your own user hive and touches nothing else.

02

Import it with the built-in tool

Run reg import on that file — the actual technique, a registry value written from a file in a temp folder. This is the moment your SOC should notice.

03

Check your alerts, then let it clean up

Open your SOC or EDR and see whether a registry modification fired. The last two lines delete exactly the key and the file the script created.

test-your-soc-modify-registry.ps1 · PowerShell · a machine you own
# test-your-soc-modify-registry.ps1 — run on a machine you own.
# Safe: writes ONE marker value under your own user hive, then deletes exactly that key. No admin.
# STEP 1 - build a one-value registry file in your own temp folder, written out in full so the command line shows the path.
Set-Content -Path "$env:USERPROFILE\AppData\Local\Temp\CyRaySOCTest.reg" -Value @('Windows Registry Editor Version 5.00','','[HKEY_CURRENT_USER\Software\CyRaySOCTest]','"Marker"="test-your-soc"')
# STEP 2 - the actual technique: import it, which writes the value.
reg import "$env:USERPROFILE\AppData\Local\Temp\CyRaySOCTest.reg"
# STEP 3 - open your SOC / EDR. Did a registry modification alert?
# STEP 4 - clean up: remove exactly the key and the file this script created.
reg delete "HKCU\Software\CyRaySOCTest" /f
Remove-Item "$env:USERPROFILE\AppData\Local\Temp\CyRaySOCTest.reg" -Force

The script creates one key with one value under your own user hive — a key that did not exist before — and one small file in your own temp folder. The last two lines delete exactly those two things. No machine-wide setting is touched, nothing existing is overwritten, and no admin rights are needed.

Reading the result — honestly

Something fired

Your tooling watches for registry values arriving from a file in a temp folder

Good — an intruder wiring up persistence or quietly changing a setting would look the same. On to the next one.

Silence

The value was written unseen — now you know

Not a verdict on your team; a specific, fixable gap you just found in a minute. The detection below closes it.

Straight with you: we never see your alerts — you’re the judge, which is also why we never touch your data. And a lab isn’t production; a test box often logs differently than the real fleet. "It fired" means your EDR flagged reg import from a user-writable path — note that the same value can be written straight from a command line or from a script with no reg.exe at all, which this rule does not see, so pair it with a rule on the registry write itself. Treat a pass as a reason to go check prod, not a finish line.

How to catch it

Missed it? Here’s the fix — take it straight to your SOC.

The logic is public and every major SIEM already supports it. Here it is in Sigma, the open, vendor-neutral format your team can translate into whatever you run.

proc_creation_win_reg_import_from_suspicious_paths.yml
title: Potential Suspicious Registry File Imported Via Reg.EXE
id: 62e0298b-e994-4189-bc87-bc699aa62d97
related:
    - id: 73bba97f-a82d-42ce-b315-9182e76c57b1
      type: derived
status: test
description: Detects the import of '.reg' files from suspicious paths using the 'reg.exe' utility
references:
    - https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/reg-import
author: frack113, Nasreddine Bencherchali
date: 2022-08-01
modified: 2023-02-05
tags:
    - attack.persistence
    - attack.defense-impairment
    - attack.t1112
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\reg.exe'
        - OriginalFileName: 'reg.exe'
    selection_cli:
        CommandLine|contains: ' import '
    selection_paths:
        CommandLine|contains:
            - 'C:\Users\'
            - '%temp%'
            - '%tmp%'
            - '%appdata%'
            - '\AppData\Local\Temp\'
            - 'C:\Windows\Temp\'
            - 'C:\ProgramData\'
    condition: all of selection_*
falsepositives:
    - Legitimate import of keys
level: medium

Potential Suspicious Registry File Imported Via Reg.EXE · SigmaHQ rule 62e0298b-e994-4189-bc87-bc699aa62d97

Author frack113, Nasreddine Bencherchali · quoted in full and unmodified under the Detection Rule License 1.1 (DRL 1.1)

https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_reg_import_from_suspicious_paths.yml

Retrieved 2026-09-11 · file sha256 474ae988dc5006ac83411276e80eebe57e4a518dedf497c457f1359bac3abf17

If your test came back silent, that rule is the whole fix. Drop it into your SIEM, or send your provider this page — “we ran this, nothing fired, here’s the detection.” Either way your coverage is better tonight than it was this morning. That’s the point.

A new one every week

This is technique 10 of many.

Each one is a real attacker move, a safe way to try it, and the detection to close the gap. Run them over a few weeks and you’ll learn more about your real coverage than any dashboard has told you.

Curious how a system catches all of these at once, out of the box? That’s what we build — meet Mobula →

Credit & sources

The technique and the incident are documented by MITRE ATT&CK (T1112) and the sources linked above. The detection is expressed in Sigma, the open detection format maintained by the SigmaHQ community, so any team can use it freely; its author is credited above under DRL 1.1.

We show you public attacker tradecraft and public detection logic, and hand you both. Nothing here reveals anything an attacker doesn’t already have — it just makes sure the defender has it too.

CYRAY · MOBULA — SECURITY OPERATIONS, ORCHESTRATED BY AI