Hi everyone,
I spend some of my free time chasing random Red Team ideas. Not necessarily vulnerabilities or privilege escalation bugs; sometimes I just wonder whether I can make telemetry tell a slightly different story from what actually happened.
While looking at Sysmon, one question came to mind: If a SYSTEM service performs an operation while impersonating another user, who does Sysmon blame for that operation?
That became the starting point for this experiment.
Named-pipe impersonation itself is nothing new. Windows has supported it for years, ImpersonateNamedPipeClient() is documented, and named pipes have been used in Red Team techniques forever. I wasn’t trying to discover a new impersonation primitive. I just wanted to take that existing behavior one step further and look at what Sysmon does with the resulting activity.
I wrote a small Windows service called GhostBrokerService.exe. It runs as NT AUTHORITY\SYSTEM and exposes a named pipe called \GhostBrokerResearch.
A normal user, TEST\GhostB, connects to the pipe. The service then calls ImpersonateNamedPipeClient(), creates a file while impersonating GhostB, and finally calls RevertToSelf() to become SYSTEM again.
The important part looks roughly like this:
pipe.WaitForConnection();
ImpersonateNamedPipeClient(
pipe.SafePipeHandle.DangerousGetHandle()
);
File.WriteAllText(file, "test");
RevertToSelf();The first thing I wanted to prove was that the file was genuinely being created using GhostB’s permissions rather than SYSTEM’s. Simply printing the current identity from my own service didn’t feel like enough evidence, so I decided to make Windows access control prove it for me.
I created C:\GhostServiceLab and gave GhostB and GhostC Modify permission, while SYSTEM only had Read/Execute permission. In other words, the service could not simply write to the directory using its normal SYSTEM identity.
If the service attempted the write as SYSTEM, it should fail. If the service successfully impersonated GhostB, Windows would evaluate the operation using GhostB’s security context and the write should succeed.
And it did.
The service log also showed exactly what I expected. The service started as NT AUTHORITY\SYSTEM, the worker thread impersonated the connected client, created the file while that impersonation was active, and then returned to SYSTEM after calling RevertToSelf().
Up to this point, nothing unusual was happening. This is simply normal Windows impersonation behavior.
Then I looked at Sysmon.
When GhostB connected to \GhostBrokerResearch, Sysmon Event ID 18 correctly identified the client:
- PipeName: \GhostBrokerResearch
- User: TEST\GhostB
This part was important because Sysmon clearly knew GhostB existed. The client identity was visible at the pipe connection.
A few milliseconds later, the service thread was impersonating GhostB and created the file. Sysmon Event ID 11 recorded the file creation, the process name was correct, the filename was correct, but the user was:
- User: NT AUTHORITY\SYSTEM
That was the interesting part.
The process really was a SYSTEM process, so I wanted another source before assuming I had found anything meaningful. I enabled Windows File System auditing and checked Security Event ID 4663 for the exact same file operation.
Windows Security showed:
- Account Name: GhostB
- Account Domain: TEST
- Process Name: GhostBrokerService.exe
- Accesses: WriteData / AppendData
I also checked the owner of the created file. It was TEST\GhostB.
So now I could compare three different pieces of information for the same operation:
- File Owner: TEST\GhostB
- Security 4663: TEST\GhostB
- Sysmon Event 11: NT AUTHORITY\SYSTEM
At that point I started calling the behavior Principal Collapse.
The name isn’t meant to suggest that I discovered a new Windows primitive. The impersonation mechanism itself is old and well known. What interested me was the attribution difference: Windows was actually authorizing the file operation using the impersonated user’s security context, while the Sysmon Event ID 11 represented that operation using the identity of the SYSTEM process hosting the thread.
I wanted to see what happened with more than one user, so I repeated the test with a second account called TEST\GhostC.
I configured the service so that the same worker thread handled GhostB first and GhostC afterwards. It impersonated GhostB, created a file, returned to SYSTEM, then impersonated GhostC and created another file.
Windows kept those identities separate. GhostB’s file belonged to GhostB and GhostC’s file belonged to GhostC.
Sysmon Event ID 11 showed SYSTEM for both.
- TEST\GhostB NT AUTHORITY\SYSTEM
- TEST\GhostC NT AUTHORITY\SYSTEM
That made the behavior much easier to see. Two different effective security principals went through the same service and ended up represented by the same SYSTEM identity in the resulting Sysmon file telemetry.
I also wanted to see whether this attribution difference could actually change a simple detection decision. So I wrote a deliberately basic lab rule: if SYSTEM performed the file operation, consider it trusted; if another user performed it, alert.
Using only Sysmon Event ID 11, the result was:
That is really the whole point of this experiment.
I didn’t disable Sysmon, delete an event, hide the process name or make the file creation disappear. The telemetry was still there. The interesting part was simply that the identity shown in the Sysmon file event was not the effective user Windows had actually used for the operation.
Again, the building blocks behind this are not new. Named-pipe impersonation is well known, Windows impersonation is documented, and unusual attribution around tokens is not an untouched subject. I am not claiming that I invented any of that.
What I couldn’t find was this exact experiment put together this way: a LocalSystem named-pipe service legitimately impersonating low-privileged clients, permissions proving that the client security context was required for the write, Windows Security auditing and file ownership identifying the client, while Sysmon Event ID 11 attributed multiple different clients to SYSTEM.
Maybe someone has documented the exact same behavior before and I simply missed it. I couldn’t find it, so I decided to test it myself.
In short, a SYSTEM service created files on behalf of GhostB and GhostC using their own security contexts. Windows knew which user was actually behind each operation. Sysmon Event ID 11 showed both of them as SYSTEM.
No disappearing logs. No disabled telemetry. Just a slightly different story about who did it.
For now, I’m calling it Principal Collapse.
Thanks for reading.
See you in the next one.