{ "id": "1b2a3c87-5247-4711-ad01-380e0be3b9e5", "created_at": "2026-04-06T00:16:16.690783Z", "updated_at": "2026-04-10T03:21:04.871579Z", "deleted_at": null, "sha1_hash": "6331945f11da6351fec5744df4f702b6397db409", "title": "The worst of both worlds: Combining NTLM Relaying and Kerberos delegation", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 346863, "plain_text": "The worst of both worlds: Combining NTLM Relaying and\r\nKerberos delegation\r\nPublished: 2019-03-04 · Archived: 2026-04-05 16:55:03 UTC\r\nAfter my in-depth post last month about unconstrained delegation, this post will discuss a different type of\r\nKerberos delegation: resource-based constrained delegation. The content in this post is based on Elad Shamir’s\r\nKerberos research and combined with my own NTLM research to present an attack that can get code execution as\r\nSYSTEM on any Windows computer in Active Directory without any credentials, if you are in the same\r\nnetwork segment. This is another example of insecure Active Directory default abuse, and not any kind of new\r\nexploit.\r\nAttack TL;DR\r\nIf an attacker is on the local network, either physically (via a drop device) or via an infected workstation, it is\r\npossible to perform a DNS takeover using mitm6, provided IPv6 is not already in use in the network. When this\r\nattack is performed, it is also possible to make computer accounts and users authenticate to us over HTTP by\r\nspoofing the WPAD location and requesting authentication to use our rogue proxy. This attack is described in\r\ndetail in my blog post on this subject from last year.\r\nWe can relay this NTLM authentication to LDAP (unless mitigations are applied) with ntlmrelayx and\r\nauthenticate as the victim computer account. Computer accounts can modify some of their own properties via\r\nLDAP, which includes the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. This attribute controls which\r\nusers can authenticate to the computer as almost any account in AD via impersonation using Kerberos. This\r\nconcept is called Resource-Based constrained delegation, and is described in detail by Elad Shamir and harmj0y.\r\nBecause of this, when we relay the computer account, we can modify the account in Active Directory and give\r\nourselves permission to impersonate users on that computer. We can then connect to the computer with a high-privilege user and execute code, dump hashes, etc. The beauty of this attack is that it works by default and does\r\nnot require any AD credentials to perform.\r\nNo credentials, no problem\r\nIf you’ve already read the blog of Elad, you may have noticed that control over a computer account (or any other\r\naccount with a Service Principal Name) is required to perform the S4U2Proxy attack. By default, any user in\r\nActive Directory can create up to 10 computer accounts. Interesting enough, this is not limited to user accounts,\r\nbut can be done by existing computer accounts as well! If we can get any user or computer to connect to our\r\nNTLM relay, we can create a computer account with ntlmrelayx:\r\nhttps://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/\r\nPage 1 of 5\n\nIt is required here to relay to LDAP over TLS because creating accounts is not allowed over an unencrypted\r\nconnection. These computer account credentials can be used for all kinds of things in AD, such as querying\r\ndomain information or even running BloodHound:\r\nRelaying and configuring delegation\r\nLet’s run the full attack. First we start mitm6 to take over the DNS on our target, in this case ICORP-W10 (a fully\r\npatched default Windows 10 installation), I’m limiting the attack to just this host here:\r\nsudo mitm6 -hw icorp-w10 -d internal.corp --ignore-nofqnd\r\nNow it might take a while before the host requests an IPv6 address via DHCPv6, or starts requesting a WPAD\r\nconfiguration. Your best chances are when the victim reboots or re-plugs their network cable, so if you’re on a\r\nlong term assignment, early mornings are probably the best time to perform this attack. In either case you’ll have\r\nto be patient (or just attack more hosts, but that’s also less quiet). In the meantime, we also start ntlmrelayx using\r\nthe --delegate-access argument to enable the delegation attack and with the -wh attacker-wpad argument to\r\nenable WPAD spoofing and authentication requests:\r\nntlmrelayx.py -t ldaps://icorp-dc.internal.corp -wh attacker-wpad --delegate-access\r\nAfter a while mitm6 should show our victim connecting to us as DNS server for the WPAD host we set:\r\nhttps://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/\r\nPage 2 of 5\n\nAnd we see ntlmrelayx receiving the connection, creating a new computer account and granting it delegation\r\nrights to the victim computer:\r\nNext we can use getST.py from impacket, which will do all the S4U2Self an S4U2Proxy magic for us. You will\r\nneed the latest version of impacket from git to include resource based delegation support. In this example we will\r\nbe impersonating the user admin , which is a member of the Domain Admins group and thus has administrative\r\naccess on ICORP-W10 :\r\nWe obtained a Kerberos Service Ticket now for the user admin , which is valid for cifs/icorp-w10.internal.corp . This only lets us impersonate this user to this specific host, not to other hosts in the network.\r\nWith this ticket we can do whatever we want on the target host, for example dumping hashes with secretsdump:\r\nhttps://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/\r\nPage 3 of 5\n\nThe attacker now has full control over the victim workstation.\r\nOther abuse avenues\r\nThis blog highlights the use of mitm6 and WPAD to perform the relay attack entirely without credentials. Any\r\nconnection over HTTP to a host that is considered part of the Intranet Zone by Windows can be used in an\r\nidentical matter (provided automatic intranet detection is enabled). Elad’s original blog described using WebDAV\r\nto exploit this on hosts. Another attack avenue is (again) PrivExchange, which makes Exchange authenticate as\r\nSYSTEM unless the latest patches are installed.\r\nThe updated version of ntlmrelayx is available in a branch on my fork of impacket. I’ll update the post once this\r\nbranch gets merged into the main repository.\r\nMitigations\r\nAs this attack consists of several components, there are several mitigations that apply to it.\r\nMitigating mitm6\r\nmitm6 abuses the fact that Windows queries for an IPv6 address even in IPv4-only environments. If you don’t use\r\nIPv6 internally, the safest way to prevent mitm6 is to block DHCPv6 traffic and incoming router advertisements in\r\nWindows Firewall via Group Policy. Disabling IPv6 entirely may have unwanted side effects. Setting the\r\nfollowing predefined rules to Block instead of Allow prevents the attack from working:\r\n(Inbound) Core Networking - Dynamic Host Configuration Protocol for IPv6(DHCPV6-In)\r\n(Inbound) Core Networking - Router Advertisement (ICMPv6-In)\r\n(Outbound) Core Networking - Dynamic Host Configuration Protocol for IPv6(DHCPV6-Out)\r\nMitigating WPAD abuse\r\nIf WPAD is not in use internally, disable it via Group Policy and by disabling the WinHttpAutoProxySvc service.\r\nFurther mitigation and detection measures are discussed in the original mitm6 blog.\r\nMitigating relaying to LDAP\r\nRelaying to LDAP and LDAPS can only be mitigated by enabling both LDAP signing and LDAP channel binding.\r\nhttps://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/\r\nPage 4 of 5\n\nMitigating resource based delegation abuse\r\nThis is hard to mitigate as it is a legitimate Kerberos concept. The attack surface can be reduced by adding\r\nAdministrative users to the Protected Users group or marking them as Account is sensitive and cannot be\r\ndelegated , which will prevent any impersonation of that user via delegation. Further mitigations and detection\r\nmethods are available here.\r\nCredits\r\n@Elad_Shamir and @3xocyte for the original research and relay POC\r\n@agsolino for building and maintaining impacket and implementing all the cool Kerberos stuff\r\n@gentilkiwi for Kekeo and @harmj0y for Rubeus and their Kerberos research\r\nSource: https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/\r\nhttps://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/" ], "report_names": [ "worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation" ], "threat_actors": [], "ts_created_at": 1775434576, "ts_updated_at": 1775791264, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/6331945f11da6351fec5744df4f702b6397db409.pdf", "text": "https://archive.orkl.eu/6331945f11da6351fec5744df4f702b6397db409.txt", "img": "https://archive.orkl.eu/6331945f11da6351fec5744df4f702b6397db409.jpg" } }