Now I'm going to go off on a sidebar here for a second and because I want to make sure that we understand what sites and services are inside of Active Directory.
And I know this is something that you can enumerate out of LDAP and some of the automated enumeration techniques that you have at your disposal, especially inside of Kali.
But it's really important that you understand what this is and the benefit behind it.
So let's say that you're pentesting an organization that is less familiar with its networking map and is more cloud-based and geo-dislocated from each other.
Which is becoming a common theme here among organizations.
So in this particular case, the organization that we're pentesting uses Active Directory and they have multiple different sites with multiple different servers and clients and all the other stuff.
Sites and services by default has one site called default site first site name.
And whenever you set up Active Directory, and if you don't mess with this, what it'll do is it'll take all systems, all servers, and compile them into one ginormous group.
And say everybody have at it. Good luck everybody.
And so that's kind of the wrong way to look at this.
Because what that means is that if somebody has a client that's in Portland, Oregon, and they're trying to log on and the first available server is in Austin, Texas.
It's going to create a lot of latency issues.
And there you can probably see where the issue comes in at and makes an opportunity for us.
So let's say for instance that they don't have this set up.
What you're doing is doing the wire shark and traffic monitoring to figure out where the servers are actually going to authenticate if it's geo dislocated.
And it also makes mapping everything out so complex and tedious.
Now, if a domain does have sites and services set up, there's added benefit to what's actually going on up there.
So for instance, instead of just having default first site name, you could have Portland in Austin.
Now inside of there, inside of each one of these groups, you would have obviously by default a servers folder.
And you can see that under first site name, I have server1-vm because it's added in there by default.
But in Portland, you would have let's say Portland-DC1, Portland-DC2.
And then you would have an Austin site that would have Austin-DC1, Austin-DC2.
And that way you know for a fact that those systems are tied to those sites.
Now, where does it really get into the networking you ask?
Well, if you look right above default first site name, you'll also see subnets.
And subnets are configured based on the actual subnets that you own.
So in this particular case, our lab owns 192.168.0.0.
And for each site, you would generally as an administrator and systems engineer, you would go in and configure all the subnets that are in here.
And if you go into the actual subnet itself, you can assign it to an actual location and go in and assign it specifically to a site.
Now, let's say 192.168.0.0.24 goes to Portland.
And 192.168.0.1.0 goes to Austin.
And so whenever you're doing your NMAP suites and you're going inside of sites and services and comparing to that,
not only do you get a scope of what systems are on there with NMAP,
but you also get an idea of what they're tied to inside of the actual domain structure.
Even if there is a split IP segment across different locations, which I've seen wonkier,
but you could get a better idea of how these servers talk.
Now, if you assign this subnet to a first site name or any other site that you create,
the servers that are inside of there that are DCs only, this will only list DCs in there,
will be the one that this subnet tries to authenticate with and communicate to for permission purposes first.
And the only time that it will go outside of that is one of two reasons.
Either A, it is completely slammed and has no availability, or B, it's offline.
So if all the servers in site Portland, for instance, Portland DC1, Portland DC2 are off,
then everybody in that site, based on the subnet, will try to authenticate with Austin.
And that will create a latency issue.
And the latency issue is kind of what we're picking out here.
Because you want to go through and try to crack whenever we do pass the hash and some other fun things.
Increasing the latency between a user and the authenticating server allows you a little bit more time to be able to go through and perform that task.
But it's also possible that when you go in and pentest an organization that none of this is set up.
Now, it is a good security option to have for your organization.
Because it takes care of, it manually dictates which IPs are going to communicate with which server primarily.
And the other thing too is that you can actually go in here, if there's multiple servers and multiple sites,
you could either force replication right away or adjust the parameters of passing that information back and forth through replication.
Now, by default, I believe it's five minutes.
Don't quote me on that because I've seen varying numbers whenever I've been doing monitoring.
My experience has been that it's anywhere between five and 15 minutes for a DC to replicate with other DCs.
Depending on the amount of data needed to transfer from one to the other.
So, if it's a lot of information that's changed in the last five to 15 minutes, next time it does its replication cycle, it may take a little bit.
Now, that being said, these sites play on the same latency issues and hindrances and benefits that the users do along with their workstations.
So, if a site is having communications issues between Portland and Austin, it would be good to check and see if you can fix something in Portland
and have it taken advantage of before it makes its way to Austin.
Or, as a security precaution, have it infiltration in Portland and before the replication can happen from Austin, stop it.
Because once the replication happens, let's say you change a password on a user account or an admin account.
Once that replication happens, if it's been fixed in Austin, it will replicate over to Portland and change that setting back to what it used to be.
Or, if you've done it in Portland and you're trying to send it out to everybody else, it will go that way as well, too.
Generally, if the blue team is good and they know what they're looking for and they have their script set up correctly,
what will happen is they notice something's going on and they will force replication from a known good site to sites that are messed up at that time.
So, if you're trying to go through and push out group policies or anything like that, that's a part of the replication sites and services overseas,
that the group in Austin is going to notice that an issue has come up and they will send it along the way to get fixed.