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 shitty 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 shitty 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.