Starting Point Part 5: Pathfinder

Our notes pages should be getting pretty full now and we are starting to understand the process. While I like the Cyber Kill Chain concept, it is missing the details on what we are doing. The MITRE ATT&CK framework can help you see what has been found in the past with categories. I like this graphic to help reinforce what we are trying to do with each piece of information we get: https://github.com/infosecn1nja/AD-Attack-Defense. We are constantly doing these loops of “find information, leverage that information for more stuff or access” until we get to where we want to go. In this case, we are pursuing a root flag on Pathfinder!

For starters, use one of the techniques in previous boxes and we come to the open ports:

Quite a few ports there, but it looks really heavy. Four LDAP ports (two secure and two not), kerberos, and port 464? We are definitely in an Active Directory situation here. We haven’t done that before, so let’s follow our process we have built so far and see where it gets us. Nmap tells us the domain we are in, so don’t forget that one. Let’s start with smb since that one is in our notes already.

Well, we haven’t seen the rest of these ports yet, so let’s dive in to LDAP. I’ll use ldapsearch because its lightweight and easy to start with.

So, right off the bat is give an error for a “bind operation” which means we need credentials. Since we are on the Megacorp network again, let’s start off by validating our previously-found creds won’t work. I have that file I have been keeping that has the username:password combos that I have found so far, let’s let crackmapexec tell us if any of them work.

And ‘sandra’ is the winner! Let’s save that in a variable and start using these creds when we look at things. Since we are already using crackmapexec, let’s use the ldap functionality to see what we can get. I’ll just run through the good options and see what falls out:

Awesome, lots of good stuff here. We got a roastable user, we see that the Pathfinder computer has delegation trust, and there are a bunch of admin groups. When I ran the last command, I got an error:

Kerberos is very time sensitive. Since it gives out tickets based on time, we have to make sure our times are aligned. When we ran nmap, it gave us a warning but we didn’t listen:

So I need to adjust the time to match (within a few seconds). So I’ll just run nmap again to tell me how far off my time is, adjust my time to that, then run crackmapexec again.

And now we are close enough and kerberos also gives us a key dump. Both keys are for a user ‘svc_bes’, so that is a target. While I continue some enumeration, let me run john in the background to start working on these keys.

With john running, I’ll go back to the top of my recon and start using these creds from ‘sandra’. Since I already got crackmapexec up, let’s go back to smb.

Okay, so we see the users. I try to run it with ‘ — shares’ and it crashes out. So I’ll try smbmap with some creds now

Okay, there are some share we can go see if we want, but they really don’t have much in them. I look back at my john command and he found a hit! I’ll store that in my creds file for this ‘svc_bes’ user and try using these new credentials. He had nothing better for smbmap, so let’s go see what access he has in ldap. So I run ldapsearch -x -b “dc=MEGACORP,dc=LOCAL” -H ldap://$IP -D svc_bes@MEGACORP.LOCAL -W and get 247 responses back. Wow, we are in active directory. Time to find the needle in the haystack. Scrolling up, ‘svc_bes’ is inside the ‘CN=svc_maint’ object. Let’s run another query and see what all he can access.

If this is your first time with active directory, you may want to run Bloodhound. It is a graphical tool that takes what I’m looking at and maps it to a graph. Just warning you!

running this: ldapsearch -x -b “dc=MEGACORP,dc=LOCAL” -H ldap://$IP -D svc_bes@MEGACORP.LOCAL -W “(objectclass=*)” aclEntry alcPropagate aclSource enteryOwner ownerPropagate ownerSource has a shortened list, but I see a group called “Remote Management Users” that we are a part of. Weird, did we see any ports open on nmap? I go check and the answer is no. However, we only ran nmap on the “top” ports and checking windows remote management port isn’t one of them. Let me run a quick scan and see:

Well dang it. We could have been on the box steps ago if we would have found this before. Even ‘sandra’ is in the group, so we could have jumped on the box immediately. Whoops, but at least now we got ‘svc_bes’ so we got progress.

And there we are. Half way to the end. So let’s look around and see what svc_bes can do. I run a ‘whoami /all’ and see some stuff, but I was expecting more permissions. Let’s run winpeas and see what we get. I’ll just use the Music directory for the things I use so I can clean up later.

Running winPEAS.exe didn’t give me much. It says that there is an autologon creds in memory, but thats about it. Next part of my process is to leverage PowerUp.

That gave nothing too. So let’s think about this. The user we have is a domain account, not a local account. So let’s focus on the domain since this user doesn’t have special permissions local to the box. Let’s grab PowerView and see what ACLs this user has.

So that returned A LOT when I hit enter. We need to filter down what we are looking for. I really want to know what svc_bes can control. I can do that with Get-ObjectAcl -ResolveGUIDs | where -Value “svc_bes” -CIn IdentityReference and there is still a lot, but its focused on this user. This user has GenericAll permissions on a lot of properties and has way more permissions that it needs (least privilege is not being followed here). I’m going to go see if he has permissions to dump things from active directory.

It starts off with a error, but then all the hashes are dumped to the screen! This user has it all. If you haven’t used the impacket collection before, it is a must when using linux to interact with active directory. Let me save the admin hash in a variable, then we can try to get on as that user with a ‘pass-the-hash’ attempt.

And we are on. Great. Looking at who we are, it seems that we are the “domain” admin and not the local admin. Lets do one more thing and pull the local admin hash from the system too. Let’s upload mimikatz and do a dump.

So I upload mimikatz and try to run it and get pages of errors. What is the problem? I’m domain administrator and not local administrator. I don’t have access to the lsass process locally. How can we elevate to the higher local user? Let’s leverage another impacket tool that allows us to get high local rights if we can write to the Admin$ drive (which we can with this domain admin user). In order to run this command with the hash, you need both pieces of the LM:NTLM has from adminstrator.

Whoo-hoo. Now we are in. We run the same steps as before and Invoke-Mimikatz now works. And now we have stolen the local admin hash too! Why do we need it, no clue but these boxes are all connected and the more creds I have the better we’ll be for the next box!

Okay. Make sure you clean up your stuff and I’ll see you on the next box!