Calling CreateRemoteThread on lsass.
Bug fix: Invoke-DllInjection was checking the processor architecture
when it should have been validating the OS architecture. This would
cause Invoke-DllInjection to fail on a 32-bit OS with a 64-bit
processor.
Latest version of Mimikatz now natively supports being reflectively
loaded by Invoke-ReflectivePEInjection, updating the script to take
advantage of this new version.
Added the following recon functions written by Joe Bialek
(@JosephBialek):
- Find-4648Logons
- Find-4624Logons
- Find-AppLockerLogs
- Find-PSScriptsInPSAppLog
- Find-RDPClientConnections
- Get-ComputerDetails (Combines all of the above functions into a single
function)
All info gathering pieces of this script can now be called individually.
Fixed a bug where the user SID wasn't being converted to a username in
the RDP function.
The function names New-UserPersistenceOption and
New-ElevatedPersistenceOptionNew-ElevatedPersistenceOption now conform
to PowerShell naming best practices.
Get-ComputerDetails is a recon script which pulls a variety of useful
information off a computer which might later be useful by an attacker.
This includes:
Logons
AppLocker process start logs
PowerShell logs to find scripts run
RDP Client saved servers
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.
mattifestation
Chris Campbell
clymb3r