Carlos A. Rojas

A javascript-free experience!

Why Good Guys Need Cross Session Execution in Windows

SaintCon — 2025 (Workshop)

Confirmed

Abstract

This interactive workshop looks at when and why a Windows administrator may legitimately need to run a process in the context of another user's logon session, and the mechanics that make it possible. The supplied session title uses the phrase “cross session execution”; the workshop itself is careful to break that down into the distinct Windows concepts it actually involves.

Precise terminology

These are not interchangeable, and the workshop keeps them distinct:

  • Access token. The kernel object describing an account's identity, groups, and privileges for a process or thread.
  • Impersonation. A thread temporarily adopting another token to act as that identity for a specific operation.
  • Token duplication. Copying an existing token (e.g. to create a primary token suitable for launching a new process).
  • Cross-session process creation. Launching a process in a different logon session (sessions isolate interactive logons; Session 0 is reserved for services).
  • Access to a user profile. Reaching a user's loaded registry hive and profile data — a distinct concern from running code as that identity.

Collapsing these into one idea is where both bad security writing and bad operational decisions come from.

Legitimate administrative scenarios

  • Running a repair or diagnostic tool in the context of a logged-on user's session to reproduce a problem that only manifests under that profile.
  • Delivering an interactive prompt to the correct session rather than the invisible Session 0.
  • Servicing or troubleshooting software that behaves differently per user context.

Each of these has a benign, auditable purpose — and each requires high privilege, which is exactly why it must be controlled.

Detection, auditability, least privilege

Because these capabilities are powerful, the workshop treats visibility and restraint as first-class concerns, not afterthoughts:

  • Auditing. Enable and monitor the relevant Windows security events (process creation with command line, special privileges assigned to new logons, and sensitive privilege use). An administrator using these techniques should be loud in the logs, not silent.
  • Least privilege. The privileges that make this possible — such as SeDebugPrivilege, SeImpersonatePrivilege, and SeAssignPrimaryTokenPrivilege — should be held by as few accounts as possible and granted deliberately, never by default.
  • Accountability. Tie the action to a named human and a ticket. “Who ran what, as whom, in which session, and why” should always be answerable after the fact.

Limitations & safer alternatives

These techniques are not a first resort. Before reaching for token manipulation or cross-session process creation, consider whether a supported remote-management tool, Run as, a scheduled task under the correct account, Group Policy, or a proper service running in the right context would accomplish the same goal with less risk and clearer auditing. The honest framing is that these are powerful tools for a narrow set of legitimate problems — and the same capabilities an attacker would abuse, which is precisely why defenders need to understand them.

Workshop lab

The hands-on portion is intended to run on a Windows virtual machine you own, isolated from production, with snapshots so the environment can be reset. It is an educational demonstration of administrator capability on an authorized system — not a technique for gaining access to a machine you do not control.

Materials

No slide deck or lab archive is published here yet. Downloadable materials will be added only when the actual files exist and are cleared for release. No external links, recordings, or attendance figures are claimed.

Related