intro fresh start to 2025, and things turned positive real quick. in late december 2024 and on 1 january 2025, i pushed v3 and v3.1 updates to vvmlist, which gave me enough serotonin. with that boost, a pentest project was assigned to me. i thought i couldn't be happier beause i was gonna do pentest. but the results shocked me. (plot twist: in a good way) target the target is a municipal affiliate, one of the biggest companies responsible for natural gas infrastructure, distribution, and operation. i assumed the municipality worked as efficiently as they claimed in their ads about "working hard." they also opened some cyber positions i never got called for. conclusion: big company, backed by a big municipality, playing a critical role. with that in mind, i didn't expect much. maybe just two domain admins at most (from esc8 and ntlm relay, ofc). day 1 i woke up real early and did my morning tasks, which are basically a warm cortado and firing up ec. after some time to initialize my brain, i put on my clothes and left home. walked to the metro in the dark, thanks to turkish government. anyway, i arrived at the target building and met with the responsible person. i had met that guy before on a call, and he had asked me not to use my own laptop for the pentest. i told him it was okay and not a big problem, but from my experience, companies that don't allow a pentester's laptop always give them a shitty one to work with. (swear on my jordans, i said it in a corporate way.) we discussed the same thing on the first day. he told me their infrastructure wouldn't allow my laptop unless i installed some utility and set it up. he also said there was no compatible utility for macos. the problem is, both times, he thought i was going to do the pentest in a windows environment. no sir, i'm just using kali, and i don't need your domain-level control mechanisms. but that control mechanism did make me feel like they were working closely and doing something good for their infrastructure. so i obtained active directory dummy user credentials and subnets to scan from the responsible person. then i got to work, leaving nessus running in the background and bloodhound-python in front. i dumped everything from active directory and used a one liner to manipulate the computers.json file and get all the domain's computers. (this was my meta until i developed a netexec module for it.) what comes after bloodhound-python? certipy! i read the certipy output with a smile on my face. not because i was about to get two domain admins from it, but because they had configured adcs in a way that made it ridiculously easy to exploit. i want you to see it too. i proceeded to exploit esc1 and esc8 and successfully obtained my first two domain admins. there was still a lot of work to do since the structure was huge, meaning there could be a big variety of vulnerabilities and misconfigurations. i always do local admin brute force checks, so i moved on to that. ran the brute force attack, and one password in my wordlist matched on about 20 computers. did an lsass dump against all of them and retrieved the hash of a privileged user. that user had local admin privileges on many machines, so i used its credentials for another lsass dump, retrieved a domain admin hash from one of the machines, and that's how i got the third domain admin. for the fourth domain admin, i checked if ldap signing was enforced on the dc. no surprise, it wasn't. i fired up an ldap relay, and it worked, automatically adding a machine account with delegation privileges on x machine. impersonation was possible, so i got a ticket for a domain admin user on x machine. did an lsass dump and found the hash of a seemingly normal user. further inspection in bloodhound showed that this "normal" user was in a group with writeowner privileges on a gpo. first step in this situation? impacket-dacledit to take ownership of that gpo. it worked. then, thanks to the pygpoabuse tool, i created a scheduled task that added the pentest domain user to the local admins group. waited for some time for computers to process the abused gpo. the dc got the gpo too, and the pentest user was in the local admins group. from there, i just added myself to the domain admins group using the pentest user. enough work for one day. day 2 same as yesterday. i arrived at the target building and started working. even though only about 20 machines had smb signing off, i had a strong gut feeling that i was gonna get a domain admin from ntlm relay. so, i fired up responder and ntlmrelay. a few minutes later, i saw that it dumped a few machines' sam. i individually tried the local admin hashes across the entire scope, and just one hash matched on multiple machines. then i dumped lsass on all of them and retrieved a domain admin hash from one of the machines. fifth domain admin captured. info: my best record for different project/domain admin counts was four, and i just broke my own record. running on faith. next thing to check: printnightmare. ran the check, and exactly seven machines returned as vulnerable. created and compiled a .dll that adds the pentest user (this is the second one) to the local admins group. exploited the vulnerability and made the pentest user a local admin on a vulnerable machine. dumped lsass and got the hash of a user in the backup operators group. fired up reg.py and dumped the sam of the dc. after that, added myself to domain admins. sixth domain admin. protip: installation of samba handles this vulnerability better than impacket-smbserver. for the seventh domain admin, i used revealhashed to get weak passwords of domain users. then i marked all of them as owned in bloodhound. a total of 683 users were using weak passwords. using custom bloodhound queries, i found that one of them had local admin privileges on about a dozen machines. dumped lsass and found a domain admin's hash and cleartext password from one of the machines. enough work for that day. day 3 same as yesterday. i arrived at the target building and started working. next thing to check: mssql sa brute force. i fired it up, and it matched on two mssql servers. executed "dir c:\users" from netexec mssql to check for domain-level admin presence so i wouldn't waste time. (i developed a netexec module for this too.) since there was no domain-level admin presence, i chose a machine to move forward with. executed "whoami /priv" to see if seimpersonate was enabled. since the target machine couldn't access my kali, i followed a different route to deploy the potato exploit. executed it to get a system shell. after that, i dropped a meterpreter exe and executed it. received a meterpreter session as system, but there was nothing useful except sam. grabbed the local admin's hash and tried it on all machines. about ten machines returned. dumped lsass on all of them and got an enterprise admin's hash from one machine. eighth domain admin. protip: 7z command line binary and dummy domain user writable shares are your friend. for the ninth domain admin, i didn't expect a dummy user to have privileges on any objects, but i checked anyway. turned out the domain users group had genericall privilege on computers and server ous. immediately fired up impacket-dacledit to grant full privileges to the pentest user (this is the third one) on the servers ou. then it was time for resource-based constrained delegation. since machineaccountquota was at the default 10 in the domain, first i created testcomputer. executed impacket-rbcd against the target machine to gain impersonation. requested a ticket on behalf of a domain admin, and it was successful. dumped lsass to get a privileged user's hash. that privileged user was a local admin on almost every machine. dumped lsass from all of them and got a hash and cleartext password of a domain admin from one machine. enough work for that day. day 4 same as yesterday. i arrived at the target building and started working. since nessus was scanning critical subnets outside working hours, i stayed overtime on day 2 and day 3. completed 95% of the work, thanks to my speed and my own automated tools. last day is my smb share inspection day if i already have domain admins in my hand. i don't rely much on automated tools for this part. for example, config.xml could be a worthless printer config file or a valuable application config file. same thing goes for .json, .conf, etc. also, my checklist includes a section for hunting sensitive data. i need to collect evidence for both content and path, so i always check smb shares manually, one by one. i love hunting web.config files because they are easy targets for finding something useful. protip: winshareenum and nxcspidey are your friends. while checking smb shares readable by a dummy domain user, i found an interesting .json file. the file contained an api endpoint and postgresql credentials. with that, i immediately executed metasploit's postgresql shell module and successfully received a meterpreter shell on the target. ran getuid to check privileges and i was running as nt authority\network service. "whoami /priv" wasn't gonna give me much, so using fullpowers solved it. fullpowers enabled seimpersonate, making it ready for a potato exploit. executed the potato exploit and elevated to system. there was nothing but a sam dump. grabbed the local admin's hash, then tested it across all machines. 15 machines returned positive. dumped lsass to find a privileged user's hash. that privileged user had local admin privileges on about 40 machines. dumped lsass again and found a domain admin's hash on one of them. added myself to domain admins for the tenth time. after that, i quickly did my final checks and filled my checklist with evidence from automated script results; ipmi hash disclosure, telnet, nfs, etc. the checklist alone was 150 pages long, making it my most extensive report yet. informed the responsible person that the work was done, handshake, out.i awarded my laptop by gluing ten of hearts card on it. - it was an awesome experience.
if you have questions: contact