Make Token
The make_token command allows you to impersonate a user if you know their plaintext password. This works under the hood by calling the LogonUserA API, which takes several parameters including a username, password, domain name and logon type. In this instance, the LOGON32_LOGON_NEW_CREDENTIALS logon type is used, which allows the caller to clone its current token and specify new credentials for outbound network connections.
The API outputs a handle to a token which can then be passed to the ImpersonateLoggedOnUser API. This allows the calling thread to impersonate the context of token (i.e. the impersonated user's context).
\
The logon session created with LogonUserA has the same local identifier as the caller, which is why, somewhat confusingly, you see "impersonated <current user>" in the console output. But the alternate credentials are used when accessing a remote resource.
\
The getuid command will also return the local identifier of the current process, and this does make it hard to track whether or not your Beacon is currently impersonating a user via make_token.
\
When in doubt, use rev2self to drop any impersonation that may be in play. This also means that make_token is not applicable to anything you may want to run on the current machine. For that, spawnas may be a better solution.
These logon events can be found in Kibana with the following query:
\
Where 4624 is the "An account was successfully logged on" Event ID and LogonType 9 is LOGON32_LOGON_NEW_CREDENTIALS. The events will show who the caller was, what user they impersonated, the calling process name, ID, and more.
\
\
One unfortunate downside to detecting this technique is that runas /netonly behaves in the same way. So it may be difficult to distinguish legitimate and malicious events.
Last updated
