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
Reverse-Engineering Malware: Malware Analysis Tools and Techniques | Frankfurt | Dec 9th - Dec 14th 2024 |
Comments
Anonymous
Sep 24th 2015
9 years ago
Anonymous
Sep 24th 2015
9 years ago
Anonymous
Sep 24th 2015
9 years ago
Anonymous
Sep 24th 2015
9 years ago
Anonymous
Sep 24th 2015
9 years ago
Anonymous
Sep 25th 2015
9 years ago
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
Sep 25th 2015
9 years ago
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.
Anonymous
Sep 25th 2015
9 years ago
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
Sep 25th 2015
9 years ago
Anonymous
Sep 25th 2015
9 years ago