escalation via VSStandardCollectorService150 (CVE-2024-20656)

CVE-2024-20656 is a local privilege escalation in Visual Studio. Installing VS with C/C++ support creates the service VSStandardCollectorService150, which runs as NT AUTHORITY\SYSTEM and starts on demand via COM. The service performs file operations (create/move/delete) on paths an unprivileged user can influence, and that is the crack: combining those operations with directory junctions and reparse points, a privileged action is redirected toward an attacker-chosen target, achieving execution as SYSTEM.

Confirming the ground. First, verify the service exists and runs as LocalSystem:

sc.exe qc VSStandardCollectorService150

SERVICE_NAME: VSStandardCollectorService150
        BINARY_PATH_NAME : "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Common\DiagnosticsHub.Collection.Service\StandardCollector.Service.exe"
        SERVICE_START_NAME : LocalSystem

The move (PoC). The public exploit (e.g. WHibe's) creates trap directories, opens a handle with FILE_FLAG_OPEN_REPARSE_POINT and stages junctions so that, when the SYSTEM service operates on "its" temp file, it ends up executing or placing the attacker's binary. Since the PoC is C/C++, you must compile it (on the box itself, which has Visual Studio, or on another Windows machine) and upload the resulting Expl.exe along with a reverse.exe generated with msfvenom.

The token detail. A shell obtained over WinRM uses a network logon, whose token usually lacks the privileges/identity the exploit needs to talk to the service's COM. So the exploit is relaunched with an interactive logon using RunasCs (RunasCs) and the user's credentials:

.\RunasCs.exe <user> <pass> "cmd /c C:\ProgramData\Expl.exe"

The exploit triggers the SYSTEM service, which runs the payload and returns a reverse shell as nt authority\system.

The box's hint. A note insisting on "keep Visual Studio updated to the latest version" is not decoration: it points to the vector being a patched VS vulnerability.

Hint vs proof. Seeing the service as LocalSystem with DEMAND_START suggests the vector, but the proof is the SYSTEM shell. It depends on the installed VS version and on being able to compile/run the PoC.

How to detect it. The signature is lineage plus filesystem manipulation: the VSStandardCollectorService150/StandardCollector.Service.exe service (as SYSTEM) spawning a binary that is not part of Visual Studio as a child (Event ID 4688 / Sysmon 1), and an unprivileged user creating directory junctions and reparse points in temp paths right before (Sysmon 11/2). The use of RunasCs also leaves an interactive logon (4624 type 2) originating from a service context, inconsistent with a normal session. A SYSTEM shell emerging after that sequence is the proof.

Defence. Apply Visual Studio security updates; restrict who can interact with the service; do not leave development tooling on production servers. Related to RunasCs, SeImpersonatePrivilege abuse and Windows kernel exploits.