Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: Tracking Privileged Accounts in Windows Environments - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Tracking Privileged Accounts in Windows Environments

While speaking with a customer, he complained about the huge number of privileged users having domain admin rights in his network. It seems to be a recurrent problem for him: The security team reviews all the users at a time t and it reduces the number of privileged accounts to the strict minimum. But quickly, the number of administrators is growing again and, at time t+x, they have to restart the cleaning process. Amongst the SANS 20 Critical Security Controls, the point #12 focuses on controlling administrative privileges. The following controls are already in place by the customer:

  • Auditing privileged accounts usage
  • Auditing privileged accounts changes (creation, removal)
  • Strong password policy

Unfortunately, the control #7 (CSC 12-7) remains a pain: the utilization of privileged accounts for non-administration tasks like reading e-mails or surfing the web. As most of the controls remains technical, a suggestion was to add a extra layer of awareness for administrators to remind them that using privileged accounts can be dangerous. Instead of simply displaying a warning message, the idea was to force the administrator to describe (log) in a few words why he started an administrator session. The information is logged and can be used later to generate activity reports from their SIEM like this example:

Timestamp Host User Reasons of the session
2015-09-12 17:23:00 ServerA a-user1 Installed patch MS-15-xxx
2015-09-14 09:43:12 DC1 administrator Installed agent from xxxx
2015-09-15 12:16:34 SQL-2 a-user2 Emergency reboot

Not valid, funny or empty reasons can we investigated case by case improving the control of privileged users.

There are commercial solutions which implement this like Cyber-Ark or Digital Guardian. I wrote a PowerShell script which can be deployed as a logon script. Details are available on my blog.


Xavier Mertens
ISC Handler - Freelance Security Consultant
rootshell.be
truesec.be

Xme

458 Posts
ISC Handler
This person could push GPO that disallow iexplorer process for administrators. This is what my organization does and it is fairly effective
kyle

5 Posts
Very effective and radical indeed. But the browser is also often the new (and only available) management tool!
Xme

458 Posts
ISC Handler
@Kyle: Do you mind sharing the GPO for restriction of running iexplorer.exe by admins?
AAInfoSec

48 Posts
I thought it was GPO, but it is apparently our HBSS host security we have that prevents admins from executing process.
kyle

5 Posts
You could set a Powershell script to start at boot that sleeps for a few seconds, then kills any process iexplore if it's owned by an admin user.
Mjnbrn

1 Posts
A script running on login doesnt help when you log in using a non-admin account and then 'run-as' the privileged account to elevate your privileges.
Anonymous
It's easier than that. Require that all admins have two accounts, one that they use for regular activities and another with admin rights. Use an authenticating proxy and block all Internet access for any account in an administrator group. Also do not allow the admin accounts to have email access.

GPOs are under the control of the same people you're trying to control. That never works, even if GPOs always worked, which they don't.
Anonymous
I agree with the two account approach. That is exactly what I do. Practice what you preach.

Audit admin account usage through logs. Report apparent policy violations to managers and/or HR. Repercussions are a must for use of admin credentials outside of policy allowances. Repeat offenders lose admin privileges permanently. If they require admin privileges to do their job but continue to violate policy on their use, they have to find a new job.
G.Scott H.

48 Posts
Even basic log monitoring systems can alert on group membership changes. For the situation that author mentioned where people were getting added without management knowledge, that would fix that problem immediately.

For companies that have gone to delegated administration, be certain that you monitor the membership of all of those groups as well. It's very easy for a domain admin to create a new group with ai innocent-sounding name and give it almost every right that a domain admin has yet no one knows it exists so no one monitors it.

We monitor the membership changes of every AD group, some 2,500 of them. The only time we get "alert overload" is when someone decides to create a new group and put five hundred people into it. It's a very, very effective way to catch mistakes where people are getting added to the wrong groups or where you know they changed duties or even jobs but you did not see their accounts getting removed from groups.

Active Directory monitoring is grunt work and everyone wants to do the high-visibility work on firewalls and such. But excessive or improper permissions will kill you faster because it allows lateral movement without detection since everyone monitors for access failures and not access successes.
Anonymous
The GPO is pretty simple. You just need to use the Software Restriction feature.
Anonymous
You can't restrict a local administrator per GPO or SAFER: they can disable GPO processing or SAFER, can write to locations in %SystemRoot% or %ProgramFiles% where execution must be allowed, ...
Anonymous
Agree but, as I said, it's just an extra control. If an admin disable a GPO, kill a process or whatever, you won't have the extra event related to his sessionn -> This can be considered as an incident.
Xme

458 Posts
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!