All right, let's go. 12 o'clock. This is Beyond the MCSE Red Teaming Active Directory and I'm
Sean Metcalf. Otherwise you're in the wrong room. But since it's single track today, I think
you're in the right room. I'm the founder of Trimark, a security company, a Microsoft
certified master in Active Directory, one of about 100 in the world, and a Microsoft MVP. I've
spoken at Black Hat last year and this year and DEF CON last year and this year and I'm very
excited to talk to you about some AD security stuff. I'm a security consultant and researcher
and I own and operate ADsecurity.org, which hopefully you're all aware of. So we're going to
talk about some key AD components from a security perspective, things I think that security
professionals should know about. Some offensive PowerShell stuff, basically how you can
bypass some of the new PowerShell version 5 security features. Effective AD recon and then
some of the defenses you'll run into as a Red Teamer and how to bypass them. And then we'll
wrap up with a checklist.
So for the Red Teamers in the room, this is what hacking looks like, right? Get full
access. Score! Love hackers, right? Or maybe you've done this. Of course you've repelled from the
top of the warehouse over the server and you have extracted the information, right? And of
course everyone has done the Tom Cruise move when hacking a system. You're hanging over the
computer and typing stuff in. Close to it, right? It looks more like this, like PowerShell
Empire, Mimikatz.
Oh, so close! But there's differing views of Active Directory. The administrator, the
security professional and the attacker have different perspectives of what Active Directory
looks like. None of them have the complete picture of what it is. The Active Directory
administrator and engineer, their perspective of Active Directory is through their tools.
80 users computers, domains and trust, through policy, sites and services, some PowerShell.
And the security professional's view of PowerShell is their perspective is from the
Active Directory is through their SIM tool, the vulnerability scanner, the events, the event
log. The attacker's perspective is much different. They're getting a lot of information about
what's going on in the environment. When you red team in Active Directory, you do recon, grab
some credentials, go from there, go from there, grab some credentials, and then DA, pop the
champagne, right? Okay, that's interesting. Thanks, Lee. So note to future speakers, when you
send your slides to someone and they send them back to you, make sure you check them before
you get up in front of DEF CON. So thank you, Lee Holmes.
All right. Let's get... Okay. Let's talk about Active Directory security. I'll try to recover
from that. So an Active Directory force is like the UFP from Star Trek. You've got the United
Federation of Planets. You've got a lot of starships. They're all one part of one happy
family, right? And in this analogy, every starship is a domain joined to the UFP forest. The
executive officers on the ship are the domain admins for their ship or domain. And if a ship's
executive officer, domain admin, is compromised, then so is the ship. In the instance of the
USS Reliant, CON is able to compromise one of the executive officers and own that ship. And all of a
sudden, they have critical systems on it. And then since two ships come together, they're all part of
one happy federation and one forest. They're all implicitly trusted. Which can lead to some really
interesting scenarios, like where one officer on one ship can control critical systems on another,
like shields. So CON was a bit dismayed that admins in one domain could control domain resources in
another and effectively become a domain admin on that other domain. So if you're a blue team member,
don't be like CON. If you're a red team member, it's awesome, because that means that in a multi-domain
forest environment, you compromise one domain, you compromise the entire forest. So let's talk
about domain controllers for a minute. We know that you take a member server, you run DC promo, it
promos up to a domain controller, right? You have, there's a template NTDS.dit Active Directory
database file on every member server that is used to seed that initial database. And that domain
controller that's being promoted will pull the domain data from the server and it will be able to
run other domain controllers in that domain to then fill that Active Directory database with the
domain information. Such as user names, passwords, computers have passwords, there are passwords in
there also. Trusts have passwords, it's in there also. And so the users connect to these domain
controllers for authentication and directory services, as do applications. So these are the
critical servers in Active Directory. They host the global catalog. The global catalog can be
thought of as a partition that goes across and crosses all the domains in the Active Directory.
Forest. Where it has information about every object in the Active Directory Forest but a subset of the
attributes. This means if you're doing some recon and you want to know about all the users in the
whole AD Forest, you just connect to the GC port on the domain controller and query that. Instead of
connecting to every single domain controller. So if DNS is used on a domain controller and the domain
controller hosts it, oftentimes when you have AD integrated DNS, this means that DNS information is
stored in Active Directory and replicated through Active Directory. So then we have read only
domain controllers, which is this really weird animal that Microsoft came up with in 2008. So it's
read only DC services, read only DNS, read only SysBall. This means that when you run into a read
only domain controller environment, it cannot replicate or send modifications to Active Directory to
domain controllers. It's not allowed to. And it has its own Curb TGT account, which means that
that Kerberos is cryptographically isolated from the rest of the domain. And the read only
domain controller does not have any passwords on it relating to that domain by default. You
have to actually add them to a group so that their passwords can be cached there. So when a
user logs on to a site that has a read only domain controller, their password isn't on that
read only. So the read only sends their authentication request to a writable and then the
writable services that authentication request, at which point the read only says, well, give me
the password for this user. And the writable will check to see if that's allowed or disallowed
based on group membership and then either send the password down to the read only or not. This
means that there's certain passwords that will be on read onlys. Read onlys are not trusted at
the same level as regular domain controllers. So what this means is that if you find an
administrator of a read only domain controller, which you can find by looking at the managed
of attribute for that domain controller, you can find a read only domain controller that
read only. You can compromise that and then you can compromise the passwords of the accounts
that are stored on the read only. There's two really interesting attributes with read onlys.
Authenticated to account list. These are all of the accounts that have authenticated to the
read only domain controller. Doesn't mean there are passwords on it. That's the revealed list. So
if you run into an environment with read only domain controllers, enumerate the membership or
the values that are in the revealed list attribute for the read onlys. And then you'll know
all the passwords that are on there.
Technically the environment and the administrators are supposed to add admins to the denied RODC
replication group. But they don't often do that. And admin accounts can end up on read onlys. So how
do clients discover DNS? Or I'm sorry, domain controllers? Well, DNS, we run DNS query, we get the
SRV records for domain controllers. Or we can use ADSI if we have PowerShell which is highly
recommended. But how do clients do this? Well, we have a domain controller that's built into the
have network subnets in the real world, right? That's how stuff talks to each other. But
you take those network subnets and you put them in Active Directory and associate them
with sites. And this maps AD to the physical world. This enables a client in one location
to communicate with the domain controller in that same location or at least nearby as
well as resources like DFS shares. The interesting thing is that if a client asks the domain
controller what site I'm in and the domain controller can't map that client's IP address
to a subnet, DC goes, I have no idea. Try again. That client goes, hey, domain controller,
what site am I in? Says, I don't know, try again. And it happens several times and finally
the client gives up and just picks a domain controller. So this is interesting because
that means logs may actually be on a totally different domain controller for that activity
for that computer than what the IR team or what the blue team is looking for. If they
haven't configured sites correctly. So group policy is a way to manage user and group sorry,
user and computer.
Policy and security settings. You create a group policy, you configure the settings
on it, you link it to an OU or a domain. And you have the group policy object which is
in AD. The computer boots up. It identifies what OU it's in, what group policies are
applied. There's a link in that group policy object to SysVol to say these are where those
files are, those group policy files and settings that need to be applied. So it copies down
those files and applies them. The interesting thing here, and it works the same for users,
the interesting thing here is if you can insert yourself
between that domain controller SysVol share and that client and get the client to connect
to your SysVol share, you can actually have that client run your own version of that group
policy. Also, if you can modify the group policy object and directory or those setting
files in SysVol, then you can have that computer apply those policy settings. Well,
group policy has a lot of capabilities. So this could be adding local administrators,
adding update service, you can add or update services, deploying scheduled tasks and so
on in software, et cetera.
So let's talk about some of the more fun stuff. PowerShell. Everyone uses PowerShell now,
right, as an attack tool. It's awesome. Run code memory without touching disk. Download and
execute code from another system. Interface with .NET and the window APIs. There's been
nothing like it on the Windows platform before. And about six years ago at DEF CON 18, Dave
Kennedy and Josh Kelly talked about PowerShell, OMFG. I mean, it was amazing and they talked
about a lot of the great features that PowerShell has for attackers and for red teamers. And
guess what? Ransomware, I think the ransomware authors have just viewed that because they're
starting to use these techniques. And in 2012, just a couple years later, Matt Graber
released PowerSploit, which is effectively the foundational PowerShell attack tool framework
that just about all of the PowerShell attack tools leverage, which includes invoke
Mimikatz. PowerShell version 5, great for blue teamers. Red teamers, you have to tiptoe
a little more carefully once PowerShell version 5 security is enabled. Because what this means
is if they have script lock logging enabled, even if you've obfuscated your PowerShell code
before it's executed by the PowerShell engine, whatever that final code is that's been
deobfuscated, it gets logged to the event log in 4104. And if they've enabled system-wide
transcript files, this is really interesting, because they'll have set up a write once share
on the network where everything you type into PowerShell, it's going to be in the power
shell on the computer that has version 5 with this enabled. That transcript file will be sent,
streamed effectively to that network share. So it's per computer, per user, which means they'll
have an over the shoulder transcript of everything that was typed, including any typos, which
is always interesting. Constrained language mode is a version of PowerShell or language mode
for PowerShell which locks PowerShell down to the base elements. So no .NET, no API calls,
invoke Mimikatz will not work in constrained language mode. If an environment has PowerShell
version 5 and app locker in allow mode, PowerShell locks down in constrained language mode
automatically. And in Windows 10 it gets even more interesting because Windows 10 introduces
the AMSI, the anti-malware scan interface where any PowerShell code or VBScript code, before
it's executed by the PowerShell engine, it's kicked over to the AMSI, which sends it over to the
anti-malware interface. So it's going to be a very complex experience. And the only reason we're
solution. And the anti-malware solution will give a thumbs up or a thumbs down. If it's a
thumbs down, PowerShell will not execute that code. Be it downloaded from the internet and run
in memory or run from a script. Now there's only a couple of vendors that support AMSI. So
red teamers, you're still in good shape. Microsoft supports it and AVG. I don't know why. We're
still waiting on McAfee and Symantec to catch up I guess. But there's also ways to bypass
AMSI. If you're using an executable that's calling PowerShell code and you drop your custom
AMSI.dll file in that same location, you can effectively hijack the AMSI calls and just say,
no, no, no, this code is okay. Don't worry about it. Or Mac Graber, PowerSploit author, he
figured out how to fit into a tweet the PowerShell command that bypasses AMSI. Pretty
awesome. Microsoft is working on it. I'm sure you've heard of it. Microsoft is working on it.
This is a year later. Not the tweet. The tweet is only a couple of months old. The anniversary
update for Windows 10 is out so maybe that will fix it. So Lee Christensen released unmanaged
PowerShell not that long ago. It's been rolled into Metasploit. Basically this allows you to
call a lot of PowerShell commands and run PowerShell code without calling PowerShell.exe
among other things. And one of my favorite PowerShell attack tools, PS attack, is a single
executable which contains some of the popular and best PowerShell attack tools that are out
there. It encrypts them into an executable and there's a build tool so you can custom encrypt
your own. And when it runs, it decrypts these files or these PowerShell functions into
memory where you can run them. And guess what? Constrained language mode is no longer a
problem. Because when you run PowerShell code from an executable, it bypasses the standard
mechanism that it uses to run PowerShell. And that's what Microsoft is doing. Microsoft is
making sure that it handles constrained and language mode because Microsoft wanted to make
sure it was compatible for all the applications that may be calling PowerShell. What about
PowerShell version 5 logging? It bypasses that also. Why does this happen? Well, in Windows
7, you have PowerShell version 2 as your base level PowerShell version. And then when you
install PowerShell level 5 or version 5, it kind of layers on top of that. So PS attack,
through unmanaged PowerShell and some other fun trickery, actually calls the system dot
management dot automation dot DLL that is PowerShell at that lower level version, which is
version 2, which enables it to bypass and make sure that all of that information, the script code
and the results are not logged. Now, smarter organizations will remove PowerShell version 2
from Windows 10, which you can uncheck the box. And when that happens, this log just flows with
data when you run PS attack. So let's talk about some fun and interesting things about PowerShell.
First of all, effective Active Directory recon. Ideally getting more information about the
environment than the AD admins. So I'm going to talk a lot about PowerView, written by my
friend Will Harmjoy. So PowerView has a lot of great tools in order to get information about
Active Directory. And I'm going to call a bunch of them out. So that way hopefully you can start
adding this to your toolkit. At the top of the graphics is the PowerView command. I'm also
comparing that with the Active Directory PowerShell module, which is available on the Windows
servers and the computers, the workstations if it's installed and configured. So that way you can do
some comparison. But we get information about the Active Directory forest. We can get the name of the
forest, the sites that are in the forest so that we can map out what's in that environment. In fact,
a really effective way to get information about an Active Directory environment or enterprise is to
pull the site information and the subnet information and you can effectively map out the entire
network just with Active Directory. You can get information about the domains that are stored in
that forest. The global catalog.
Microsoft recommends that every domain controller is a global catalog. So this means that with one
command you can get a list of pretty much all the domain controllers in the organization.
Application partitions. So this will show you, for example, in the graphic right here you can see
that there's DNS that's integrated in Active Directory because they're in application partitions.
The forest mode. Here it says 2008 R2 forest. That tells me what security enhancements are not
available to those admins in this Active Directory environment. And then of course we see the
schema and the domain naming FISMOs are. We look at the domain information. What forest is in. All of
the domain controllers. Any child domains. The domain mode. Again, telling us what kind of
security is available. The PDC emulator. So if you're a red teamer and you want to know what
domain controller to connect to when you do all your activity, you might want to target the PDC
emulator. Why is that? It is the busiest domain controller on the network. It is also the best
connected by Microsoft recommendations. You could also do that with the PDC emulator. You could also
target one that's all the way, you know, at a branch office somewhere. But the logs on the PDC are
going to be super busy. And it's also typically a best practice to co-host all the FISMOs on the
same domain controller. So it's going to be extra busy. So we have forest. We have domains. We've
talked about Star Trek and how awesome it is. But let's talk about trust for a minute. If an
organization has trust to other business units in their environment, they may have actual
and accidentally compromised their environment. Because a lot of times they create another
domain or another forest because of trust issues, right? They're like, I don't really trust that
business unit. R&D, they kind of do their own thing. They're kind of cowboys and cowgirls. We'll
let them do their thing. But then they create a trust and say we trust everyone in that domain.
And then they'll do a two-way trust. And Will Harmjai has covered a lot of good information
about exploiting across trust. So when you dig for golden active directory, you're looking for
default and weak passwords, right? I found passwords stored in user attributes. So check the
description fields for accounts. Check for the extension attributes, those custom attributes.
Sensitive data can be stored in active directory because the administrator doesn't realize
that all of these attributes, at least most of them, are available for authenticated users to
read. There is an attribute called a confidential attribute which by default only domain
admins can view. That's where sensitive stuff should be stored. That's where bit lock
or keys are stored by default. That's where the last passwords are stored by default. Deleted
objects. So when an active directory admin deletes an object in active directory, is it
gone? No. No. I'm here. No. No. There you go. Exactly. You know, right? It's not deleted. It's
marked as deleted. It's hidden. But the data is still there. And so sometimes admins will create
an account for, I don't know, a CEO and put some information in there. Like, I don't know, I'm
like a home phone number. Like, oh, I shouldn't have done that. Delete. Guess what? It's
still an active directory. You can search for objects that have the is deleted flag and pull
that and look at it. And you might find some very interesting information. So I'm going to
refer to Will Harmjai on most of the user and admin hunting activities because he covers it
far better than I do and he has a lot of sessions on it. But effectively using invoke user
hunter as part of power view to go through and identify user home directory servers and chairs,
profile pass servers and chairs, log on script pass, run get nest session against each of them and
get information about where they're logged on. And then you can start mapping out who is where
and what rights they have. But even better than that, go to the various group session on Saturday
at 1 o'clock on Bloodhound, which they announced at B-Sides Las Vegas just a couple days ago.
Bloodhound enables you to use power view to query and use the power view to query and use the power
view to get information, get information about the active directory environment, put it into a graph
database and graph out all of the connection points between users and groups and computers. And
very quickly and easily identify that this user can go to this group, can have access, admin
access to this computer, has admin access to this computer, where this domain admin is logged on
to and now I have domain admin access. So the initial gathering information takes a little while, but that graphing,
is very quick. So I highly recommend you check that out. It's called Bloodhound. So there's some
interesting user properties on the user objects. Last log on date. Password last set. Admin count is
a really interesting one. Because if admin count is set to one, it's very likely that user account
is a member of domain admins or another privileged group. Because there's a process that actually
runs every 60 minutes to protect privileged groups in active directory. And it stamps them with admin
count equals one. It doesn't go back later on and remove it. So you could have some false positives
here. But it can provide some really interesting information. SID history is another interesting one.
SID history attribute can contain a SID from another user and provide the same level of access as
that user. It's effectively permission cloning. So if you find user accounts with SID history, and
that SID history is for another user that has some really interesting capabilities and rights, you
could probably clone that or use that account. Custom attributes contains some really interesting
information. A lot of times organizations code or categorize users using custom attributes.
And if there's data in the service principal name, that means that this user account is a service
account, is a Kerberos service account. Same thing for computer objects. Let me just call out that
these attribute names are specific to the active directory PowerShell module command links. So
they may not translate exactly. Last log on date. So this is effectively when that computer is last
rebooted. So what you can do is you get a list of all the computers, find out when they've last
rebooted, look at password last set to see if they're still active on the network. If a computer
hasn't updated their password last set attribute in, say, 60 days, because by default all the
Windows computers should update at around 30, then if they haven't updated in that time, that
computer may not be on the network. But if they have updated within that time frame, and the
last log on date is six months or eight months, that system hasn't been patched. That system is not
patched in a long time. So that may be something that you want to look more closely at. And
Windows computers by default register their operating system and information related
information in active directory. But so does Linux. So does Mac. So do some storage devices
like NetApp, EMC. So you can find information about what's in active directory just by asking
active directory for it. Service principal name. You can get the information about the
Kerberos enterprise services on these computers. And then the last two are related to the
Kerberos delegation. And I spoke about how to leverage Kerberos unconstrained delegation to
compromise a domain last year at Black Hat. Did you know that you can do DNS lookups via LDAP?
It's pretty cool, right? I don't have to ask DNS where it's probably logged and there's some
information about what people are querying for. I can just look at active directory. Say,
okay, give me a list of these computers, all the domain controllers and all their IP addresses.
And it's an LDAP call. Sure. Here you go. Or I can get, I can get a list of all the IP addresses.
I can do reverse lookups. What's the site, what's this computer related to this IP address?
Even if there's not pointer records configured in DNS because this is all through active
directory. So in the old days we had to actually do port scanning to find enterprise
services. Nowadays we can use something that I call spin scanning which is much more efficient
because Kerberos services have to have a service principal name associated in active
directory, registered in active directory. So there's a number of spin types like MSSQL, SVC,
TermServe, WSMAN, FEMService, ExchangeMDB. We can search for these. We can ask active
directory for this information and it'll give it to us. So we can find all the SQL servers very
easily. And the format has the spin type, server name and SQL often has a port number or an
instance at the end. So we can get this information by just asking the active directory domain
controller and we can get a list of all the servers, their port number, the service accounts
associated with them and some additional information. So we can get a list of all the servers, their
port number, their port number, their information. We can also request all of the user accounts
that have service principal names associated with them, which are service counts. And we can
leverage a tool called Kerberos, it takes advantage of how Kerberos works, where we can
request a service ticket for a specific service principal name or service principal names,
and then the domain controller is going to look at that user account associated with that spin
and it's going to encrypt that using that password hash for that user account, which is a basic
and then send it back to us. And if we've requested RC4 encryption, guess what? That
password hash is the NTLM password hash. So we can take that service ticket, encrypt it with
RC4, encrypt it with that service account's NTLM password hash, take it offline to our
attacker machine, and we can run Kerberos against it, which takes a dictionary list, goes
through each of those words, does a one-way hash function and gets the NTLM password hash and
then attempts to decrypt that service ticket using that. And if it's right, if it can open it,
then it's guessed the password for that service account offline without any admin access,
without ever touching the target or communicating with the target. So the old school way for
group enumeration, finding your domain admins, is what? Group name, domain admin. We have two.
Luke Skywalker, ADS administrator.
We can also enumerate the membership of the RDC groups, Denied RDC Password Replication Group,
because enterprises should be configuring this so that way these admins are not storing their
passwords on RDCs, especially if they have RDCs in the environment. But remember when I mentioned
admin count equals one gets stamped for privileged groups and accounts? Well, there's four here.
CurbTDT is one of those special groups, so we'll put that to the side. But there were two members
of Denied Admins, ADS administrator and Luke Skywalker. When we look for admin count
equals one, we have another one, Kyler Wren. Where did he come from? He's a member of the
administrators group in the domain. So by looking for admin count equals one, we can get a lot of
information about potentially privileged accounts. Remember there could be some false positives,
without any group enumeration. And then one of my favorite components of PowerView is the
ability to identify what Active Directory groups have local administrator rights in the environment.
Because when you have a large environment, it's a lot more than just the number of people in the
environment. It's very difficult to manage all these workstations. So what are you going to do?
You're going to create a group policy, say that your workstation admin's group in Active Directory,
it should be a member of local administrators for all my workstations. So we're going to take that
group policy, configure it, and apply it to the OU that has all the workstations. Well, PowerView can
pull that information out and identify which AD admin groups or AD groups have admin access to
which computers. And we can do that by targeting a specific OU. And then we can get a list of what
groups have admin access to which computers. And we can do that by targeting a specific OU. And then we can get a list of what group
group policies apply. And here, it's the workstation admin's group. And then the second command that we run will
give us a list of all of the computers in that OU. And then, of course, all we need to do is enumerate the
membership of workstation admins, and then we know who to target. So I tried to work in the DEF CON theme this
year, attack of the machines. So computers with admin rights. Why are people putting computer accounts in admin
groups? I don't know. I keep finding it. What does this mean? If you find computer accounts, they have a
dollar sign at the end.
In an admin group, all you have to do is compromise that computer account and get system on it. And at that point, that
system account has those admin rights in Active Directory. So in this case, they added a regular computer to
workstation admins. We can discover regular users with admin rights. So users typically have an email address,
especially if you're running an exchange in the organization. Or they have a specific naming format, like firstname.labs.
Name. We can look for admin accounts or user accounts in admin groups this way. Now, exchange admins often will have an email
address associated with them, so you have to filter some of those out. But it's a nice way to find regular user accounts that
have more rights than they should. We can also look for virtual admins, hyper V admins, VM or admins that are often groups
in Active Directory that have full admin access to the virtualization platform. Compromise those accounts, you own the
infrastructure. But we can also follow the protocol to get a data set of the clients. So there are lots of ways to find the right
the delegation in Active Directory. What delegation has been configured on the OUs in the domain.
These are permissions that have been configured directly on the OUs. And here we can see that
someone has delegated to the accounts OU help desk level 2 and help desk level 3. But they made
a mistake. Both of those tiered levels have full rights on all objects. An obvious mistake.
Except for the fact that ACLs are very difficult to parse through and look at and identify. So
this means level 3 has far more rights than they should because they probably should just have
reset password access. So we enumerate that group. We see C3PO is the user account that's a
member of that group. So we target his account. We tell him we speak bocce and we're in good
shape, right? We can also use the PowerSpoil tool get GPP password to identify credentials in
SysVol. It scans the SysVol share on the domain controller. It identifies XML files that
have a C password attribute. And then it scans the SysVol share on the domain controller. It
scans the SysVol share on the domain controller. And that gobbledygook that you see is that
encrypted password string which we can decrypt because Microsoft published the decryption key.
Thank you. When an organization has exchange, we can also get information about who they
commonly email. In Outlook, you have your contacts. People should be putting their most
commonly emailed people in the contacts field, in the contacts component. But we can add
contacts to Active Directory so they should be able to access those contacts. So we can
show up in the GAL. But there are objects in Active Directory now, which means we can get a list
of all the contacts in the organization, which is moderately interesting. Much more interesting to
me is actually parsing through that and identifying what domains they associate with and what
they email. And as we can see here, it's Empire, Rebel Alliance, Rebel Fleet, Starkiller, the
Alliance, First Order. I think they're playing both sides. It's really interesting. We can also
get information about the domain password policy. We can also get information about the domain password
policies. Again, at the top, using Power View, which also gives us the Kerberos policy. In the
bottom, using the Active Directory PowerShell module. And this is the default password policy. So
if you see that the min password length is seven in an organization, write it up and say, please
don't do that. If you need to do something like that, use fine-grain password policies, which, of
course, we can pull as a domain user. And oftentimes, the best way to manage passwords for administrators
and service accounts is to create a fine-grain password policy that says that they have to have
longer passwords than the rest of the domain. So we can also discover all the group policies in the
organization that authenticate users have read access, which is all of them by default. And so we
can look at them. We can see, all right, there's a domain PowerShell logging policy, a full
auditing policy, prevent local account logon. That's interesting. Add server admins, local
administrator group, AdWorks. Okay. Emmet config, AppLocker config. And then we have a domain
user, and LAPS. That's interesting. So we can actually pull the AppLocker whitelisting policy from Active
Directory. Now, I cheated. It's in binary format. I just converted it to text and parsed it. But I got
enough information here that tells me that they're running AppLocker in the default configuration
setting. So now I know where I can drop executables and run them from. These policies should be
locked down so authenticated users don't have read access. Emmet configuration. Now I know how they're protecting their
URLs, their executables. Again, I cheated. It's a binary file in SysVault, but I converted it to text. But I can get a
good amount of information from that. And there's a LAPS policy, but it's not that interesting, because it's
just going to say how long that password is and how often I change it. More interesting is using
PowerView to pull the permissions for who has rights to the LAPS password attribute, where that clear
text password is stored, which is MS, MCS, ADM, PWB. And with this information, we can identify
who has the ability to view the LAPS passwords. So we can go after those accounts. Because once we have
that, we can then pull from Active Directory a list of all of the local admin accounts on all the
computers that those users have view access to. So I wrote my own, which has a very nice list of the
groups that actually have LAPS delegation and where they apply to. And I'll be working with Will
Harmjoy to get this into PowerView, so that way you have some good information as well. So I'm going to go
back to PowerView and I'm going to show you how to do that. So let's talk about Active Directory
defenses and bypasses. Organizations say, you shall not pass. Are they right? No. I didn't know
Captain John Luke Picard was Gandalf, but whatever. So Florian Roth posted a really great graphic
that shows the common exploit pass for Windows. They posted this on Twitter. I'm not going to cover
this, but it's there for reference. So you run through the same process you always have when you run
into these defenses, when they're actually setting up good quality defenses in the organization. One
thing that's been popped around a lot in the past year on Twitter is the concept of honey tokens or
honey credentials, which for the instance of this talk, are credentials injected into memory,
deployed somehow, often using run as net only. But these may or may not be real on the network. So
if you drop on a box and you dump credentials and you're like, wow, this looks great. I got all these
credentials. Check AD to see if it's a valid account. Check to see if it makes sense. Does it
pass the sniff test? Or is it a trap? It's a trap. So if they're using the Microsoft local admin
password solution or LAPS, they're randomizing all of those local administrator passwords on
the computer, which is great. In fact, in your red team report at the end when you own them
completely, you should say, yeah, use LAPS or something like that because I use your local
admin accounts to jump from one to one or the other, and I like my job to have some
challenge and some mystery in it. So if they have LAPS configured, you can use power up to get
local admin rights, obviously dump credentials, look for service accounts, the usual stuff. You
can find AD accounts that have local admin rights. You can find AD accounts with LAPS password
view rights or a lot of organizations deploy LAPS, but LAPS only controls one password, one
account's password, which is usually the default admin account. And a lot of organizations still
have a lot of additional local admin accounts, which means they're not going to be able to use that. So if you're
using LAPS, you should pay attention to that because it's going to be a lot of trouble.
So those are some of the things that happening to Internet users.
Network segmentation is becoming very popular. Admin systems are placed in a separate network
segment where you can't easily get to them, but there's always a way. Find the admin accounts,
figure out where they log on. Compromise the patching system because they may have isolated
those admin computers and workstations and servers but they're still using the same SCCM to patch
their workstations, their servers, their domain controllers. Stop patching the main controllers
with the same system used to patch everything else. So that's an important point. And I think the
accounts. Or maybe there's no members in domain admins but everyone forgets about the
administrator's account. Domain admins gets their active directory rights through being a
member of the domain administrator's group. Domain administrator's has full right to AD.
Domain admins have full rights to workstations and servers by default in addition. So look
for custom delegation like tier or level or workstation or server admins because someone has
rights somewhere. Microsoft has a great white paper about the privilege admin workstation which
is really the baseline for what should be an admin workstation environment. But organizations
cheat and it's very difficult to get this right. It's difficult to go through the whole list of
steps and configure it properly. So if you compromise the install media or the patching
system then you can get admin rights on the local admin workstations. Or you compromise the
communication which is supposed to be encrypted using IPsec or similar which may not be. Jump
or Admin rights are not the same as Admin rights on the local admin workstations. They're
very popular. We have this one server, all our admins go to it. They log on to that. But if
they're not using an admin workstation, they're using the regular user workstation, all we need
to do is drop a key logger on there. PowerSploit has a great PowerShell based key logger. We
can get those credentials when they type them into their RDP session. Or if they have two
factor enabled on RDP, two factor often isn't enabled, or possible to my knowledge, for
WMI or WinRM PowerShell remoting, PSX or NEME power shell remoting. So if you have a
power shell, you can use that. If you compromise that jump server, you own the domain. And
if the organization has not separated their admin tiers into tier zero Active Directory
administrators, tier one server admins, application admins, and tier three workstation
admins where they're not supposed to log into each other, and maybe they have one admin server
for all of these, that's easy. Compromise a workstation admin and then jump up to domain
admin. So Microsoft's goal is to get everyone to put their Active Directory admins, their
domain admins, into an admin forest, a red forest. And ultimately their admin accounts that
are at lower tiers into another forest. That way they're protected from the production forest and
all the legacy stuff that's there. Most organizations can't get up to 2012 R2 across all of
their servers and computers. Can't get up to Windows 10 on their workstations. You can do
that in an admin forest. It's a nice recommendation. And Microsoft has a great write up on
it. So you can point them to that. It will make it a lot more difficult to act for the
red teams in the future and the attackers to actually get full Active Directory domain
admin. Because again, you want your job to be interesting, not easy. So there is a universal
bypass for most defenses. Get full access from my first slide. Remember that? No, I'm
just kidding. It's service accounts. Service accounts are the universal bypass for most
defenses. So even if they put all of their Active Directory admins or domain admin user
accounts into that admin forest, usually they're service accounts that have rights. Why? Because
they're over permissioned. They're over permissioned. They're over permissioned. They're over
protection. They're not protected like admins. They're weak passwords. No two factor. And
limited visibility and understanding. There are service accounts that have been in that
organization longer than the people that are administering the server and they have no idea
why those accounts are still there. Or why they have that access. So some interesting Active
Directory facts. All authenticated users have read access to most, if not all, objects and
their attributes. All authenticated users have read access to most, if not all,
contents of Sysfall, which includes group policy and scripts and other things that AD admins just
put in there because they never think anyone will find them, including files with passwords in
them. You're kidding me. Standard users can have elevated rights through the magic of SID
history, even if they're not a member of any group at all. They could even modify a user or group
without elevated rights through custom OU ACLs, custom permissions. Or if they have access to
modified group policy that's linked to the domain or an OU, could take over that group policy and
control the organization. So you're a red teamer. You got domain admin in the organization. Pop the
champagne. Woohoo! We won, right? That was a nice day's work. So we pull the domain admin
account hashes. Well, there's a few other things that you want to get. You want to get the
CurbTGT hashes. We know that. We can create golden tickets with it, right? You also want to grab
the domain controller computer account password hashes. Because even if the organization
changes the first two, you could actually create a silver ticket using that domain controller
computer hash to re-compromise the organization and run Mimikatz DC sync to pull all the
credentials. And I talked about this at DEF CON last year. Interesting fun fact. NetApp, by
default, does not change your computer account passwords in Active Directory unless the admin
goes in and schedules it. It's documented on NetApp site. What does this mean? I pull those
device password hashes for NetApps and other storage devices. I'm sure it's the same on others.
Once I have that, I can create silver tickets and have read access to all the files on those
shares. I learned recently from a red teaming friend of mine that NetApps often by default also
share out on NFS in a Windows environment. So you want to check to make sure that these other
file sharing services are not enabled when they're not needed. DSRM account password hashes are
the default administrator account on the network. So if you want to make sure that you're not
using the domain controller, the RID 500 account, you pull these and they have a DSRM registry key
set to 2, you can actually pass the hash to the domain controller, run Mimikatz and run DC sync
off of it. I talked about this at DerbyCon last year. So security pro's AD checklist. Identify who
has AD admin rights. Identify who has the rights to log on to the domain controllers. This
includes account operators, backup operators, print operators, server operators by default. They have
been changed that a help desk user may have the ability to log on to a domain controller because
they put their help desk groups into account operators. Identify the virtual host admins. They
may be an active directory. They're probably an active directory and they're probably not well
protected. Scan the domains, the OUs, the admin SD holder and group policies for
inappropriate group policy permissions. And in your report, say please protect your active
directory domain admins. Make sure they only log on to admin workstations, admin servers,
don't make my job easy. And limit the service account rights. Go through all of them and figure
out what accounts they need. Go back to that vendor and try to figure out what accounts they need.
So a quick PowerView AD recon cheat sheet. These slides will be posting on ADsecurity.org in
about 15 or 20 minutes automatically. So you'll have all of this. But these are all the
commandlets or functions I ran from PowerView so you can look at them later. So in summary, active
directory stores the history of the organization. Why is this? Because they've deployed active
directory. They've updated it. They've modernized it. It's their organization paradigm for support
and business has changed so they've shifted things. They've moved things in. They've created new
delegation, new delegation groups. But guess what? Most of that old stuff is still there hiding.
You find it, you can exploit. And you can help them fix it. If you ask the right questions of active
directory, you can map the active directory environment and the enterprise far and wide into the
organization. They're far better than what the admins know about. You can update their documentation
for them if they pay you for it. But you can quickly recon the environment in hours if not sooner
depending on the size of the organization. But the business requirements ultimately subvert
security every time. So in your reports, make sure that you highlight this and say, look, if you
want to fix this, you're going to have to spend some money, fix the resources, do what needs to be
done. If you identify the proper leverage and apply it, you will own active directory. And
you will help the organization fix it. Because as a red teamer, your job is to make the blue team
better and help them level up their defenses. So the next time when you get brought in, you run
through your playbook and you go, wow, nice job. And you tell them that. They'll love that. Say, hey,
great job on fixing these things we talked about later. We checked it. You did a great job. And
you'll probably get hired again. So that's my time. Thank you very much for yours. Any questions?
Thank you.