Welcome

Challenge Lab (Easy) - by Noah Heroldt

The following post by 0xb0b is licensed under CC BY 4.0


Scenario

Objective / Scope

You are a member of the Hack Smarter Red Team. During a phishing engagement, you were able to retrieve credentials for the client's Active Directory environment. Use these credentials to enumerate the environment, elevate your privileges, and demonstrate impact for the client.

Starting Credentials

Summary

Summary

In Welcome we start with credentials obtained through phishing and leverage them to perform a full Active Directory compromise. Using the initial user e.hills, we enumerate SMB shares and domain objects, collecting usernames and relationships with BloodHound. From exposed HR documents, we recover an onboarding password reused by a.harris, whose group membership grants GenericAll control over i.park. Chaining these permissions, we reset credentials across multiple accounts to reach svc_ca, a service account with certificate enrollment privileges. Enumerating AD CS, we identify a misconfigured template vulnerable to ESC1 abuse, request a certificate impersonating the Administrator, and authenticate with its derived NT hash. Using a WMI-based execution method to bypass AV restrictions, we obtain a session as Administrator on the domain controller, completing a full-domain escalation from a single phished credential.

Recon

We use rustscan -b 500 -a sysco.hs -- -sC -sV -Pn to enumerate all TCP ports on 10.1.239.66, piping the discovered results into Nmap which runs default NSE scripts -sC, service and version detection -sV, and treats the host as online without ICMP echo -Pn.

A batch size of 500 trades speed for stability, the default 1500 balances both, while much larger sizes increase throughput but risk missed responses and instability.

With the results of our RustScan we identify a Windows host named DC01 on domain WELCOME.local exposing DNS on 53, Kerberos on 88, Active Directory LDAP on 389 (AD), LDAPS/tcpwrapped on 636, kpasswd5 on 464, Microsoft RPC / MSRPC endpoints on 135, NetBIOS/SMB on 139 and 445 (SMB2 message signing required), RPC-over-HTTP on 59 .NET message framing on 9389, RDP on 3389 and several ephemeral MSRPC ports 49664, 49667, etc.

SMB

Since we already have some credentials from the scenario. We will test whether we can authenticate via SMB using these credentials, for which we will use NetExec.

We can authenticate as e.hills and then try to enumerate the shares. The Human Resources share stands out as it is readable.

Since the IPC$ share is also readable, we perform a RID brute force to enumerate additional users.

An RID brute-force cycles through the relative ID part of Windows SIDs (e.g. 500, 501, …), querying the host/domain via IPC$ for each constructed SID to see which ones map to real accounts. This works because RIDs are assigned in predictable ranges/sequences and Windows returns distinguishable responses for existing versus non-existing SIDs.

Alternatively we could also use the --users parameter to enumerate the users.

We are able to identify some users and save them to users.txt.

Now that we have a user list and a password, let's try a password spray. However, we cannot find any further access.

We generate an /etc/hosts entry with the following command. We do this to ensure consistent name resolution during enumeration and exploitation.

We add the following entry to our /etc/hosts file.

Bloodhound Enumeration

Since we have the credentials of a user we can also use BloodHound to enumerate the domain:

We see that the user e.hills does not have any interesting group membership or outbound object control relationships that we can use to escalate our privileges.

We investigate on the users found from the RID brute force and are able to identify a path from a.harris or j.johnson to i.park. The users a.harris and j.johnson have a GenericAll permissions through on i.park, that would allow us to change the password of the user (if we would be able to compromise one of those accounts). Furthermore we see that i.park is member of the Helpdesk group which has a ForceChangePassword permission on both svc accounts.

The svc_ca account might be of high value to enumerate the certificate templates on the machine.

We also check for Domain Admin accounts, but there is just one: the Administrator user account.

Shell as a.harris

We move on and continue to enumerate the SMB service. We try to get access to the share Human Resources. Maybe we are able to spot some sensible information, like onboarding material. We connect to the share using smbclient.

Next, we download all the documents in the share.

One of them is particularly interesting: Welcome Start Guide.pdf

This appears to be an onboarding document. It could possibly contain sensitive information like an onboarding password. But the file is password-protected.

We generate a hash using pdf2john.py to crack the password used.

Next, we use john to crack the hash and are successful.

We are able to unlock the onboarding document and find a default password.

We spray the password using the users identified using Netexec and are able to successfully authenticate as a.harris.

Before we start to make use of the GenericAll permission on i.park we try to enumerate further shares, but there are no further.

Recalling the BloodHound data we see that a.harris is also in the Remote Management Users group. So we could be able to get a session with that user.

Futhermore, we recall that we have the capability to change the password of i.park as the user a.harris is part of the HR group that has the capabillity to do it.

We will follow the path identified in our BloodHound Enumeration...

... but first we connect to the target machine with the credentials as a.harris to find the user flag at C:\Users\a.harris\Desktop\user.txt.

Access as i.park

Since we now have access as a.harris, we are able to change the password of the user i.park through the GenericAll permission of the HR group. We use the following resource as reference:

GenericAll -> Force Change Password

To change the password we use bloodyAD:

After we have changed the password we try to authenticate as i.park via SMB using NetExec and are successful.

Access as svc_ca

Recalling the path again, we make use of the ForceChangePassword on svc_ca via the Helpdesk group which i.park is part of.

For this we can reuse the bloodyAD command and adapt the users and password:

After we have changed the password we try to authenticate using SMB via Netexec:

Shell as Administrator

In addition to using BloodHound to enumerate objects and relationships within Active Directory, there are also tools specifically designed for enumerating certificate-related vulnerabilities. Notable examples include Certipy, which help identify vulnerable certificate templates that can be exploited for privilege escalation.

Now that we have access as svc_ca we try to identify vulnerable certificate templates using Certipy.

We receive a json output with the results. The certificate templates Welcome-Template is misconfigured to allow svc_ca to enroll and supply arbitrary subject names, enabling ESC1 attacks for impersonation via client authentication.

ESC1 is when a certificate template permits Client Authentication and allows the enrollee to supply an arbitrary Subject Alternative Name (SAN).

For ESC1, we can request a certificate based on the vulnerable certificate template and specify an arbitrary UPN or DNS SAN with the -upn and -dns parameter, respectively.

https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc1-enrollee-supplied-subject-for-client-authentication

Results of Certipy:

If not already done, add the following entries to your /etc/hosts file:

We requested a certificate for svc_ca from CA WELCOME-CA using the vulnerable Welcome-Template template, set the UPN to administrator@WELCOME.local, and received the issued certificate as a .pfx.

Next, we try to authenticate as Administrator using the certificate and we receive the NT hash.

We test if we can authenticate witht he hash via SMB and are successful.

Unfortunately we cannot connect using evil-winrm.

Instead of using evil-winrm, we could aslo try psexec, wmiexec and so on, since port 135 + dynamic RPC ports and usually SMB 445,139 are open and we have access to.

We make use of wmiexec2.py we used in Anomaly which is an obfuscated version of wmiexec to evade signature-based AV detection.

We give it a try, passing the hash of the Administrator and are successful. We receive an interactive session.

We'll find the final flag at C:\Users\Administrator\Desktop\root.txt.

Last updated

Was this helpful?