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
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.
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.”
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).
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.
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
option is to treat the scanner like any other management
tool, and put it inside the “red forest” with JIT
another option is an account that is enabled or disabled
based on limited time periods.
yet another option is an account that rotates is password
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!”
you can imagine, I’m VERY EXTREMELY BITTER on this front. We
have ended up having to give DA privileges)
Operator might also work…
On Behalf Of Brian Arkills
Sent: Wednesday, April 26, 2017 4:20 PM
To: Britt, Brian
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
😊 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.