21.07.16 Released Darkexec ver 1.3
• New token output provides Domain\Username, Session, Impersonation Level, Process ID, Thred ID
• No more windows displayed in loopback connections
• Fixed setting ACL in Interactive mode
• Asks session number if is not passed by
• Improved dynamic-lenght buffer for output
• Improved Token search engine performance
• Improved more detailed Error Handling
• Now working on "WORKGROUP" machines too
• Bug fixes


20.01.16 Released Darkexec ver. 1.2
• New access Token search engine. Now all available Users access token on the machine, with highest privileges, are listed and ready to be used.
• New named-pipe service, fixed buffer I/O issue where causing blocking output
• Embedded dex.exe code into dexsvc service, last one is called recursively as executable too.
• Usage simplified defaulting arguments when missing
• Bug Fixes

19.11.15 Released Darkexec ver. 1.1
• Improved Error Handling
• Improved Stability and Bug Fixes
• Added new Icon




Access Token manipulation, a new way to surf 'n a domain.


1. The scenario

A typical scenario is a Windows context and generally a Domain.

Which are the reasons to obtain explicit user's credentials when you already have got some system access to a workstation ?
1. Maintaining access.
2. Gain access to user's environment contents.
3. Take control on the remote user's resources.

Considering that obtain credentials just for access-manteining is stupid, dangerous, logged.

Such disadvantages are exposed using different techniques to obtain access as pass-the-hash or pass-the-ticket ?
1. If handled separate and manually they are not transversal, and hard to use with the different communications protocols.
2. Hard to automate if compared to tools like the famous SMBEXEC.

In this kind of scenario, having access to a machine with administrative privileges, having at least another user's process started, it is possible to gain full access to its security context according to some technique, we can call it pass-the-token.

In the same condition mentioned above, Darkexec, manipulating Users Access Token in all differents Winsta, is a tool made to bypass the Microsoft Windows OS's user-context security boundaries, implemented from win7 to win10, until now (server editions included).


2. Access Token

An "access token" is an object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account associated with the process or thread. When a user logs on, the system verfies the user's password by comparing it with information stored in a security database. If the password authenticated, the system produces an access token. Every process executed on behalf of this user has a copy of this access token.

The system uses an access token to identify the user when a thread interacts with a securable object or tries to perform a system task that requires privileges.

Access tokens contain the following information:

• The security identifier (SID) for the user's account
• SIDs for the groups of wich the user is a member
• A logon SID that idenfies the current logon session
• A list of the privileges held by either the user or the user's groups
• An owner SID
• The Sid for the primary group
• The default DACL that the system uses when the user creates a secureable object without specifying a security descriptor
• The source of the access token
• Whether the token is a primary or impersonation token
• An optional list of restricting SIDs
• Current impersonation levels
• Other statistics

For all the list of functions to manipulate access token please follow the link below

[view references at :]

2. Windows Stations user's session architecture

The diagrams below show the relationships between sessions, windows stations, desktops and services in Windows Vista as compared to earlier operating systems

[view references at :]

This is a classic workstation scheme, having only sessions 0 and 1, 0 for service session and 1 for the unique available user attached to the console. In a terminal server we will have the same layout, just sessions numbers normally start form 2, and there are more than one user logged on..
The user session contains a "Windows Station" (WinSTA) that host by itself 3 (by default) or more desktop (Ex. CTRL+ALC+CANC, Screensaver, user desktop)

for these three objects the sessions 2 and 3 are mutually inaccessible and separate each-others but the service session 0 can interact with both.

N.B. when we talk about "separate", we don't mean "physically", in memory, but only like referenced to the classics callings used by winAPI to make user-token-manipulation.
In fact, the first time everything was carried out writing a kernel mode driver program, editing users token directly, in memory, with the same positive result.. anyway existing system libraries for do that was quite useless and dangerous to use a kernel mode approach.. (Exception made to different situations where a GPO bypass may be required... and we are working on it... ;) )

The following link explain shortly how to apply the basics concepts of a Securable Object to a WinSta or Desktop Objects and why we are talking about:

so windows code isn't public, but you can search and find a lot more about this.. briefly: user mode and GDI32 processes aren't secureable objects, so windows needs to introduce objects like windows stations, desktops and sessions, that are secureable objects instead, as kernell mode processes are, too.

On this layout, SYSTEM calls different functions to modify and duplicate users token, creating processes in the right security context, with relative privileges.
Abusing system functions, an user granted as Administrator can call SYSTEM for code execution, then it can edit user's token to obtain full and redistributable access "acting" in a different security context.


3. develop, practical exploitation

The project is composed by a main distributed executable: darkexec.exe.
The application made a SMB connection to the target, if it’s different from localhost, copying the service executable: dexsvc.
The last runs as a service and, if “connectback” was specified, the client will also start the communication with the named-pipe service.

The service acts and communicate as described:

not interactive mode, it only calls dexsvc.exe in service mode:

1. enables SE_TCB_PRIVILEGE to the calling process.
2. identifies best Access Token from process and threads owned by the users to impersonate - opens processes handle and tokens handle - OpenProcess(), OpenProcessToken().
3. duplicate user token x - DuplicateToken().
4. in connectback execution redirect the input output handles to the calling user PROCESSINFO.
5. modify token’s session if it’s necessary - SetTokenInformation().
6. it “passes” the modified token for execution - CreateProcessAsUser().

interactive mode, make two call to dexsvc.exe: as service and as executable too:

1. gets the commands from the local dexsvc, which holds the pipe for communication
2. identifies best Access Token from process and threads owned by the users to impersonate - opens processes handle and tokens handle OpenProcess(), OpenProcessToken()
3. duplicate user token x - DuplicateToken().
4. in connectback execution redirect the input output handles to the calling user PROCESSINFO.
5. modify token’s session if it’s necessary - SetTokenInformation().
6. modify the ACL for WinSta object and Desktop, it makes an interactive viewable windows graphically correct (no matter psexec!! ^_^ )
7. it “passes” the modified token for execution - CreateProcessAsUser().


Practical demonstration

4. conclusions

Thanks to the Msdn world, Microsoft itself, others people and stuff... :)

We are working a lot to make it better and implement new interesting features, so if you want to help us please report any bugs, anomaly or everything else to


Thank you all, Enjoy !!!




Darkexec - ver. 1.3, #pass-the-token - 32bit | Windows.


If you want to contact us,
send an email to

Follow us

We are on Youtube.

© 2015 - Copyright, all rights reserved.