addcomputer.py Does not set machine object attributes (dnsHostName, SPNs, etc) when creating over SAMR

[b1gbroth3r]

Configuration

impacket version: Impacket v0.9.23.dev1+20210504.123629.24a0ae6f - Copyright 2020 SecureAuth Corporation Python version: 3.6 & 3.9 Target OS: Ubuntu & Kali

Debug Output With Command String

python3 addcomputer.py evilcorp.local/leon:<password> -method SAMR -computer-name rbcdFromLinux -computer-pass Password123 -dc-host dc01.evilcorp.local -dc-ip 192.168.2.10 -debug
Impacket v0.9.23.dev1+20210504.123629.24a0ae6f - Copyright 2020 SecureAuth Corporation

[+] Impacket Library Installation Path: /home/b1gbroth3r/.local/lib/python3.8/site-packages/impacket
[*] Opening domain EVILCORP...
[*] Successfully added machine account rbcdFromLinux$ with password Password123.

Additional context

The expected result is to have a new computer object created with the populated attributes being set on lines 217 -229. However, querying the new object with pywerview or viewing it in the GUI from the DC reveals this output:

accountexpires:         never
badpasswordtime:        1600-12-31 18:00:00
badpwdcount:            0
cn:                     rbcdFromLinux
codepage:               0
countrycode:            0
distinguishedname:      CN=rbcdFromLinux,CN=Computers,DC=EVILCORP,DC=LOCAL
dscorepropagationdata:  1601-01-01 00:00:00
instancetype:           4
iscriticalsystemobject: FALSE
isgroup:                False
lastlogoff:             1600-12-31 18:00:00
lastlogon:              1600-12-31 18:00:00
localpolicyflags:       0
logoncount:             0
ms-ds-creatorsid:       S-1-5-21-3737425248-4185734480-769832259-1156
name:                   rbcdFromLinux
objectcategory:         CN=Computer,CN=Schema,CN=Configuration,DC=EVILCORP,DC=LOCAL
objectclass:            top,
                        person,
                        organizationalPerson,
                        user,
                        computer
objectguid:             e4df1e58-e0c2-44f5-9083-84cdb60e8858
objectsid:              S-1-5-21-3737425248-4185734480-769832259-1190
primarygroupid:         515
pwdlastset:             1600-12-31 18:00:00
samaccountname:         rbcdFromLinux$
samaccounttype:         805306369
useraccountcontrol:     ['PASSWD_NOTREQD', 'WORKSTATION_TRUST_ACCOUNT']
usnchanged:             27348
usncreated:             27345
whenchanged:            2021-05-11 06:44:42
whencreated:            2021-05-11 06:44:42

[jagotu]

Interesting. I don't remember how the domain enroll on Windows populates those fields. However, as a workaround when those are necessary, I think it should be possible to just connect to ldap using the added machine account and populate them.

[0xdeaddood]

Hi @b1gbroth3r!

Thanks for pointing this out. The script doesn't complete the final steps in the process of joining a client computer to a domain via the SAMR protocol. As you mentioned, the LDAP attributes dNSHostName and servicePrincipalName are not populated as requiered in [MS-WKST] 3.2.4.13.2 and detailed in the Appendix A71 .

We are going to work on this. In the meantime, you can use the workaround that @jagotu suggested.

[0xdeaddood]

Interesting. I don't remember how the domain enroll on Windows populates those fields. However, as a workaround when those are necessary, I think it should be possible to just connect to ldap using the added machine account and populate them.

I've been digging a little bit on this and I found that [MS-ADOD] section 3.1.2 describes the complete process of domain joining via SAMR. The last steps (27-32), referred to as "Update client computer account" in the specification, are executed via LDAP. In those steps, the attributes dNSHostName and servicePrincipalName are updated. It seems that we can't execute the flow only through SMB.

However, it would be nice to complete the entire joining process via SAMR. For this, we would need to refactor the code to be able to reuse some LDAP functions in the SAMR flow. In turn, we should think about the cases where LDAPS would not be available. What do you think @jagotu?

And as usual, PRs are welcome 😃

[jagotu]

Well, this is complicating the matters a bit. No matter what we choose, I think we should keep the only-SAMR (without any LDAP) choice, cause for S4U2 attacks the "uncomplete" machines seem to be fine.

Another thing to note is that while creating the computer account requires LDAPS (as the DC won't allow you to set unicodePwd over LDAP), updating dNSHostName and servicePrincipalName should work just fine over plain LDAP.

Therefore I think the possible network conditions (and the scenarios we could support) are:

1. LDAPS accessible - just use it for everything and don't use SAMR
2. SMB+LDAP accesible - create a complete account by using SAMR and doing the final step over LDAP
3. Only SMB accessible - create an uncomplete account using SAMR

Currently the script supports scenarios 1 and 3. This issue asks for number 2.

My only current concern about implementing the new variant:

I believe things will get messy with kerberos -- AFAIK impacket kinda only creates and expects one-ticket-per-file ccaches. Therefore I can imagine in some cases of weird kerberos delegation attacks and getST.py usage you'll have to juggle around tickets for cifs/DC and ldap/DC and that can get messy.

I can think of two possible solutions: either add the final step as a "second phase" (so something like running addcomputer.py -method SAMR and then addcomputer.py -method finishsetup, so you can switch tickets), or use the newly added computer account credentials for the connection - that way you're doing plain old password auth and things should hopefully work.

BTW. I'm not really sure if those two parameters are necessary for any of attacks, which was my focus when making this script. Making the addcomputer.py work for adding actual computers was not my original goal.