0x00 Preface

---

Previous articles "Domain Penetration - Obtaining DNS Records" and "Domain Penetration - Obtaining DNS Records with Standard User Privileges" introduced methods for acquiring DNS records in domain environments, which help us quickly understand the internal network architecture.

However, DNS records can only serve as auxiliary indicators. There is no direct correlation between DNS records, the corresponding MachineAccount in DNS records, and the actual computers.

Non-privileged users within the domain can freely create DNS records and MachineAccounts.

This article will introduce methods for non-privileged users to create DNS records and MachineAccounts within a domain, documenting the essential knowledge points to master.

0x01 Introduction

---

This article will cover the following topics:

  • Introduction to MachineAccount
  • Methods for non-privileged users to create MachineAccounts
  • Methods for non-privileged users to create DNS records

0x02 Introduction to MachineAccount

---

1. MachineAccount

Whenever a computer joins a domain, a machine account (MachineAccount) is created as a member of the "Domain Computers" group.

In a domain environment, the list of all machine accounts can be obtained with the following command:

net group "Domain Computers" /domain

Each machine account name ends with the character $.

Note:

When using Mimikatz's DCSync feature to export all user hashes, all machine account hashes are also exported.

If a machine account hash is obtained, it can be used to forge a Silver Ticket, thereby gaining access to corresponding services. For exploitation methods, refer to the previous article "Domain Penetration – Pass The Ticket".

2. MachineAccountQuota

Indicates the number of computer accounts a user is allowed to create in the domain, with a default value of 10.

Documentation:

https://docs.microsoft.com/en-us/windows/win32/adschema/a-ms-ds-machineaccountquota

For an introduction to MachineAccountQuota (MAQ), refer to:

https://blog.netspi.com/machineaccountquota-is-useful-sometimes/

Here is a brief summary of the 10 rules mentioned in the reference material, along with personal insights. The characteristics are as follows:

(1) Allow non-privileged users to create computer accounts via MAQ, default is 10, but cannot delete created computer accounts

To disable MAQ, refer to: https://social.technet.microsoft.com/wiki/contents/articles/5446.active-directory-how-to-prevent-authenticated-users-from-joining-workstations-to-a-domain.aspx

(2) The creator account's SID is stored in the ms-DS-CreatorSID attribute of the computer account

That is, for computer accounts created via MAQ, viewing the ms-DS-CreatorSID attribute can reveal the creator account's SID

(3) Computer accounts created via MAQ will be placed in the "Domain Computers" group

(4) For computer accounts created via MAQ, the following attributes can be modified:

  • AccountDisabled
  • description
  • displayName
  • DnsHostName
  • ServicePrincipalName
  • userParameters
  • userAccountControl
  • msDS-AdditionalDnsHostName
  • msDS-AllowedToActOnBehalfOfOtherIdentity
  • samAccountName

The AccountDisabled property can be used to disable this user

The userAccountControl property records the user's attribute information. For details, refer to https://support.microsoft.com/en-us/help/305144/how-to-use-useraccountcontrol-to-manipulate-user-account-properties

(5) Adding a computer account will create the following 4 SPNs:

  • HOST/MachineAccountName
  • HOST/MachineAccountName.domain.name
  • RestrictedKrbHost/MachineAccountName
  • RestrictedKrbhost/MachineAccountName.domain.name

(6) Machine accounts do not have local login permissions

But commands can be executed via "runas /netonly"

0x03 Methods for Non-Privileged Users to Create MachineAccounts

---

1. PowerShell Implementation

Requires Powermad

The command to create a computer account testNew via MAQ is as follows:

New-MachineAccount -MachineAccount testNew -Password $(ConvertTo-SecureString "123456789" -AsPlainText -Force)

View the full properties of the computer account testNew:

Get-ADComputer testNew -Properties *

Specifically includes the following properties:

  • AccountExpirationDate
  • accountExpires
  • AccountLockoutTime
  • AccountNotDelegated
  • AllowReversiblePasswordEncryption
  • AuthenticationPolicy
  • AuthenticationPolicySilo
  • BadLogonCount
  • badPasswordTime
  • badPwdCount
  • CannotChangePassword
  • CanonicalName
  • Certificates
  • CN
  • codePage
  • CompoundIdentitySupported
  • countryCode
  • Created
  • createTimeStamp
  • Deleted
  • Description
  • DisplayName
  • DistinguishedName
  • DNSHostName
  • DoesNotRequirePreAuth
  • dSCorePropagationData
  • Enabled
  • HomedirRequired
  • HomePage
  • instanceType
  • IPv4Address
  • IPv6Address
  • isCriticalSystemObject
  • isDeleted
  • KerberosEncryptionType
  • LastBadPasswordAttempt
  • LastKnownParent
  • lastLogoff
  • lastLogon
  • LastLogonDate
  • localPolicyFlags
  • Location
  • LockedOut
  • logonCount
  • ManagedBy
  • MemberOf
  • MNSLogonAccount
  • Modified
  • modifyTimeStamp
  • mS-DS-CreatorSID
  • msDS-User-Account-Control-Computed
  • Name
  • nTSecurityDescriptor
  • ObjectCategory
  • ObjectClass
  • ObjectGUID
  • objectSid
  • OperatingSystem
  • OperatingSystemHotfix
  • OperatingSystemServicePack
  • OperatingSystemVersion
  • PasswordExpired
  • PasswordLastSet
  • PasswordNeverExpires
  • PasswordNotRequired
  • PrimaryGroup
  • primaryGroupID
  • PrincipalsAllowedToDelegateToAccount
  • ProtectedFromAccidentalDeletion
  • pwdLastSet
  • SamAccountName
  • sAMAccountType
  • sDRightsEffective
  • ServiceAccount
  • servicePrincipalName
  • ServicePrincipalNames
  • SID
  • SIDHistory
  • TrustedForDelegation
  • TrustedToAuthForDelegation
  • UseDESKeyOnly
  • userAccountControl
  • userCertificate
  • UserPrincipalName
  • uSNChanged
  • uSNCreated
  • whenChanged
  • whenCreated

Note:

The Get-ADComputer command requires the ActiveDirectory module, which is typically installed on domain controllers.

For systems without the Active Directory module installed, you can import it using the following command:

import-module .\Microsoft.ActiveDirectory.Management.dll

Microsoft.ActiveDirectory.Management.dll is generated after installing the PowerShell Active Directory module; I have extracted it and uploaded it to GitHub:

An open-source project

Powermad also supports viewing computer account attributes, but specific attributes to view must be specified.

For example, the command to view the servicePrincipalName attribute is as follows:

Get-MachineAccountAttribute -MachineAccount testNew -Attribute servicePrincipalName

Note:

Powermad's Get-MachineAccountCreator command can enumerate the creators of all computer accounts (MachineAccount).

To modify computer account attributes, use Powermad's Set-MachineAccountAttribute command, which supports modifying the following attributes:

  • AccountDisabled
  • description
  • displayName
  • DnsHostName
  • ServicePrincipalName
  • userParameters
  • userAccountControl
  • msDS-AdditionalDnsHostName
  • msDS-AllowedToActOnBehalfOfOtherIdentity
  • SamAccountName

Example as follows:

Set-MachineAccountAttribute -MachineName testNew -Attribute SamAccountName -Value test

2.C# Implementation

SharpAllowedToAct includes this functionality

I extracted the function for creating a MachineAccount, made simple modifications to support compilation with csc.exe or Visual Studio

The complete code has been uploaded to GitHub, address as follows:

An open-source project

You can use Visual Studio to create a C# project and compile AddMachineAccountofDomain.cs to generate an exe file, or upload AddMachineAccountofDomain.cs to a test environment and compile it using csc.exe

The environment using csc.exe for compilation supports .NET 3.5 or higher

The compilation command is as follows:

C:\Windows\Microsoft.NET\Framework64\v3.5\csc.exe AddMachineAccountofDomain.cs /r:System.DirectoryServices.dll,System.DirectoryServices.Protocols.dll
or
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe AddMachineAccountofDomain.cs /r:System.DirectoryServices.dll,System.DirectoryServices.Protocols.dll

0x04 Method for Non-Privileged Users to Create DNS Records

---

Here, you can use Invoke-DNSUpdate.ps1 from Powermad

The Invoke-DNSUpdate command supports adding the following records:

  • A
  • AAAA
  • CNAME
  • MX
  • PTR
  • SRV
  • TXT

Add an A record for the machine account testNew with the following command:

Invoke-DNSUpdate -DNSType A -DNSName testNew -DNSData 192.168.1.111

The command to delete this record is as follows:

Invoke-DNSUpdate -DNSType A -DNSName testNew

Non-privileged users cannot modify or delete existing records

For more details, refer to:

https://blog.netspi.com/exploiting-adidns/

0x05 Summary

---

This article introduces methods for creating DNS records and Machine Accounts by non-privileged users within the domain, demonstrating that DNS records can only serve as an auxiliary method for determining the internal network architecture

From a defensive perspective, if an attacker only has the permissions of a non-privileged user within the domain, when attempting to create a computer account via MAQ, if they do not obtain higher privileges, they cannot clear attack traces (unable to delete computer accounts created via MAQ). The attacker can be identified by checking the creator of the computer account