Support, in my opinion, tries to show people things that are sometimes done by support team who might not think of the consequences. From exposing tools used to developing tools that use cleartext credentials, you will have the opportunity to explore these as well as other misconfigurations in the environment.
References
Enumeration
Service Enumeration
Just like every scenario, we need to get to know our target better. We do this enumeration by trying to find ports opened on the host and then enumerate each service.
Finding Open Ports:
As you might know, we are looking at an active directory environment.
Through LDAP, we got found the domain, but we can explore further.
LDAP (TCP 389) Enumeration:
As we must, let's find out what we can get through LDAP.
Well, basically LDAP is not accessible without valid credentials. Let's proceed to the next service.
Kerberos (TCP 88) Enumeration:
Through Kerberos, we can only attempt to bruteforce user accounts at this point in the exercise to find valid ones.
From the accounts found and excluding the default ones, we can see support@support.htb and management@support.htb exist. Whoever has worked in an enterprise environment can assume easily these might be shared accounts, which technically should be avoided.
SMB (TCP 445) Enumeration:
As basic step when enumerating SMB is to attempt to use null sessions and find out what is allowed.
The only share that we can attempt to access is support-tools.
From these tools, the only unrecognized one is UserInfo.exe.zip. We need to unzip the file and test it.
Gaining Access
While looking at the unzipped files, we need to try and run it the Windows executable somehow. For this, we will use mono.
Let's try to use it to retrieve user information from the accounts we got through Kerberos. As it is retrieving user information, this means it must be connecting to a service, so let's attempt to capture some packets:
And the packet capture reveals another account and its password:
Found potentially hardcoded credentials: ldap:nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz
Our first test of this credential would be to use it through Bloodhound and in turn enumerate the domain further:
Looking at the relationship between 'support' and the domain controller shows this account inherits the ‘GenericAll’ delegated right through its membership of the 'Shared Support Account'.
Also, we can now pull a list of users from the domain:
Through LDAP, we will enumerate the 'support' account and its attributes:
┌──(kali 👿 kali)-[~/…/Support]
└─$ ldapsearch -x -H ldap://support.htb:389 -D 'SUPPORT\ldap' -w 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' -b 'CN=support,CN=Users,DC=support,DC=htb' -s base
# extended LDIF
#
# LDAPv3
# base <CN=support,CN=Users,DC=support,DC=htb> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#
# support, Users, support.htb
dn: CN=support,CN=Users,DC=support,DC=htb
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: support
c: US
l: Chapel Hill
st: NC
postalCode: 27514
distinguishedName: CN=support,CN=Users,DC=support,DC=htb
instanceType: 4
whenCreated: 20220528111200.0Z
whenChanged: 20220528111201.0Z
uSNCreated: 12617
memberOf: CN=Shared Support Accounts,CN=Users,DC=support,DC=htb
memberOf: CN=Remote Management Users,CN=Builtin,DC=support,DC=htb
uSNChanged: 12630
company: support
streetAddress: Skipper Bowles Dr
name: support
objectGUID:: CqM5MfoxMEWepIBTs5an8Q==
userAccountControl: 66048
badPwdCount: 1
codePage: 0
countryCode: 0
badPasswordTime: 133069989459107223
lastLogoff: 0
lastLogon: 0
pwdLastSet: 132982099209777070
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAG9v9Y4G6g8nmcEILUQQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: support
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=support,DC=htb
dSCorePropagationData: 20220528111201.0Z
dSCorePropagationData: 16010101000000.0Z
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
The info attribute contains account information related to credentials: support:Ironside47pleasure40Watchful
Given that the ‘support’ account has 'canPSRemote' right or delegated rights, we can attempt to access the system using this account through WinRM:
User flag found:
Privilege Escalation
Constrained Delegation
The inherited rights of 'support' by its membership of 'Shared Support Accounts' group mean the following:
GenericAll: GenericAll = Full Control
The right to create or delete children, delete a subtree, read and write properties, examine children and the object itself, add and remove the object from the directory, and read or write with an extended right.
It provides full rights to the object and all properties, including confidential attributes such as LAPS local Administrator passwords, and BitLocker recovery keys. In many cases, Full Control rights aren’t required, but it’s easier to delegate and get working than determining the actual rights required.
Example: A Server tier group may be delegated Full Control on all Computer objects in an OU that has the computer objects associated with servers. Another common configuration is delegating Full Control on all Computer objects in the Workstations OU for the Desktop Support group, and delegating Full Control on all user objects in the Users OU for the Help Desk.
• Set Execution Policy and Import PowerView
• Checking if user can create new computer objects: ms-ds-machineaccountquota
Run the following (change the values of the parameters of course): Get-DomainObject -Identity "dc=offense,dc=local" -Domain offense.local
At this point, we need to get the machine account hash from FAKE01$ and then try to get the Administrator account's TGT, so then we can use it to access the system as the Administrator user:
