Windows Token Misuse

Viewing 2 reply threads
  • Author
    • #7738

      Hi All,

      just a quick question, I’ve recently found quite bad overuse of domain admin priv’s accross our network by admins. I’ve performed a POC by using Incognito and successfully added a new account from a standard account into the domain admins via tokens.

      I’ve read the paper for this, as included in unleashedbt type materials. So I will be trying to implement better policy to control overuse and highlight the dangers to why Domain admins needs reducing.

      I’m currently going through a best practise windows 7 hardening document and it mentions using User Account Control (UAC)

      would this be a mitigation or risk reduction in an attack like incognito? My feelings are it could help remove the dash attitude of just logging in as admin and therefore reducing the amount of tokens hanging around.

      Granted the real problem is a culture shift and AD structure least priv permissions themes, but its still useful.

      Any opinions or experiences welcome…


    • #48316

      Currently in the same boat.  First limit the users who can be domain/enterprise admin.  There should never be too many people with this access.  It is not always needed for regular day-to-day activity.  Next make them have pretty strong passwords or utilize 2-factor authentication.  Log the use of those accounts once they are limited and if you see an over-abundance of log on events, then do some root cause, if it comes up the user is just lazy, well revoke the privs.  One less admin to worry about.

      As for the day-to-day AD work, well that can be delegated, again use unique IDs for this.  No one should be using their standard network account to perform the work.  A good way to force them to do this is by making sure their admin account only has access to the services required and can only log on to the servers that host those services.   

      For example, the Exchange admin account only needs access to the Exchange box and AD, it should not be allowed to log on interactively to say the database server.

      So if you can limit down to unique IDs for things, you can log and alert more accurately, then reduce more if you need to.  There should also be no generic ID used by multiple people.  If an a restriction in an application requires such a thing, make sure it is well documented.

    • #48317

      Agree, I really want to get some accountability over these accounts and provide some ability of containment if the worst happens. At the moment its the old god complex going on and convinience rules over security, using things like password vaults which removes all accountability with RDP utils which store credentials to hop around boxes that seems to further flatten the need for priv escalation to that of a normal account.

      I’m currently looking at the newer audit policies in 2008 as we run a windows 7 only shop (one good thing no legacy about) although expensive firewalls running as pure stateful packet filters was a bit of a laugh.

      thanks for your input…

Viewing 2 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2020 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?