Skip to main content
Before reporting an issue, run with -vv or -vvv to get detailed debug output. Most problems become clear with increased verbosity.
Symptom: RelayKing enumerates computers from AD but cannot resolve any hostnames. Scan targets appear empty or all hosts fail immediately.Cause: Your testing host’s DNS is not configured to query the domain’s DNS server, so domain computer FQDNs cannot be resolved.Fixes:Force RelayKing to use a specific DNS server with --dc-ip, which is also used for DNS resolution:
python3 relayking.py \
  -u lowpriv -p pass \
  -d client.domain.local \
  --dc-ip 10.0.0.1 \
  --audit \
  --protocols smb,ldap,ldaps,mssql
Alternatively, point a custom nameserver at the domain controller directly with -ns:
python3 relayking.py \
  -u lowpriv -p pass \
  -d client.domain.local \
  --dc-ip 10.0.0.1 \
  -ns 10.0.0.1 \
  --audit \
  --protocols smb,ldap,ldaps,mssql
Or edit /etc/resolv.conf on your testing host to add the domain controller as the primary nameserver:
nameserver 10.0.0.1
If the domain’s DNS server refuses to resolve FQDNs for domain computers, that is a network configuration issue — not a RelayKing bug.
Symptom: RelayKing cannot connect to LDAP, AD enumeration fails, or --audit mode exits early with a connection error.Checks:
  • Verify the domain name is correct: -d client.domain.local (use the full domain, not a NetBIOS name).
  • Verify --dc-ip points to an accessible domain controller IP.
  • Confirm the DC is reachable on port 389 (LDAP) or 636 (LDAPS):
nc -zv 10.0.0.1 389
nc -zv 10.0.0.1 636
  • If the DC requires LDAPS, add --ldaps:
python3 relayking.py \
  -u lowpriv -p pass \
  -d client.domain.local \
  --dc-ip 10.0.0.1 \
  --ldaps \
  --audit \
  --protocols smb,ldap,ldaps
  • Run with -vvv to see the exact LDAP error:
python3 relayking.py -u lowpriv -p pass -d client.domain.local --dc-ip 10.0.0.1 --audit --protocols smb -vvv
Symptom: Scan runs for a long time per host, timeouts are frequent, or overall scan time is unacceptably slow.Fix — use --proto-portscan:This flag performs a fast port scan before running protocol checks. It skips protocol checks entirely for closed ports, avoiding timeout waits. This is the single biggest performance improvement available:
python3 relayking.py \
  -u lowpriv -p pass \
  -d client.domain.local \
  --dc-ip 10.0.0.1 \
  --audit \
  --protocols smb,ldap,ldaps,mssql,http,https \
  --proto-portscan
Fix — reduce threads:If the network is becoming a bottleneck, lower --threads (default 10):
--threads 5
Fix — adjust timeout:Reduce the per-connection timeout if hosts are consistently unresponsive (default 5 seconds):
--timeout 3
Fix — use scan grouping:For very large domains, split the scan into groups with --max-scangroup or --split-into to track progress and resume more easily if the scan is interrupted.
Symptom: RelayKing exits before scanning starts with a message like Given credential looks invalid or similar.Cause: RelayKing validates credentials against the domain controller via LDAP before starting a scan. This safety check prevents account lockouts from running a full scan with invalid credentials. If the credential check fails, the scan will not proceed.Checks:
  • Confirm the username, password, and domain are correct.
  • Verify --dc-ip points to a reachable DC.
  • If the DC requires LDAPS for the credential check, add --ldaps.
  • For Kerberos, ensure KRB5CCNAME is set and the ticket is valid (klist).
  • Run with -vv to see the exact error returned from the DC.
This pre-check is intentional — it prevents running thousands of authentication attempts with a locked or invalid account. If the check fails, fix the credentials before retrying.
Symptom: RelayKing reports authentication errors, access denied responses, or produces no results despite valid-looking credentials.Checks:
  • Confirm credentials are correct by testing them independently (e.g., with smbclient or netexec).
  • For --audit mode, a low-privilege domain account is sufficient — no admin rights needed for basic enumeration.
  • For --ntlmv1-all, local administrator credentials are required on each target. Standard domain credentials will not work for reading the registry.
  • For pass-the-hash, provide hashes in LMHASH:NTHASH format:
--hashes 'aad3b435b51404eeaad3b435b51404ee:a87f3a337d73085c45f9416be5787d86'
  • Run with -vv to see which authentication attempts are failing and why.
Symptom: --ntlmv1-all does not return registry data for some or all hosts.Cause: RemoteRegistry service is disabled on the target hosts.Note: This is not a RelayKing bug. --ntlmv1-all reads LmCompatibilityLevel from each host’s registry via RemoteRegistry. If the service is disabled on a host, that host’s value cannot be read.Use --ntlmv1 (without -all) instead to check the domain-wide GPO setting, which does not require RemoteRegistry or admin rights:
--ntlmv1
Running --ntlmv1 is also the minimum requirement to enable cross-protocol SMB relay path detection in the report.
Symptom: HTTP or HTTPS results appear incorrect — either reporting relay-able when the service is not, or missing relay-able services.Note: Some HTTP services behave in non-standard ways that are difficult to account for. HTTP detection is inherently less reliable than SMB or LDAP checks. Edge cases with HTTP(S) services that produce false results are a known limitation.Workaround:
  • Run with -vv to see the raw HTTP responses RelayKing is evaluating.
  • Manually verify suspicious results by checking the HTTP/HTTPS endpoint directly.
  • If you are seeing consistent false positives with a specific service type, consider opening an issue with -vvv output.
Symptom: --session-resume fails to load, reports errors, or produces unexpected behavior.Checks:
  • Confirm the session file exists at the path you are providing:
ls -la relayking-session.resume
  • Verify you are running the resume against the same target environment. Session files store the resolved target list and scan state — resuming against a different domain or credential set will produce incorrect results.
  • If the original scan completed successfully (phase complete), resuming it will load the session but find no remaining work. Start a new scan instead.
  • Run with -vv to see what state is being restored from the session file.
Symptom: Kerberos authentication fails, tickets are not used, or scan exits with Kerberos-related errors.Checks:
  • Confirm KRB5CCNAME is set to the correct ccache file path:
export KRB5CCNAME=/tmp/lowpriv.ccache
echo $KRB5CCNAME
  • Use an FQDN (not an IP address) for --dc-ip when using Kerberos. Kerberos requires a hostname for proper name resolution:
--dc-ip dc01.client.domain.local
  • If the environment has DCs that require Kerberos but member servers accept NTLM, use --krb-dc-only to avoid Kerberos-related failures on non-DC hosts:
-k --krb-dc-only
  • Use --no-pass with -k when authenticating via ccache to suppress password prompts:
-k --no-pass
  • Run with -vvv to see detailed Kerberos negotiation output.

Build docs developers (and LLMs) love

Get started for freeTalk to us