Introducing RelayKing – Relay To Royalty

Premise:

The Relay Detection & Reporting Problem

If you’re anything like me and/or an offensive security professional, you’re probably very, very familiar with NTLM relaying attacks against Active Directory environments. NTLM relay attacks are anything but novel; pentesters and hackers alike have been forcing blue teams and sysadmins all around the world for decades to pull their hair out as they attempt to mitigate this class of issue. This blog will not explain what this issue is – if you want more information, a quick Google search for “ntlm relaying” will yield numerous excellent blog posts explaining the core issue.

Some may believe NTLM relay attacks are basically dead, but this couldn’t be further from the truth. Most of the time, a lot of testers are probably just missing easily exploitable relay/reflection vectors they just never found due to lack of holistic visibility on the issues responsible for allowing it in the first place.

Wait, just missing them? Isn’t there a lot of public, free tooling to detect issues that allow NTLM relay attacks, like nmap, NetExec (and its numerous very helpful modules), among other tools & options? After all, they do allow you to check signing and channel binding requirements on the most attacked protocols in NTLM relay attacks. Even Nessus will flag hosts that lack SMB signing in scan results, if detected.

Well, do any of these tools allow you to check multiple protocols at once, against multiple targets? Do they support other checks, in tandem with the protocol checks, for issues that facilitate or allow NTLM relay abuse aside from just signing/channel binding configs on protocols? Are they pulling every single computer out of AD, checking every protocol on discovered computers, and checking for the abuse vectors such as WebDAV WebClient and NTLM reflection CVEs? Do any of them allow you to easily report these issues if you do manage to find numerous instances of them?

The answer, unless you know something I don’t (or built it yourself privately), is no.

Existing Solutions

A lot of great tooling exists to exploit these issues already. The first one that comes to mind is Impacket’s ntlmrelayx.py – a tool that RelayKing DOES NOT aim to replace, and instead, significantly augments to make more powerful. The same goes for Responder and mitm6; there’s no need to reinvent the wheel these great relay and protocol poisoning tools we all love.

So, why a new tool?

What is substantially lacking is identification, categorization, taking full inventory of relay attack paths, and then reporting on those issues to clients. Some tools exist currently that do allow identification of relaying issues – specifically, NetExec and its suite of modules now allow you to perform some of these tasks by default. However, reporting issues from these is at best, a little cumbersome to say the least. Not impossible, but certainly not “slick”.

It’s easy for consultants/operators to just miss various, viable relay vectors because they didn’t scan every single subnet/computer advertised in AD, individually, with every single tool in existence, many of which only detect a single kind of issue. It’s not difficult to see how error-prone the current approach is and how much is likely missed because of it.

Further Problems with Existing Tools

This is in no way meant to disparage, discredit, or poke fun at any of the existing tools that are out there for NTLM relaying. As offensive practitioners, we are always standing on the shoulders of giants. But, as I’ve used these tools over the years on engagements, I’ve found a few things I’ve really desired to have that none offer in their current forms:

• Ability to query every single computer object in the domain and check for the issues mentioned below:
• Full identification of all hosts lacking SMB signing, and EPA/channel binding on LDAP+LDAPS, MSSQL, HTTP+HTTPS, RPC, and WinRM+WinRMS.
• Ability to identify all hosts in the environment that have WebDAV WebClient enabled.
• All hosts vulnerable to CVE-2025-33073, an NTLM reflection vulnerability originally downplayed by Microsoft as a local privilege escalation vector. I previously wrote a blog post mentioning how severe the issue truly is.
• Ability to discover Net-NTLMv1 usage outside of just enumerating the domain GPO (most tools just check DefaultDomainControllerPolicy). I’ve found hosts not affected by this GPO can have their own LanMan settings that make them vulnerable, and there was no good tooling to check for this.
• Ability to mass-coerce EVERY domain-joined host all at once for maximum relay impact.
• Generate a relay list to easily plug all identified relay vectors into Impacket’s ntlmrelayx.py for instant path-to-ground for attacking them.
• A tool that can do all the above relatively quickly AND accurately without compromising the amount of data collected.
• Automatically disregard/filter out non-domain-joined resources / non-Windows hosts when doing a domain-wide relay vector audit. (We’ve all seen the Nessus finding for SMB signing not being enforced on a random *nix NAS/file server that you can’t do anything with.)
• And possibly most importantly, after collecting all this information, create a report on all of these specific issues and relaying paths in numerous output formats, allowing us consultants to report every domain-joined, actual risk-generating occurrence of said issues without missing random instances because we failed to scan some random subnet, or forgot to run one of 8+ checks in one section of the network.

No tools offered all these capabilities. In fact, not even one offers a great way to do any one of these without some manual shell/regex magic and even then, the process is prone to issues. Worse yet, as I dove deeper into researching the intricacies of detecting these flaws remotely, I realized that some tools were not being so clear to the user about the reliability of their detection heuristics. Some resources are also just straight up wrong about what makes relaying attacks exploitable in the field.

These blind spots mandated something new: a tool that consolidates and handles all this, without replacing Impacket’s ntlmrelayx.py or Laurent Gaffié’s Responder and instead augments them to allow full relay primitive coverage and target exploitation.

Back to Table of Contents

Enter RelayKing – Upping Your Relay Game:

With all this in mind, I built RelayKing. RelayKing ensures you find all the pesky, hidden relay paths plaguing corporate networks. After it helps you find them and point you towards successful exploitation, it’ll help you report on every individual instance of config and/or patch failures that allow relaying attacks to be successful. No longer will you have to regex various python tool outputs and pipe in target lists manually (unless you want to, it supports that too) – easily and instantly report all relay vectors to your clients for maximum coverage, 100% of the time. Easily build automatic reporting tools around multiple available RelayKing output formats that automate reporting for your team’s unique needs.

RelayKing is a comprehensive tool for identifying various relaying vectors beyond just signing/EPA/channel binding issues but also hosts affected by NTLM reflection CVEs and WebDAV WebClient usage. RelayKing can (usually) identify all these issues by simply providing it with a low-privilege AD user account. And very importantly, RelayKing can report on all these issues in a variety of formats including plaintext, JSON, XML, CSV, grep, and markdown. Here’s a list of basic features it offers:

• Detect lack of signing + channel binding/EPA issues on SMB, HTTP, HTTPS, MSSQL, LDAP, LDAPS, SMTP, IMAP, RPC, WinRM, and WinRMS. (IMAP and SMTP detection is highly untested!)
• Enumeration and cataloging of NTLM relaying vectors by querying AD and each computer discovered.
  • Or, by supplying RelayKing a subnet in either CIDR notation or “IP range” format (i.e. 10.0.0.1-254).
  • Single target mode is also available authenticated or unauthenticated.
• Identification of issues without credentials via targeting a subnet and attempting null authentication.
  • Identification of any authentication coercion vectors available via null authentication such as “PetitPotam”. Reporting on these issues is also available. (Certain protocols are limited for unauthenticated scanning of EPA/channel binding issues)
• Wickedly fast scanning and querying of each selected protocol you choose. We’ve found that an environment with roughly 20,000 live, online computers took about 23 minutes from start to finish when querying SMB, MSSQL, LDAP, LDAPS, HTTP, and HTTPS, plus WebDAV WebClient & CVE-2025-33073 detection alongside the protocol checks. Not bad!
• Domain-wide and individual host NTLMv1 LanMan policy detection via domain GPO read OR RemoteRegistry read against all domain computers. Mass RemoteRegistry read method requires local admin creds usually and probably is not OPSEC safe.
• Individual identification of all WebDAV WebClient-enabled hosts.
• Individual identification of all hosts vulnerable to the CVE-2025-33073 NTLM reflection vulnerability.
• “Coerce All” functionality – coerce EVERY computer in the domain and make it rain machine account authentication to your listener. Obnoxious, and very heavy.
• Relay list generation for instant insertion into Impacket’s ntlmrelayx.py for quick relay target list generation that won’t miss anything you explicitly want to hit. Additionally, the target and URL automatically output to the generated relay target file for HTTP/HTTPS relay vectors.
• Numerous output formats to report from – easily build tools and wrappers around your preferred output style to catalog these issues for reports.
• Tier-zero asset identification (work-in-progress)
• And many more in the future to come!

Back to Table of Contents

RelayKing Usage Examples:

For the purposes of brevity, here’s some important verbiage/acronym explanations:

• “EPA” = “Extended Protection for Authentication.” Also, EPA == Channel Binding, for all intents and purposes.
• “CB/CBT” = “Channel Binding/Channel Binding Token” respectively.

Alright, so you’ve cloned RelayKing from the Depth Security repo, installed the dependencies (in a venv, hopefully), and are sitting in your terminal.
First, print usage args with -h or –help, of course:

There’s a good chunk of arguments, and you may find it useful for me to explain to you how they work because it could possibly be a tad unclear. Also, a friend and very brilliant researcher “@unsigned_sh0rt” (Garrett Foster) lent me his lab for some testing and screenshots for this blog. He is, without question, owed a beer for being generous enough to do this. His research is also top notch, and you would be remiss to not follow it as well.

One-Size Fits All

What you’re probably going to want to do in most cases, if you want the best coverage, is run a command like the one below. If you run any command with RelayKing, the one below or a slight variant of it is probably the best for your use case:

python3 relayking.py -u ‘lowpriv’ -p ‘lowpriv-password’ -d client.domain.local –dc-ip 10.0.0.1 -vv –audit –protocols smb,ldap,ldaps,mssql,http,https –threads 10 -o plaintext,json –output-file relayking-scan –proto-portscan –ntlmv1 –gen-relay-list relaytargets.txt

That will perform the following tasks:

• Connect to the Active Directory domain specified with the -d flag.
• Whenever we pass “–audit“, we ignore any CIDR/individual targets specified and pull from Active Directory.
• Dump every single enabled computer object and their respective FQDNs from AD
• Use multi-threaded, fast DNS lookups to make sure computer FQDNs also resolve to an IP address from the DNS server for the domain’s DNS zone.
• –proto-portscan will then perform a VERY fast port scan against the default ports for any protocols you specified. For this command, ports 80,443,445,389,636, and 1433 will only be checked. If you add other protocols, it will check those too. Don’t worry, this is fast and substantially improves the scan performance by not wasting time attempting to connect to services that aren’t listening.
• After ensuring each host & service it wants to scan are in fact online + available, check the protocols you specified for their signing/channel binding enforcement policies using the provided credentials if necessary. It will only scan the hosts and services that the port scan determines are up and listening to avoid wasting time hanging up threads with timeouts.
• While checking the protocol security attributes, enumerate WebDAV WebClient presence and whether it’s enabled and available for coercion attacks.
• Query the domain LanMan policy for Net-NTLMv1 usage.
• Query UBR (Update Build Revision) from DCERPC to determine if the host is patched against CVE-2025-33073 (NTLM reflection)
• Use 10 primary worker threads for search (dispatches child threads for specific jobs – HTTP/HTTPS work differently and will dispatch 20 sub-worker threads per primary worker thread to search for HTTP NTLM enabled paths on the hosts. This means roughly 200 HTTP/HTTPS discovery threads by default with 10 main threads.)
• Output in both plaintext and JSON format.
• Output the scan results in relayking-scan.txt and relayking-scan.json for reporting needs.
• Output a relay target file named relaytargets.txt

Comprehensive and a lot going on. Here’s an example of the plaintext output “Summary” section:

Understanding RelayKing Output – Summary

Slick. We found only six live hosts from AD, but we found sixteen unique relay vectors. The output should be straightforward to understand in plaintext output mode for most people.

Those vectors include vulnerable HTTP, HTTPS, and LDAP(S) relay endpoints affecting tier-0 hosts (DCs, SCCM). The remainder are SMB/MSSQL relay opportunities, WebDAV coercion, or NTLM reflection paths. Keep in mind that the NTLM reflection abuse info is populated based on partial MIC removal TTPs as described in this blog I wrote during RelayKing’s development. This is why “SMB to LDAP/LDAPS” shows as being possible above when CVE-2025-33073 is in play.

In this case, domain compromise would be trivial by exploiting CVE-2025-33073 against the affected DC (DC01) and relaying to the LDAP(S) service with partial MIC removal. Relaying to MSSQL or SMB on the SCCM hosts would likely also result in domain compromise.

Scan Details Section

We can also drill down into the individual output details for each host we scanned by scrolling down in the plaintext output below the summary. As you can see, each host and protocol checked have their own respective output and details. Useful for screenshots and demonstrating issues on a specific host or instance. If an error was thrown for a check/scan task, you will see it there also:

Relay Target Generation

Our relaytargets.txt also contains the following generated output:

The relay target list generation will automatically include the proper URI scheme for the vulnerable protocol, and when dealing with HTTP/HTTPS, the specific URL(s) vulnerable to relay. We can plug this into Impacket’s ntlmrelayx.py immediately if we want, although I’d recommend pruning the output for more specific targets, especially in larger environments where a lot of junk you probably don’t want to target will end up in there.

JSON Scan Output

JSON files have a predictable structure. For example, you can pull all relay paths from the JSON output with a JQ expression to key on .relay_paths like the one below:

Or, without cat:

HTTP/HTTPS Audit Notes

Keep in mind that if you enable HTTP/HTTPS based checks, it checks ~50+ common NTLM-auth enabled paths on each server before it’ll validate discovered paths are genuinely vulnerable to NTLM relay. This can be quite heavy and time consuming in some environments although it’s VERY fast in my experience – likely faster than you expect it to be. If there’s a better way to do this, I’m unaware of it.

When dealing with ADCS / SCCM / Exchange servers, it attempts to detect them and mark them as critical/high-value relay targets for HTTP(S). The detection is not perfect and needs some serious work. I’ve shamelessly copied Garrett Foster’s sccmhunter and Oliver Lyak’s Certipy for AD queries/logic to detect these. It could be better though, and PRs are very welcome. Tier-zero asset detection in general needs work. If I spend months implementing this stuff by myself, it will never get done.

Back to Table of Contents

RelayKing – Scan Performance:

RelayKing offers above-average scan performance, in my humble opinion. I’ve had the opportunity to run it within some rather large enterprise environments with numerous checks enabled. Below is the overall scan performance for smb,mssql,ldap,ldaps,http,https + other concurrent side-checks on a network containing roughly 19,250 live hosts:

1,413 seconds is equal to approximately 23 ½ minutes. Active Directory originally reported well over 40,000+ computer objects, but it was trimmed down to the 19.25k after DNS resolution + port scans occurred. I personally consider this beyond acceptable performance, considering the task at hand. I suspect it will perform relatively well in even larger environments, provided DNS and available network bandwidth aren’t significant bottlenecks.

I’ve also implemented aggressive timeouts on some of the checks to ensure primary detection worker threads aren’t hung for too long.

Back to Table of Contents

Relay Detection Logic – Notable Caveats:

To reiterate…

LDAP/SMB/XYZ Signing = Signing is its own thing, protocol specific, and relies on a session key derived from the target principal’s NT hash. This prevents relay (with Net-NTLMv2) because relay operators lack the relay victim principal’s NT hash or the ability to derive it. Deriving it properly would imply relay operators would know the user’s hash or plaintext password, which would negate the purpose of relaying entirely.

Channel Binding == EPA (Extended Protection for Authentication) are functionally identical to one another and require TLS 1.0 to negotiate at minimum. EPA requires cryptographically valid CBT (channel binding token), typically derived from the server’s TLS certificate that both client and server agree upon, ensuring a meddling party hasn’t intercepted and manipulated traffic. Sadly, this is exactly what we want to do most of the time as relay operators, and it prevents this in most circumstances.

Plaintext protocols CANNOT implement channel binding – they inherently require an encrypted TLS session for enforcement. Plaintext HTTP cannot support channel binding. Neither can plaintext LDAP, and so on and so forth. However, plaintext LDAP can support LDAP signing. HTTP doesn’t have a signing feature, only CB/EPA. Generally, TLS services with channel binding = no more relay (Usually, most of the time).

Enough technical jargon and acronyms yet? I know, it’s putting the classic “retro encabulator” video to shame with the volume of terminology.

Anyways, even the above gets questionable when we start bringing Net-NTLMv1 authentication and/or NTLM reflection issues like CVE-2025-33073 into the picture. A lot of existing write-ups and blogs on this are not accurate, which is not helpful. This is absurdly confusing to try and follow, and I don’t blame people for getting it wrong. The actual truth feels like a lawyer’s default, concise answer for every legal question in history – “It depends.”

Asking AI Basic LDAP/LDAPS Relay Questions

Well, if the technical blogs are missing details (or at least partially lacking notable caveats/circumstances/factors that allow for exploitation), maybe AI agents/LLMs are less inaccurate. Let’s give them a shot. For models, I selected the most expensive, deep-thinking, intelligent models for each service. This is (supposed) to prevent random slop that some of the fast/instant models on some AI services produce. I used the same prompt for every single popular AI service:

GPT 5.2 Thinking seems to believe that LDAP signing does not prevent NTLM relay attacks, and that CBT is the only thing that breaks NTLM relay:

Perhaps it’s being pedantic. Indeed, maybe it’s so intelligent that it knows the authentication itself will in fact “succeed” with only signing enabled (without CB) but fails to mention the caveat that taking any actions after the “successful” authentication will fail due to the lack of a properly calculated session key. Even if overly pedantic, it still omits key details about how signing works and the behavior you’ll experience if you create this scenario yourself.

If you’re already familiar with how protocol signing works in Windows (or you read the beginning of this section), you’ll know that the “message integrity” part GPT is referring to relies on a session key that can only be derived properly from the relay victim principal’s NT hash (NOT their Net-NTLMv2 hash) and then included inside of NTLMSSP, which we don’t have in a standard relay context. Once again, this is because we’re relaying Net-NTLMv1/v2 auth and NOT NTLM handshakes containing NT hashes. If we had the NT hashes, we wouldn’t need to relay at all since we would just use said NT hashes to authenticate without any relay nonsense. This may seem painfully obvious and repetitive, but it’s important to note to understand how blatantly untrue the statement “LDAP signing does not stop SMB relay” is.

Bottom line – without the session key properly calculated based on the victim principal’s NT hash, any actions taken after authentication will fail. My previous blog demonstrates this exact behavior on SMB and RPC with signing enforced if you want to see it for yourself.

Google Gemini also seems to think signing-only on LDAPS leaves you vulnerable:

Confused yet? Since when do servers just ignore mandated protocol signing requirements attested within NTLMSSP because the authentication happened over TLS? News to me.

Grok doesn’t seem to really do much better on this issue either:

I am entirely unsure what Grok is talking about with the second and third bullets. I am confident nearly all of this is gibberish made up out of thin air. If channel binding is enforced, NTLM authentication fails entirely. The CBT in the victim’s NTLM response (if any) won’t match the relay operator’s theoretical TLS session. Auth is rejected. There’s no session to tamper with. How exactly would an attacker “use an unprotected session after successful non-relayed auth” in a relay attack?

Further, Grok seems to be conflating MIC removal attacks (originally outlined in CVE-2019-1040) that allow you to force relayed client authentication to advertise to the target server that the client doesn’t support signing and to downgrade/allow an unsigned session. This works because without the MIC, we can happily strip SIGN flags within NTLMSSP and not invalidate the MIC (since it’s not there anymore). Which won’t work if the server mandates signing – you can lie all you want to the server, but if it’s mandated, it’s mandated (in standard, vanilla relay contexts over Net-NTLMv2 w/ MIC removal).

The patch for CVE-2019-1040 made the MIC mandatory when certain flags are negotiated within NTLMSSP. But MIC removal does work with Net-NTLMv1 authentication since Net-NTLMv1 doesn’t support computing a MIC within NTLMSSP. Due to this, we can strip signing flags from NTLMSSP freely without worrying about corrupting a MIC. Additionally, Net-NTLMv1 does not support MsvAvChannelBindings (simply the channel binding token’s hash), or MsvAvFlags (indicates/advertises EPA/CBT) within the AV_PAIRs field for NTLMSSP’s NtChallengeResponse. Without these flags, channel binding cannot succeed.

Better yet, relay from SMB via Net-NTLMv2 -> LDAPS with both channel binding + signing works with CVE-2025-33073 reflection because of partial MIC removal tactics and quirks involving NTLM local authentication prior to the patch that fixed CVE-2025-54918. Not confusing at all, right?

Claude 4.5 Opus seems to have a better (best?) understanding of the issue, as far as I can tell:

Relay Viability Caveats – Yes/No Is Wrong – It Always Depends

The above output from Opus 4.5 is true for Net-NTLMv2. And again, none of this is universally true if you support Net-NTLMv1 authentication or have unpatched NTLM reflection issues like CVE-2025-33073. You can relay to LDAP(S) anyways, irrespective of CBT/signing requirements with that CVE or Net-NTLMv1 in play. Numerous other cross-protocol relays also work. With Net-NTLMv1, supposedly, SMB signing becomes entirely negated with specific abuse tactics. A snippet from a blog from Praetorian seems to indicate as such as well:

(Side note: I should probably implement this attack in ntlmrelayx.py for easy-mode NTLMv1 abuse.)

Anyways. If you’re wondering where I found a north star, single source of truth for “relay works or relay doesn’t work based on XYZ”, you’ll be disappointed to learn that I haven’t at this point. I’ve found numerous blogs that state variants of everything the LLMs above repeated, most of them being partially untrue. The closest is probably Andrea Pierini’s blog but it generally covers more advanced tactics. The basics, apparently, are still very confusing to everyone.

I’ve been forced to draw from experiences in the wild, behavior in labs, and validation of each specific control in each possible configuration to figure out the truth.

Alright, onto the actual logic I settled on for RelayKing.

Back to Table of Contents

Protocol Detection Logic – Signing + EPA/Channel Binding Enforcement:

Detection logic is straightforward and uses widely known methods for most protocols. SMB, LDAP/LDAPS, and MSSQL should really come as no surprise as to how they’re checked. Inspiration and detection logic also very much a coalescence of Nick Powers’ RelayInformer and various NetExec detection implementations. Basically, any instance of LDAP lacking signing or LDAPS lacking both channel binding and signing are vulnerable. SMB signing is obvious. MSSQL as well.

HTTP/HTTPS

For HTTP, this is relatively straightforward. For plaintext HTTP, we can pretty much always assume a relay is possible because plaintext HTTP does not support CBT over a plaintext network socket, inherently. Plaintext HTTP + NTLM enabled web path without mandated upgrade to TLS 1.0 or higher = free relays, always.

HTTPS is a little tricker. We need valid credentials and to provide a bogus CBT, a valid one, and omitting the CBT entirely after finding a NTLM-enabled path/endpoint. Based on the server response, we can figure out the EPA policy set in IIS. This is an acceptably reliable (i.e. the most reliable I know of) check for HTTPS EPA enforcement. If the login doesn’t succeed/user doesn’t have permissions to log into the endpoint, detection may not be the most reliable in some cases. We can demonstrate this in the lab.

See below:

We take a conservative approach with EPA detection on HTTPS. As I mentioned, if the user RelayKing runs as lacks permission to authenticate to a web endpoint it discovers, it can’t reliably validate that EPA is enforced and marks it as not relayable. This is done to prevent false positives but could result in false negatives for certain circumstances. There’s not a good way around this as far as I know. Example in the figure below:

Why? For some reason, the low-priv user did not have permission to authenticate to the HTTPS endpoint mirrored from the HTTP service. But it could for the HTTP one. Why? I have no idea. Because EPA is per-endpoint and per auth provider in IIS, it’s also possible for some endpoints to have it enabled and others not. We can’t just assume because one does or doesn’t have it enforced; the others follow suit. Unlikely, sure, but an edge case we need to account for regardless.

Since we can’t detect it reliably here, we mark it as “None” rather than True/False and don’t count it as a relayable target. However, the endpoint in question does in fact lack EPA and is relay-able despite our inconclusive result. When I ran RelayKing again with domain admin credentials instead of a low-privilege one, the path/URL was found to be affirmatively lacking EPA. Because the DA account could authenticate properly, it could check for certain and avoid speculation. Run your audits with DA creds if you want to ensure this caveat is always mitigated. This probably needs more research.

RPC

RPC is relatively straightforward. If we can successfully authenticate using RPC_C_AUTHN_LEVEL_CONNECT or RPC_C_AUTHN_LEVEL_CALL – we know that no encryption/signing requirements are enforced. If we successfully authenticate, we can pull some more detailed information via EPM.RPC_C_EP_ALL_ELTS to return all the individual capabilities the RPC server supports, giving a definitive answer nearly always. You usually can’t do a whole lot with RPC anyways (sans ADCS RPC enrollment), but this may be useful to someone at some point. Here’s a table displaying the typical attack requirements:

WinRM/WinRMS/IMAP/SMTP

For WinRM/WinRMS, you’ll likely find that regular WinRM is useless because it usually requires a session is signed with a session key, once again derived from a user’s NT hash and their username. This is usually not possible to ever acquire in the context of a relay. For WinRMS, the current logic is so, so bad and needs work. I never find WinRMS available anyways, so whether you’ll find value from it is questionable. Please, submit a PR (or I’ll fix this myself when I have time.)

IMAP/SMTP detection is highly untested, although it works in the one lab I’ve tried it in. Needs work!

Back to Table of Contents

Detection Logic – Other/Misc Checks:

These are straightforward.

WebDAV WebClient

For WebDAV WebClient, we connect to the IPC$ share on a host and search for the named pipe corresponding to “DAV RPC SERVICE”. If it’s enabled and the pipe exists, WebClient is running and enabled.

If we receive an error from the IPC$ check, we log it and don’t mark it vulnerable:

CVE-2025-33073 + CVE-2025-54918

For CVE-2025-33073 NTLM reflection, we query UBR (Update Build Revision) from DCERPC to determine if the host is at a patch level before or after the June 2025 security update that fixed the issue. If the build version is prior to this update, we know it’s vulnerable to the flaw and will mark it as such.

For Server 2025 domain controllers that are beyond the 33073 patch level, but PRIOR to the patch that resolves CVE-2025-54918, they are flagged as well. PrintSpooler is also checked when this condition is met for PrinterbugNew exploitation.

NTLMv1/LanMan

For NTLMv1/LanMan domain policy (–ntlmv1), we query GPOs to find a policy that explicitly sets it. Easy enough.

If we specify the arg “–ntlmv1-all”, RelayKing will attempt to use remote registry to query the registry value for each host in the domain to look for exceptions or hosts that set their own individual policy. This is typically only successful with a local admin credential. This allows you to find gaps on workstations and servers that don’t have an over-arching policy applied to them. This may seem very redundant and unnecessary, but I’ve seen it before and would have missed it had I not manually tried to coerce every computer in the domain.

If it isn’t obvious, it’s very noisy when we use the –ntlmv1-all flag since we’re querying RemoteRegistry for all domain computers, presumably with administrative credentials. This could cause EDR solutions to throw alerts. Beware.

Back to Table of Contents

Coerce Functionality:

RelayKing also offers –coerce-all as an option. You specify this with –audit. When you specify this, it coerces every computer in the domain with PetitPotam, DFSCoerce, and PrinterBug. This is heavy and it goes without being said, not OPSEC safe whatsoever. But it’s fun and you can rain machine account Net-NTLM auth by doing this. By default, it will coerce with all three methods above, so you’ll get three auth handshakes via Net-NTLMv1/v2 when it succeeds.

Back to Table of Contents

OPSEC Considerations:

If you haven’t guessed or figured this out at this point, this is not an OPSEC-considerate tool in nearly all cases. You WILL generate alerts. You are authenticating, in some cases, to tens of thousands of services & hosts and querying information that could set off EDR or SIEM alerts. It uses Impacket and ldap3 libraries, which are well fingerprinted by many security solutions at the time of writing in early 2026. I am considering making an –-opsec-safe mode that doesn’t use these well-known libraries to help evade this and get better results, but it’s not a high priority currently.

Back to Table of Contents

Post-Introduction Tool Housekeeping

To-Do’s:

• Lot more testing (YOU CAN HELP – See GitHub)
• Create usage wiki.
• Implement mass shell-abuse file dropper (.scf, .searchConnector-ms) across all accessible shares and nest them properly. Implement –cleanup alongside it for seamless removal at the end of your engagement. Existing tools accomplish this, but not in the manner I’d really prefer them to.
• Kerberos relaying + paths. Create logic surrounding all krb relay techniques including reflection. This is not trivial.
• –opsec flag to switch from fingerprinted Python libraries. Not high priority. See Known Bugs/Limitations.
• Fix WinRMS detection – see known bugs/limitations.

Back to Table of Contents

Known Bugs/Limitations:

• Potential issues with Impacket protocol handlers getting blocked by EDR. In the future, possible implementation of alternative network libraries for signing/cbt/epa with –no-impacket or –opsec to switch from Impacket to OPSEC safe libraries. Not trivial and not massive priority currently. If widespread issues are encountered (which they haven’t at the time of writing in January 2026), this could be expedited for implementation potentially.
• Semi-busted checks when using strictly Kerberos auth for various protocols. Avoid specifying without –krb-dc-only
• UBR check falsely reporting certain Windows 11 builds as “older + unknown” Windows versions. No FP/FN from it, but silly.
• Cannot check MSSQL/HTTPS/LDAPS EPA/CBT from unauthenticated context reliably. Probably needs extra research.
• Funky RPC behavior on Windows 11 hosts. Suspected Impacket quirks. RPC in general could use more improvement but RPC is typically low impact relay protocol so not highest priority.
• Downright bad detection logic for WinRMS. Just needs an overhaul.
• Potentially odd behavior in environments with poorly configured DNS.

Back to Table of Contents

Submitting Issues/PRs:

PRs are ALWAYS welcome. Any more functionality I can get add in that improves the tool for everyone = everyone wins.

For issues, please do not submit issues without adequate detail and documentation to troubleshoot the issues. Running the tool with -vvv should be a default consideration, and any other information such as packet captures, verbose output from other tools than RelayKing, or any other pertinent troubleshooting information is necessary to diagnose and fix issues with the tool.

See GitHub for more information.

Back to Table of Contents

Conclusions and Caveats:

So, to conclude, RelayKing has become a crucial part of our toolkit and allows us to find far more vectors for NTLM relay that we simply had no way of easily identifying prior to its existence without loads of manual leg work. This is beneficial to our clients in a major way, and it will be for yours also. It is not perfect, has bugs, and needs work to become what it should be – the universal relay-identifying companion you should run on every test. But it is about 90% of the way there, and you will likely find additional value from running it on your engagements today, right now.

For defenders, the same benefits can be yielded from usage of RelayKing in a defensive manner. RelayKing empowers defenders to be able to audit every host in their Active Directory environment for these misconfigurations and allow them to fix the most trivial attack vectors threat actors and pentesters love to exploit. You will find straggler hosts in your environment you thought had policies applied to them to fix these issues, but for one reason or another, did not apply properly. Variable report output formats allow mangling of data and importation into other tools/reporting systems.

Back to Table of Contents

Recommendations:

For Attackers

Incorporate RelayKing into your assessment workflow and find more high-impact NTLM relay vectors. Experiment, tinker, and find bugs in the tool. Share your experiences and any paths to a win you found with me on LinkedIn, X, or GitHub.

For Defenders

Enable signing and channel binding on all protocols, everywhere, all the time. Make it a serious, high-priority effort in your organization. Without unreasonable delay, apply all Windows security patches in a timely manner to prevent NTLM reflection primitives. Disable WebDAV WebClient where it’s not necessary to prevent authentication coercion attacks. Request that vendors, particularly those with legacy, proprietary software suites that do not support technologies like signing and channel binding, support these security controls.

Forcing an organization to expose themselves to severe, easily exploited risks because an application that controls an office thermostat, or something along those lines, relies on having SMB signing and LDAP signing disabled to work, is NOT a reasonable request from a software vendor in 2026. Be resistant to tolerate risk around this issue by default. Exceptions should be exceedingly rare.

(I know this sounds like an overly specific example, but it is always things like this. No hate on web-thermostat-admin-application-vendors!)

If you’re using Net-NTLMv1 or allowing it within your environment, remove and decommission any services reliant on it since there is no way to mitigate relaying attacks properly while supporting Net-NTLMv1. If vendor products are reliant on this protocol suite and block removal of support in your organization, consider contacting the vendor and asking (politely demanding) a patch that remediates the issue(s) necessitating Net-NTLMv1 support. If the vendor is unable, or uncooperative in doing so, seek alternative solutions/products from vendors that support modern authentication suites and are not reliant on DES-based protocol suites designed in 1993. Multiple services such as crack.sh and ntlmv1.com offer free online cracking of any Net-NTLMv1 hash with a specific challenge. The challenge is the numeric sequence “1122334455667788” and all SMB auth capture tools such as Responder and Metasploit allow specifying this challenge.

Further reading on Net-NTLMv1 weaknesses and just how trivially they can be exploited with free online resources in 2026 can be found here.

Back to Table of Contents

Author Bio

Logan Diomedi

Logan Diomedi is a Principal Offensive Security Consultant at Depth Security. He brings a wealth of knowledge from his IT and systems administration background that meshes directly with his lifelong passion for offensive security. Logan has spoken at information security conferences such as BSides Roanoke and also performs independent security research in his free time.

X – https://x.com/relay_royalty

LinkedIn – https://www.linkedin.com/in/logan-d-b9b62788/

GitHub – https://github.com/logansdiomedi