Windows 10 breaks the current version of Invoke-TokenManipulation.ps1 because wininit is now a protected processes. Rather than hardcoding to a specific process to obtain a SYSTEM token, it's better to enumerate all processes running as SYSTEM and find one that works. I have updated the script to version 1.12 and added logic on lines 1689-1696 to make sure it can successfully grab a SYSTEM token necessary to function.
- Changed Remove-VSC to have a single mandatory parameter (DevicePath)
- Updated New-VSC to check initial state of the VSS Service and return
VSS to its inital state after execution
The column headings in the log file are out of order, e.g.
```
"TypedKey","Time","WindowTitle"
"Document1 - Word","[Shift]","01-05-2015:20:53:29:28"
"Document1 - Word","[Shift][Shift]","01-05-2015:20:53:29:31"
"Document1 - Word","[Shift]","01-05-2015:20:53:29:38"
```
The "WindowTitle" should be the first column heading like this,
```
"WindowTitle","TypedKey","Time"
"Document1 - Word","[Shift]","01-05-2015:20:53:29:28"
"Document1 - Word","[Shift][Shift]","01-05-2015:20:53:29:31"
"Document1 - Word","[Shift]","01-05-2015:20:53:29:38"
```
Updated to the latest Mimikatz build. Added sanity checks to ensure that
32bit PowerShell isn't being run on a 64bit OS which will cause Mimikatz
to fail.
Thanks to Run Mariboe for the contribution to Invoke-TokenManipulation
adding the -PassThru flag for newly created processes. Version increased
to 1.11.
Latest version of Mimikatz now natively supports being reflectively
loaded by Invoke-ReflectivePEInjection, updating the script to take
advantage of this new version.
Added a check to ensure the script isn't being run from Session0 with
the "NewWinLogon" flag. This flag does not work in Session0 because
winlogon.exe tries to load stuff from user32.dll which requires a
desktop is present. This is not possible in Session0 because there is no
desktop/GUI, so it causes winlogon to load and then immediately close
with error code c0000142 indicating a DLL failed to initialize. There is
no way to fix this that I know of, if you need to run the script from
Session0 use the "ExistingWinLogon" flag.
This doesn't need to reside in PowerSploit. Those that are truly
paranoid should validate that the embedded executable in
Invoke-Mimikatz.ps1 is indeed mimikatz.
This was causing AV to flag upon downloading PowerSploit.
Processes could not be started when the script was being run from
Session 0. The fix is to use the CreateProcessAsUserW function when
running in Session 0. This API requires SeAssignPrimaryTokenPrivilege
priviege, so for non-session0 calls I still use CreateProcessWithTokenW
which does not require special privileges.
Matt Graeber
PowerShellMafia
FixTheExchange
clymb3r
Jared Atkinson
Jonathan
Chris Campbell