Vintage
SUMMARY
This is a Windows Server 2022 machine with NTLM authentication disabled, meaning it only accepts Kerberos authentication. We start enumerating with BloodHound CE with provided user credentials and discover a pre-Windows 2000 machine that, once exploited, allows reading password of a gMSA account. Taking control of the GMSA account we enable another revoked service account that we can abuse with a targeted ASREProasting to obtain its password. Once sprayed, this password leads to another user credential with remote management permission. Finally, we are able to configure Evil-WinRM for Kerberos authentication and collect the user flag.
Regarding escalation, first we disclose DPAPI secrets with Impacket's dpapi.py. The compromised account has permissions for a delegation attack, so we request an ST ticket impersonating an user member of domain administrators group.
KEYWORDS
NTLMSSP, pre-Windows 2000, gMSA password, bloodyAD, targeted ASREProasting, Kerbrute, DPAPI, Impacket, dpapi.py, delegation attack, S4U2self/S4U2proxy abuse.
REFERENCES
https://metacpan.org/pod/SMB::Auth
https://www.trustedsec.com/blog/diving-into-pre-created-computer-accounts
https://x.com/filip_dragovic/status/1524730451826511872
https://github.com/micahvandeusen/gMSADumper
https://www.thehacker.recipes/ad/movement/dacl/readgmsapassword
https://github.com/ropnop/kerbrute
https://gist.github.com/zhsh9/f1ba951ec1eb3de401707bbbec407b98
https://www.thehacker.recipes/ad/movement/credentials/dumping/dpapi-protected-secrets
https://github.com/gentilkiwi/mimikatz/wiki/module-~-dpapi
https://www.thehacker.recipes/ad/movement/kerberos/delegations/
https://www.thehacker.recipes/ad/movement/kerberos/delegations/s4u2self-abuse
ENUMERATION
Port scan.
Looks like a domain controller.
We have credentials for P.Rosa:Rosaisbest123, so let's enumerate the SMB service.
Odd, let's try with smbmap
Weird, check with Wireshark what is going on.
After some investigation on the reported error after the NTLMSSP_NEGOTIATE message, it seems NTLMSSP (NTLM-based authentication) is disabled in the server. Meaning we will have to use Kerberos authentication throughout the entire process.
Having user credentials next step would be to brute force the RID to get more usernames. However, this does not work since NTLM is disabled in the host, and the crackmapexec fails also to negotiate NTLMSSP authentication.
At this point we could try to use Kerberos authentication with crackmapexec; however, we will proceed to continue enumerating with ldapsearch
This tool works since it uses simple authentication. You can verify this by dumping the entire directory and analyzing the traffic with Wireshark.
Once we have understood what is happening with the server authentication configuration, let's continue enumeration with ldapsearch
First we take the sAMAccountName of objects with objectclass=users. In other words, we enumerate the usernames.
We see several usernames along with domain controller DC01, a managed service account gMSA01$ and a computer account fs01$
We take the opportunity to dump a list of users using this query.
And with this user list we can verify if there are users with Kerberos pre-authentication disabled (ASREProasting).
There are no accounts with pre-authentication disabled; on the other hand, we discover three revoked accounts, one of them is the service account svc_sql
Next step would be to collect data and continue enumerating with BloodHound CE. There is no problem with that, since the bloodhound-ce-python tool supports Kerberos authentication.
In fact, in the output we see the first action is to request a TGT ticket.
Ingest the data in BloodHound CE and start enumerating. First thing we notice is fs01$ is a rather old (vintage) pre-Windows 2000 machine.
Also, it can read group managed service account passwords.
USER
Since fs01$ can read gMSA01$ password, our first step would be to find a way to compromise old pre-Windows 2000 computers. And it seems there is a there is a high probability that the computer account password is actually the same as the computer name in these machines.
The attack path would be to get a TGT ticket for the pre-Windows 2000 account, using the computer name as password. Then use the tool suggested by BloodHound CE (gMSADumper.py) to dump gMSA01$ password.
Begin requesting a TGT for fs01$
Now, next step would be to use gMSADumper.py to dump the password; however, it does not work due to DNS issues.
Luckily, it seems bloodyAD also reads gMSA passwords.
Back to BloodHound CE, mark gmsa01$ as "Owned" and enumerate from there.
We see gmsa01$ has permissions to add itself into serviceManagers group.
And serviceManagers have GenericAll over the three service accounts we discovered before, including the revoked one.
So if we added gmsa01$ into serviceManagers we could reactivate the service account svc_sql
Let's add gmsa01$ to serviceManagers. First step would be to generate a TGT.
Now add the account with bloodyAD using its own TGT.
Now, if gmsa01$ has inherited group's permissions, it has GenericAll over the svc_sql account and we can reactivate the account.
If we remember, since svc_sql was revoked and we couldn't verify if it has Kerberos pre-authentication disabled. Now, after activating it, we can try a targeted ASREProasting attack, which is similar to a targeted kerberoasting attack (as we did in Administrator).
In a nutshell, in a targeted ASREProasting attack we set the attribute DONT_ REQ_PREAUTH, since we have GenericAll over the user account, then dump the hash and try to crack it offline.
First step would be to reactivate the account, using the same gmsa01$ ticket we have in cache (verify if it has not expired, and renew it if that's the case).
Now we can set the DONT_REQ_PREAUTH attribute so it is asreproastable.
Repeat the ASREProasting and dump the hash.
Which can be cracked with module 18200.
Now spray the password with a tool that supports Kerberos authentication, for example Kerbrute.
You can verify in BloodHound CE the compromised account has remote management permissions, therefore we can have an Evil-WinRM session under its context. We just need to find a way to use Evil-WinRM with Kerberos authentication.
Normally, according to documentation, Kerberos authentication is supported with -r flag, but first you have to configure the KDC realm in the /etc/krb5.conf file.
I used this tool as support, but needed to make some modifications to the file supplied by the tool. The final configuration file is this.
Also, it may be necessary to add the IP 10.10.11.45 in the /etc/resolv.conf file (comment the existing lines).
Now you can open an Evil-WinRM shell using Kerberos authentication.
And collect the user flag.
SYSTEM
Start from the shell as c.neri and take the opportunity to enumerate the system.
We have already seen how to harvest DPAPI-protected secrets in Week 7. Office. Basically, DPAPI is a Windows API used by applications that want to protect and store secrets such as passwords, tokens, etc. Encrypted data is stored in data blobs in the user's directory that have been secured by user-specific master keys.
Blobs are usually be found here.
Master keys are derived from user's password and usually located here:
In this case we find blob files here.
And here.
And regarding the master keys, they are stored in a folder named after the user's SID.
And inside we find the master keys.
In Week 7. Officewe decrypted the blobs with mimikatz. In this case, the host is running a defender solution that blocks Mimkatz, so we will use Impacket's dpapi.py with files transferred to Kali machine.
First thing would be to obtain the key from the master key file with user's password, SID and blob files.
And with the decrypted key, obtain the secret from the blob.
Which results to be credentials for another user c.neri_adm
To summarize this part: someone has protected c.neri_adm credentials using Windows cryptographic API (DPAPI). The secret is stored a data blob file protected with a master key, that is derived from user c.neri password and SID. Both blob and master keys files are stored in c.neri user folder.
Back to BloodHound CE, mark c.neri_adm as "Owned" and enumerate from there. First thing we notice is the user belongs to delegatedAdmins group.
And if we enumerate the delegatedAdmins group we see a possible path to domains administrators via l.bianchi_adm account, since l.bianchi_adm is also a delegated admin, and in turn a domain administrator.
This suggests a delegation abuse attack. Kerberos delegations allow services to access other services on behalf of domain users. And Service for User to Self (S4U2self) allows a service to obtain an ST on behalf of another user to itself.
In this case, if we had a service account belonging to delegatedAdmins group, we could request an ST impersonating l.bianchi_adm and gain root, since this account is member of domainAdmins.
We have control over c.neri_adm who is already member of the delegatedAdmins. So one option
would be to convert c.neri_adm to a service account by adding a SPN attribute to the account.
However, this option doesn't work because it seems assigning an SPN to itself violates constraints defined by Active Directory.
Thinking about other ways, we could take the svc_sql account we reactivated before and add it to the delegatedAdmins group. We can do it since we control c.neri_adm
And now try to change SPN for svc_sql
It worked, now we have a service account in the delegatedAdmins group, meaning we can request an ST for CIFS (SMB) impersonating l.bianchi_adm
And use this ticket to open a CIFS-based (SMB) shell as l.bianchi_adm
You are root.
Last updated