Credentialed Vulnerability scanning of Domain Controllers

  • 168 Views
  • Last Post 27 April 2017
BrianB posted this 26 April 2017

All:   Is anyone dealing with an issue where the IT Security department as part of their normal process, want to perform a credentialed vulnerability scan of your Domain Controller? If so, how are you locking the credential down such that the service account is not granted domain admin privileges? I am actually wanting to perform credentialed scans of my DC’s to get a better understanding of any flaws. But I also want to make sure they only have just enough privileges to perform the task only.

  Incidentally, I am running Win 2012 R2 DC’s. I believe Server 2016 has the ability to grant JEA, but we cannot upgrade to 2016 yet due to some enterprise software that is not yet certified with 2016 and will drop support if they determine we are on that Domain level.   Brian Britt        

Order By: Standard | Newest | Votes
barkills posted this 26 April 2017

I’m not sure I understand the question.

 

If a vulnerability scan is performed, there is value in it being performed from a non-domain account. There is also value in it being performed from a domain account with no privileges. But having any additional privileges begins to blur

the lines of value. For example, if the account has Backup Operator, Administrator (on DCs), or Domain Admins, it’s obvious that everything is vulnerable.

 

So put into that context, your question seems to be ‘how do I prevent the “normal” user I provide for vulnerability scanning purposes from getting more privileges?’ My response to that is to not give that user any more privileges.

😊 Which is where I find myself wondering what I missed about the question.

 

Taking this a different direction, I think there is abundant evidence that the biggest risks will not be addressed via vulnerability scanning of domain controllers. The biggest risks are compromises of the very abundant domain joined computers,

leading to cached credential compromise, leading to lateral movement on to other domain computers, leading to more privileged cached credentials, repeated until juicy stuff is exposed.



 

Microsoft has a slew of interesting stuff to help protect that well-exercised (and publicized) path to embarrassment and loss: ATA, Privileged Access Workstations (PAWS), Authentication Policies, PAM (just in time privileges!!), LAPS, and

more.

 

Brian

 

show

a-ko posted this 27 April 2017

In my experiences when dealing with this ask is that the security teams don’t actually understand nor know the actual risks of the systems. In your case, Brian A.; you are 110%

correct. This is what security should be focusing on.

 

But in Brian Britt’s standpoint, security teams are basically going out and just buying tools (like Nessus or Tripwire IP360) and going “I need admin rights on all the things

with my tool so I can hit all the things and report on whether or not you’re patching your systems properly.”

 

This is absolutely not a sane security policy, and actually weakens security, since that’s yet another credential that’s exposed now through a 3rd party tool,

that god forbid now has domain admin privileges, likely stored within the tool’s database (which is likely either MySQL or MSSQL).

 

I completely agree with you, and completely disagree with the approach. But in almost every organization that I’ve been in, that attitude will basically get you some very dirty

looks and probably piss a lot of people off.

 

I, personally, have no problem calling this nonsense out for what it is on a public mailing list and someone can be free to disagree with me on that regard

😝

 

Another option is to treat the scanner like any other management tool, and put it inside the “red forest” with JIT credentials.

 

Yet another option is an account that is enabled or disabled based on limited time periods.

 

And yet another option is an account that rotates is password frequently.

 

And yet another option is to finally tell your security team the below, and then get dirty looks as to “Well you’re not cyber security! I know better!”

 

(As you can imagine, I’m VERY EXTREMELY BITTER on this front. We have ended up having to give DA privileges)

 

Server Operator might also work…

 

show

spam posted this 27 April 2017

some regulatory requirements specify a credentialed scan against all

network servers as a condition of accreditation.   On Windows

servers the credentials used typically need quite wide but read only

access to the registry to validate the settings against the

requirements (the same is true of non-DCs, but most people seem more

comfortable giving local admin rights away).





There is definitly value in credentialed scans beyond simple patch

level. How else are you going to pick up insecure service

permissions or unquoted service paths (as two examples that seem to

be found every time), which could be leveraged for priviledge

escalation or lateral movement.  A good assesor knows how to

differentiate between false positives caused by the credentials used

from genuine vulnerabilities (eg reporting a share can be read is

useless if you used a domain admin account - but reporting the share

has everyone read/write because your domain admin rights let it

enumerate the ACLs is more valuable)





However, as you say there are significant risks - the top two

targets for health check teams are often vulnerability assesment and

3rd party management tools. We get round it by creating time-limited

accounts. We'll give you 30 minutes to scan our DCs then the

account  loses domain admin rights. Alternatively, if you're rich

take a look at something like Thycotic Secret Server (not a user but

have looked into it and discarded it based on price), which can tie

in with most vulnerability assesment tools so that no one needs to

know the credentials used.








On 4/27/2017 3:10 AM, Michael Cramer

wrote:














In

my experiences when dealing with this ask is that the

security teams don’t actually understand nor know the actual

risks of the systems. In your case, Brian A.; you are 110%

correct. This is what security should be focusing on.

 

But

in Brian Britt’s standpoint, security teams are basically

going out and just buying tools (like Nessus or Tripwire

IP360) and going “I need admin rights on all the things with

my tool so I can hit all the things and report on whether or

not you’re patching your systems properly.”

 

This

is absolutely not a sane security policy, and actually weakens

security, since that’s yet another credential that’s exposed

now through a 3rd party tool, that god forbid now

has domain admin privileges, likely stored within the tool’s

database (which is likely either MySQL or MSSQL).

 

I

completely agree with you, and completely disagree with the

approach. But in almost every organization that I’ve been

in, that attitude will basically get you some very dirty

looks and probably piss a lot of people off.

 

I,

personally, have no problem calling this nonsense out for

what it is on a public mailing list and someone can be free

to disagree with me on that regard

😝

 

Another

option is to treat the scanner like any other management

tool, and put it inside the “red forest” with JIT

credentials.

 

Yet

another option is an account that is enabled or disabled

based on limited time periods.

 

And

yet another option is an account that rotates is password

frequently.

 

And

yet another option is to finally tell your security team the

below, and then get dirty looks as to “Well you’re not cyber

security! I know better!”

 

(As

you can imagine, I’m VERY EXTREMELY BITTER on this front. We

have ended up having to give DA privileges)

 

Server

Operator might also work…

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx

[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Brian Arkills


Sent: Wednesday, April 26, 2017 4:20 PM


To: Britt, Brian

<brian.britt@xxxxxxxxxxxxxxxx>;

ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] Credentialed Vulnerability

scanning of Domain Controllers





 

I’m not sure I understand the question.

 

If a vulnerability scan is performed, there

is value in it being performed from a non-domain account.

There is also value in it being performed from a domain

account with no privileges. But having any additional

privileges begins to blur the lines of value. For example, if

the account has Backup Operator, Administrator (on DCs), or

Domain Admins, it’s obvious that everything is vulnerable.

 

So put into that context, your question

seems to be ‘how do I prevent the “normal” user I provide for

vulnerability scanning purposes from getting more privileges?’

My response to that is to not give that user any more

privileges.

😊 Which is where I find

myself wondering what I missed about the question.

 

Taking this a different direction, I think

there is abundant evidence that the biggest risks will not be

addressed via vulnerability scanning of domain controllers.

The biggest risks are compromises of the very abundant domain

joined computers, leading to cached credential compromise,

leading to lateral movement on to other domain computers,

leading to more privileged cached credentials, repeated until

juicy stuff is exposed.



 

Microsoft has a slew of interesting stuff

to help protect that well-exercised (and publicized) path to

embarrassment and loss: ATA, Privileged Access Workstations

(PAWS), Authentication Policies, PAM (just in time

privileges!!), LAPS, and more.

 

Brian

show

Jwalton4th posted this 27 April 2017

Michael, you are spot on in your reply below.  This is the exact same thing I am currently going through right now.  I’m providing the “IT Security” team with a very locked down OU so they can test things despite my arguments against they

should not be testing in a production environment, not to mention, why are they even testing?  It’s not their job to implement technology.  The lead of this newly established team left his systems engineer position with a server team to establish this IT Security

team.  He just hasn’t caught on that there is a huge difference between IT Security and being on a server team where you have elevated access.  I have explained several times that IT Security’s job is to audit, monitor, and report.  If there are vulnerabilities

to fix, it’s server teams job to do that.  Who monitors them?  Instead, they spend more time researching products that they believe should be implemented that has nothing to do with auditing or monitoring the domain and network.  I join your bitterness and

I have had some nasty looks (and emails) exchanged between our teams.

 

show

Cynthia posted this 27 April 2017

I wholeheartedly agree with everyone’s take so far.

In order to avoid giving the qualys service account domain admin privileges, I had to add the account as a local administrator to all the servers.

I still didn’t like having to do that much – after all I can use batchpatch to scan servers for patches needed, services that are up after a reboot, etc..



and I don’t have to give batchpatch any admin rights at all.

Nonetheless, I had to so I do have restricted groups set up in the server ou’s with sub-ou’s , so I didn’t have to log in to each one but it was still a bit of work.

Just in case you are visual here’s an example:

 

Servers (ou)

  Base Servers 2012 R2 (ou)

     RestrictedGroupBaseServers2012R2 (group policy)

 

      Contents of policy:

       Computer configuration\Policies\windows settings\security settings\restricted groups\built-in Administrators – make sure to add all currently allowed local admins to the servers as well as the addition.

 



Cynthia Erno



 

show

a-ko posted this 27 April 2017

Unquoted service paths are only a problem when an account can write to a protected area. The actual vulnerability here requires you to be able to write to the root of C:. If something can write to that drive on a Domain Controller,

you have other issues. 




Vuln is this:




If the path is unquoted, and you have C:\Program Files\MyApp\MyApp.exe; and you run it as "LOCAL SYSTEM", an application named "Program.exe" written to C: will be executed instead, and then executed with the privileged rights of that

service.




Again, C: is a protected area. Can't write there without already elevated rights...so yeah...







Get Outlook for iOS








show

a-ko posted this 27 April 2017















The best part about all of these tools is they usually REQUIRE NTLM. Talk about irony.




But it's TOTALLY secure, right?! It's a security tool! It definitely doesn't have vulnerabilities that allow the vendor to use your product for demos without your knowledge! (Google Tanium and sort by date)




Get Outlook for iOS








show

Close