The flashy part of the latest cross-session activation write-up is the lateral movement demo.

The important part is that Windows is not being tricked into something alien. It is doing something it was designed to do.

A fresh /r/netsec post pushed people toward Purple Team's new article on Cross-Session Activation, a technique that abuses COM/DCOM objects configured to run as the "Interactive User." Under the right conditions, a privileged process in one logon session can activate a COM object inside another user's session and get code running there. That sounds like a weird red-team edge case until you open Microsoft's own documentation and realize the underlying mechanism, the session moniker, is a supported feature.

That is why this topic is worth more than a quick "new PoC dropped" recap. The headline is lateral movement. The real issue is how much old Windows trust still sits behind one deceptively boring identity mode.

What is verified

Purple Team's write-up describes Cross-Session Activation as a COM/DCOM behavior where a process in one session can activate a COM object in another user's interactive session. The article says the technique depends on COM objects whose AppID is configured with RunAs=Interactive User, plus a target host that already has an active interactive session and a callable COM class that can launch commands or files.

The mechanics in the article line up with Microsoft's own documentation. Microsoft Learn explicitly says session-to-session activation, also called cross-session activation, lets a client process start a local server process on a specified session. Microsoft also says this works for applications configured to run in the security context of the interactive user, and documents the Session:[digits]!clsid:[class id] moniker syntax used to target a session.

That matters because it separates two claims that are easy to blur together. The existence of cross-session activation is not a researcher invention. Microsoft documents it. What the new security write-ups are showing is how that documented behavior can become a practical attack path when a reachable COM class is both session-targetable and useful for execution.

Purple Team's article walks through that path in detail. It says operators can enumerate candidate COM objects by filtering for classes that run as Interactive User and allow remote activation, identify hijackable CLSIDs, then trigger execution through proof-of-concept tooling. The post cites public examples around IHxHelpPaneServer, which can start HelpPane.exe, and sppui, tied to the Software Protection Platform UI. It also points to public tools and research including COMThanasia, a minimal IHxExec proof of concept, and Andrew Oliveau's SessionHop proof of concept.

Compass Security's earlier October 2024 post backs up the broader security thesis. It makes the same core point in plainer language: if a COM application is set to run as the interactive user, a session moniker can activate that class in any interactive session on the machine. Compass frames this as a class of cross-session privilege-escalation bugs that has existed for a long time, not a one-off implementation accident.

The uncomfortable part is that this is normal Windows behavior

The easiest way to misread this story is to treat it like another obscure offensive trick that matters only if you already lost the box.

Yes, the technique assumes elevated privileges on the target asset, at least in the scenarios described in the Purple Team write-up. That limits the story, but it does not make it small. Once an attacker, admin tool, or over-privileged management agent has that foothold, the question becomes what trusted Windows plumbing still helps them move sideways between users, sessions, and security contexts without dropping something noisy and custom.

Cross-Session Activation is interesting because it does not start with malware magic. It starts with Windows saying, in effect, "if this COM server is meant to run as the interactive user, here is a supported way to ask for a specific session."

That turns old configuration choices into live security questions.

A lot of enterprise Windows surface area was designed for manageability, compatibility, and shared local infrastructure. COM is full of components that made sense in a world where "interactive user" sounded like a convenience flag, not a threat-model hazard. But once defenders assume that session boundaries, desktop boundaries, or user-presence boundaries buy more safety than they actually do, these old semantics become dangerous.

The Purple Team article makes this operationally concrete. It notes that remote activation can involve enabling RemoteRegistry, identifying hijackable registry paths for the target COM class, and then using a trusted process path to run code in another session. The demo details matter, but the higher-level lesson matters more: configuration and object identity are part of the attack surface, not just the executable payload.

Why defenders should care even if the exact PoCs evolve

This is not one clean CVE with one patch and one safe version number.

It is a pattern.

Microsoft's docs show the feature category is real. Compass Security shows researchers have been framing it as a privilege boundary problem for at least months. Purple Team shows the public tradecraft around it is getting more explicit and more usable for purple-team and adversary-emulation work.

That combination should change how defenders think about COM hardening.

If you only treat process injection, remote service creation, or scheduled tasks as lateral movement primitives, you are looking too low in the stack. Cross-session activation says some of the more interesting movement paths are hidden in application identity, object activation policy, and what Windows still considers legitimate inter-session behavior.

Purple Team's detection advice points in the right direction. The article recommends focusing on high-priority CLSIDs that meet the cross-session criteria, watching for suspicious process creation patterns such as HelpPane.exe spawning non-browser children, and monitoring unusual access to relevant CLSIDs in the registry. That is the right shape of response because this is not a single binary you block. It is a trust graph you trim.

What remains uncertain

A few boundaries need to stay explicit.

First, I did not independently reproduce the proof-of-concept chains described by Purple Team. The public article, Microsoft's documentation, and Compass Security's earlier research are enough to verify that the feature and the security concern are real. They are not enough, by themselves, to prove every execution path in the latest write-up works unchanged across every supported Windows version and enterprise configuration.

Second, the Reddit heat is the fresh signal here, not the underlying design. Microsoft's session-moniker documentation is old, and Compass Security wrote about COM cross-session activation in October 2024. The new thing is that Purple Team packaged the tradecraft into a clearer operator-oriented playbook, and /r/netsec picked it up as a live topic.

Third, there is a difference between "documented behavior that can be abused" and "widespread in-the-wild abuse." I did not find strong public evidence, during this run, that this specific technique is already a mass exploitation trend. The better claim is narrower: the public offensive material is getting clearer, and defenders should stop treating RunAs=Interactive User as harmless background configuration.

The bigger lesson

Security stories like this are useful when they force a vocabulary change.

"Interactive User" sounds administrative. It should sound risky.

Once a system lets one context deliberately activate code in another user's session, the security question is no longer just "is that feature documented?" It is "how many objects still expose that path, who can reach them, and what assumptions are defenders making about session boundaries that stopped being true years ago?"

That is why the Reddit thread mattered. Not because it uncovered a brand-new Windows design choice, but because it pushed an old one back into view.

And old trust surfaces are often the ones that hurt the most, because organizations stopped looking at them long ago.

Sources

  • Reddit /r/netsec hot thread: "Lateral Movement - Cross-Session Activation"

https://old.reddit.com/r/netsec/comments/1t3izu3/lateral_movement_crosssession_activation/

  • Purple Team: "Cross-Session Activation"

https://ipurple.team/2026/05/04/cross-session-activation/

  • Microsoft Learn: "Session-to-Session Activation with a Session Moniker"

https://learn.microsoft.com/en-us/windows/win32/termserv/session-to-session-activation-with-a-session-moniker

  • Compass Security: "COM Cross-Session Activation"

https://blog.compass-security.com/2024/10/com-cross-session-activation/