Tip:
Highlight text to annotate it
X
>> JUSTIN HENDRICKS: I'm Justin and I'm going to be going over AD and how you can own it
using management software. And so we'll get started here.
So, introduction. It's going to ‑‑ pretty much it's going to go over isolation and how
you need to isolate AD from everything else and the management that ‑‑ the management
environment of AD and how it's handled. So I'm specifically going to look at SCOM, HPI
load, and hyper‑V and how they can be used to own ADs, essentially. There's no vulnerabilities.
We're going to look at how it's abused if they're not managed right and not configured
properly. So the software used to manage end domain
controllers is often overlooked. As you know, it handles all Windows auth and all the hashes,
which if you're after an environment you want to get all the hashes because once you get
all the hashes you can own any box in the domain, and so ‑‑ so, yeah. It's the
crown jewels of the environments. And recognitions usually look at ID seg, so
they only look at active directory and the OS level ID seg. They don't look at everything
that interacts with active directory. And so background, I'm going to go over SCOM,
which is used for monitoring. Of course, if it's a high‑valued asset, you want to monitor
it right, so you're going to use some sort of monitoring. In this instance we're going
to look at SCOM. There's a SCOM security guide that's available on the internet. It's really
long. Nobody probably read it. They probably hit next, next, next.
There's also out‑of‑band management devices, which is network devices that allow out‑of‑band
management, so if the machine is off, then you can restart it up. It's used for imaging,
et cetera. And so we're going to look at HPI load in
this instance, and then hyper‑V as well. So if you host ‑‑ which hyper‑V is
a virtualization. So if you host AD on a hyper‑V host, then you also need to look at the hyper‑V
host. There's warnings online about it, but it's often overlooked and everybody ignores
the host and only looks at the OS level ID seg; right?
First we'll look at SCOM and it's used for monitoring and alerting. The SCOM SDK service
is what it uses to interact with the agents and everything. It's open up on 5723 and 5724
is what it uses. These are required. These need to be open if you want to access the
SCOM management. Like if you actually want to look at the alerts and everything, these
have to be open. So often times organizations have these open in the firewall in order to
look at alerts outside the environment because they want to act upon them, right?
And Nmap, for instance, won't scan for these. So if you use Nmap, then you'll need to add
these to the list and you'll see why in a minute. And the SCOM agent, as well, which
runs on every monitored machine, it runs as local system, and so it's great because it's
admin access. So you'll see in a minute. So abusing the functionality of SCOM. So SCOM
has this beautiful feature called "Task" and they let you run arbitrary DB script on every
monitored machine. So, obviously, if you can own the SCOM app or the machine, then you
can run arbitrary script as local system on every managed machine. And let's see, then
you have to be a member of SCOM administrator's or author's role, which is application level
roles within SCOM and you're able to then run these, obviously.
And so, so if you have a SCOM instance, then you need to have another instance that only
monitors AD and then one instance that monitors everything else. So, obviously, they need
to be isolated. That's the whole goal here. So here's an overview of the architecture,
which is on MSDN ‑‑ or yeah. So it uses the SDK, which then executes on the alert
management server and then that runs the script on the agent‑managed machines and it usually
runs as whatever the agent is running as, and by default it runs as local system, which
I already mentioned. So they have an operations manager console
as well, and that uses the SDK as well, but you can also use their libraries that they
have as well. So here's just a screenshot of the installation.
As you can see, by default it runs as local system.
And there's many warnings out there on the Internet that it can be very dangerous and
it's bad, but nobody reads them, of course, so we're going to abuse it.
So demo time. I hope this is showing here. So we've got a few demos.
>> AUDIENCE: Might have to adjust the resolution. >> JUSTIN HENDRICKS: Okay.
Okay. Now demo time. The demo gods are not with me today.
All right. There we go, we have something. (Applause.)
>> JUSTIN HENDRICKS: It's only on that screen, so I have to look down at that.
All right. Well ‑‑ okay. Cool. All right. So pretty much here's the SCOM
Operations Manager. So we're going to use it to auth these in a low privileged account,
and that's in the SCOM administrator's role, because that's how it's added. So the SCOM
console lists all the machines. One machine is a domain controller. Our new SCOM, what
we're going to execute is going to execute a reverse HTTPS show, and the DB script is
written out to hard disk and then executed in the SCOM task.
So as you can see there, we're just running arbitrary power show, and then running the
script that's going to start a reverse show. So we'll copy that, create a new SCOM task
under the authoring. So next we'll just call it interpreter. And you can hide the name
if you're going to be sneaky. Then we want to run it on all Windows computers. So increase
the timeout value to half an hour, that way we have plenty to migrate into another process.
And then, so we create the task. And so this SCOM SD ‑‑ so the actual user that is
executing and has access into this, it only has access on the SCOM machine. So, obviously,
it's not an admin in AD. So we're going to run the task. So we ran them against each
of the machines; one is a domain controller. And you'll see we got the shells back.
(Applause.) >> JUSTIN HENDRICKS: So it runs as local system.
And so we're just going to open a session on the domain controller. We get the ‑‑
let me just, yeah, we'll migrate ‑‑ we're not migrating yet. So yeah, it runs as local
system by default. Then we're just going to list the processes, migrate into spooler,
because after half an hour it will end because that's what we have our execution as. So you
want to hurry up and migrate and then ‑‑ and the migrate processes empty the hashes,
end of story. There we go. There you go. There's the hashes
and now we've owned that domain. (Applause.)
>> JUSTIN HENDRICKS: Then you can also do it, you can also write arbitrary XZs. You
can write a reverse shell in DB script as well, which works. There's ‑‑ and so
in this instance we're just going to write an arbitrary XZ. So I'll skip ahead ‑‑
I also mention here, here's the SCOM administrators and there's the SCOM SDK users that is admins
in the SCOM app and not in AD, obviously. And so, so if you're in admin in the SCOM
app, then you're essentially an admin. So we'll just create another one here. It's
pretty much the same thing. I'll skip through it. Except it's writing out an arbitrary XZ
and then executing it. It runs it. And you can run this across however many machines
there are. So it will, it will spin up an instance on every agent, so. And then it just
runs and empties the hashes out. And one last example here that I had was the
SCOM ‑‑ so we're at 5724 is used by the SCOM SDK and the operations manager uses 57 ‑‑
5723. So if that's not open, but 5724 is open, then you can still use the SDK libraries that
they have, you can execute everything using that use as well, you just have to implement
it on your own. In this example we're going to import new management pack and it's just
going to run arbitrary commands. And this is just a little app that I wrote that uses
the SDK. Really *** app, but it works. So imports to management and then you'll see,
you kind of have an interactive, you know, you can execute whatever you want against
it. So, just another example. All right. We'll move on.
So recommendations. Here, let me switch this back.
Okay. I'll just move on. So recommendations is that the SCOM servers used to monitor AD
need to be isolated and not to rely on SCOM SDK ports open. If they are, they need to
be closed off. SCOM administrators and authors should be limited to only the admins, obviously.
So you'll need another instance that only monitors AD. Move engineers and everybody
else into the read only or operator roles and that won't allow them to execute new agent,
and also to reduce the agent, as well, so it doesn't need to run as local system.
And there's a official security guide, too, that you can read.
My bad. All right. So, for conclusion. So SCOM tasks
all need to be audited, that way if there's any hidden task in there, they need to be
audited. So it also has the execution logs in SCOM.
And by default it's one week, but you can edit that. So it's good if you want to increase
it or if you're the bad guy and you want to remove the execution logs, you can also edit
it. Then it also logs every auth in the operations manager event log. So here's just a screenshot
of the history, so you can obviously edit it to be zero days and nobody will know what ran,
or you can edit it for one month if you want to audit.
So next we're going to go over out‑of‑band management devices. Every machine usually
has out‑of‑band management hardware used for monitoring and maintenance. So it's used
for imaging, for restarting if you run out of hard disk space, et cetera, et cetera.
It's for emergencies, essentially. So the admin interface is usually accessed over
SSH or IPMI, HTTPS as well. It's equivalent to actually having the box in your office
in your hands; right? So, and many of them, all except for HP, have really *** default
passwords. So most of the time organizations might not update those so you can use that
as access. There's also, about a month ago Rapid 7 released
some really nice remote root exploits that allow ‑‑ that allow admin access without
auth. That's really useful. They're often hard to update because you have to ‑‑
it's usually very manual and so organizations might not update.
And there's ‑‑ here's an example of HPI where they have an overwrite chip which is
actually on the machine. If it's enabled, then it ‑‑ then you don't have to auth
at all. So it's, you know, it's awesome if you're after that machine. So here's a list
of common user names. IO is the only one that's actually updated and all the rest have ‑‑
So one more demo. Here, hang on. Let me switch this back. The
mouse isn't coming over. Give me one sec, it's not cooperating.
There you go. So this is HPI load here and what's going to happen is we're going to mount
an ISO and we're going start into Knoppix and then do sticky keys and that's pretty
much it. So ‑‑ so you mount the ISO in the HPI integrated remote.
Let me skip back here. All right. So we mount the ISO here within
the admin interface. We start the machine up, and rather than making you watch it start
up, I'll skip ahead here. So it starts in the Knoppix, and we sticky key the box that
way we can get access. So we're just going to replace the sen.exe with cmd.exe and that's
one way to get access if you actually have access to the box.
So we're going to rename that cmd.exe, paste, override it, restart the box. So we unlock
the ISO, restart it back up, hit the shift key five times and there you go.
So, obviously, you guys know how it works. We hit the shift key five times and then we
have a show ‑‑ a system, sorry. (Applause.)
>> JUSTIN HENDRICKS: It's nothing new. And then here you can just add another user, empty
the hashes, et cetera, et cetera. So we just add a user and then we get access
to the box. Sticky keys off. No. All right. We'll move on here. We're running
out of time. Okay. So recommendations. Update the default password. It should always be
updated, obviously. Have regular patching for the out‑of‑band devices. Monitor audit
logs for unauthorized access. Configure ‑‑ factor off, if you're able to. You should
also have another management environment, you know, for all these out‑of‑band devices.
There's an article online also that you can read that helps with that.
So next we'll go over hyper‑V, it's virtualization software that hosts virtualization machines.
Administrator on the host has admin rights on all the VMs that it hosts, obviously. Here's
another example where you can also start into a live disk and steal the VHD file or ‑‑
either/or, I guess. So here's how you mount an ISO. Once you're
in it, you can steal the MTDS, then you have all the directory and you can extract the
hashes offline, essentially. So all they'll know is the machine unexpectedly restarted,
unless they look at the host audit logs. So recommendations. The hyper‑V, the hyper‑V
host they need to be isolated with AD exactly like everything else and the admins on it
should only be admins. So it's easy principle. And also, you need to protect the ‑‑
protect the VHD files as well. So, yeah, only admin should have access to those.
And it should also be in another management network, if available. There's another article.
Then lastly, vulnerability standards as well. Organizations usually do auth scanning and
those usually have admin rights on every box. So if you're scanning your domain controller
with a domain admin creds, the box or whatever you're using should be treated as a domain
controller. I mean, it's ‑‑ you know. And so, yeah, you can ‑‑ obviously if
you own one of those, then you own AD as well if there's an isolation.
So conclusion is everything that interacts with AD needs to be looked at, so management
stuff also has to be properly secured. And so that's about it.
And here's my information and I'll have everything up online next week.
(Applause)