Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Login attempt with wrong domain name with trusted domain can lead to account lockout

Open
  • Is something wrong?
#62 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
csharp
Domain
authentication, security

Research direction

Start with the SharpHound.exe command and trace how --Domain, --domaincontroller, --ldapusername, and --ldappassword are used when collecting data from trusted domains. Reproduce the two-domain setup described in the issue, then verify that repeated collection does not attempt authentication as the trusted-domain username or cause those accounts to lock out.

Written by the indexing model from the issue text.

Description

Description:

I executed SharpHound.exe (Version 2.0.0) on a none-domain-joined machine and provided the target domain, domain controller and ldap credentials via arguments. I expected that all required login attempts to collect the data would use as account name <provided_domain>\<provided_username>. However, when data was collected for trusted domains, the logins were performed using <trusted_domain>\<provided_username>. Since the same user account name existed in the other trusted domains (but with different passwords), this increased the "incorrect login attempts" count. After several executions this lead to a lockout of the user account in all trusted domains.
I'm unsure if this behavior is intended and that I just called SharpHound the wrong way, but I was expecting that all logins would be performed with the ldap username with the provided domain name. Or do I need to also specify the domain with the ldap username argument?

Steps to Reproduce:

  1. Create a network with two domains (DomainA.NET and DomainB.NET and create a trust relationship between them) with the same username in both domains but with different passwords.
    In my case I tested it with a domain administrator account, e.g.: "DomainA.NET\DomainAdmin" with password "Password1" and "DomainB.NET\DomainAdmin" with password "Password2"

  2. Create a Windows Client (in my case it was Windows 10 system which was not domain joined) and execute the following command on the system:

SharpHound.exe --CollectionMethods All,GPOLocalGroup,SPNTargets,LoggedOn --collectallproperties --memcache --Domain DomainA.NET --domaincontroller DC01.DomainA.NET --ldapusername DomainAdmin --ldappassword Password1

  1. Execute the command multiple times until the configured account lockout treshhold is reached. => "DomainB.NET\DomainAdmin" will get locked because SharpHound will attempt to perform a login as LDAP user "DomainAdmin" also in DomainB because of the trust relationship, however, this user has as password "Password2" and not "Password1".

Expected Behavior:

I expected that all logins would be performed as "DomainA.NET\DomainAdmin" user, even when querying data from "DomainB.NET". Actually, I also assumed that no connections to DC01.DomainB.NET would be established and that no logins with accounts in DomainB would be attempted.
I expected that the "--Domain" and "--ldapusername" flags are combined to form the final username which is used to perform the login and not that a login as "DomainB.NET\DomainAdmin" is attempted at all.

Actual Behavior:

A login as "DomainB.NET\DomainAdmin" is attempted which can lead to an account lockout after multiple executions.

Environment Information:

BloodHound: -

Collector: 2.0.0

Dominant language
C#
Stars
1.4k
Forks
264
Avg merge
10m
Merged PRs (30d)
3

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SpecterOps/SharpHound

All issues in SpecterOps/SharpHound

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.