Do you have local admin rights?

This discussion came up at work recently & the majority of the admins I work with do want to have local admin rights to their wkstns. However, majority of them do have elevated admin privileges when using their token. I really don't think it is necessary to have local admin rights on your workstation as it does create a weakness on your network with that system. So, if that system was to become compromised via malware, phishing, etc, then the attacker could pivot off your system to gain access to other systems.

What does your company do or enforce?

A local telemarketing company was forced to shutdown recently due to being hit with some ransomware encryption (I believe, not for certain) because maybe their backups were not working or didn't have a disaster recovery plan in place...maybe their admins had local admin rights on their boxes?? who knows, I just know it devastated a lot of employees (approx. 300) right before xmas. I don't know the specifics, but I wonder if their IT company just had their hands tied due to restricted IT budgets to have safeguards in place or if they just had an incompetent security posture in place. I believe they had their own IT staff but it could have been outsourced to a local MSP.

Find more posts tagged with

Security

Comments

tedjames

IT and security staff have local admin rights. General staff do not.

LonerVamp

I've always had local admin rights on my workstation, but I'm also typically the one who holds those keys in the first place.

Discussing this topic is nuanced and also includes other defenses in depth. In fact, I actually ask this question when I interview other security folk (I actually use "domain admin" in my question just to add another layer to it).

Sidenote: Don't confuse the conversation by also accidentally including "domain admin" rights and conflating that with local admin rights. You can have local admin rights and not be a domain admin. Domain admins should NOT be allowed to log into their normal local workstation interactively nor should those identities be allowed to browse or do untrusted things on systems (check email, open files, browse the web, download exe's from the internet...) Anyone with DA access should have a non-privileged account they normally operate as, just like any other user on the network.

This is best taken by layers and it entirely depends on the maturity of the IT department of the organization, the security interest/maturity of the org, and the budget to manage workstations "properly." For instance, small shops may run with local admins, just because locking that down and supporting those users with subsequent IT needs costs more.

As maturity and size moves up and your IT team can support workstations through centralized deployment means, then it becomes useful to take local admin rights away from groups of lesser-technical users, often who all have the same software needs to do their jobs. It expands from there to start including others who don't have interesting needs.

Some of the last groups are often your most technical ones...research, sysadmins, developers, security, workstation admins. It takes quite a lot of maturity and advanced practices to lock those systems down properly. Sometimes this is gotten around (arguably!) by having separate systems to do management tasks, or local VMs or something. All of this is work and complexity if you find it worthwhile.

So, while you might have something in between with some users running with local admins, then yes, you have higher risk on those systems. I mean, even barring random web browsing and installing bad software, a malicious insider could start poking at local hashes and logging to try to escalate to higher privileges on the network/domain.

For me, I've always had needs that require very regular local admin access over the years, from my years doing workstation support, to systems administration, to security. It honestly just makes me and my team(s) more efficient. But yes, that increases the risk. This is partially why I do extra things like run NoScript in Firefox and live a life of browsing a neutered web...

RE Ransomware: Ransomware may also move laterally due to lack of patching systems internally or from pilfered hashes from a system where those hashes are accepted by other systems (shared local admin or domain user who has local admin everywhere).

wd40

We had local Admin rights I think 5 years ago, then it was decided that all local Admin accounts will be disabled and to get a temporary admin access you need to follow a certain process.

We hated it back then, but now I understand why this is necessary.

Listen to podcasts below .. you might change your mind about having local admin accounts.

Shadow Brokers

https://darknetdiaries.com/episode/53/

NotPetya

https://darknetdiaries.com/episode/54/

JDMurray

In places that I control, nobody has local admin rights by default on any OS on any device. If you need root/admin access to perform some privileged operation you must (temporarily) elevate to it using logged and non-anonymous authentication. I would hope that the security design of embedded systems (IoT) also adheres to the "lowest necessary privilege level" rule but probably most do not.

yoba222

Can't remember off the top of my head but I believe this is a control item in the CIS benchmark for Windows hardenings -- to not allow local admins.

tedjames

In the early '90s, I worked for an unnamed software company that gave EVERYBODY superuser rights on a UNIX system. That was a recipe for disaster, though it's amazing that I never heard of anything blowing up there. I think that most people were afraid to try to do more than their job.

TechGromit

I have Admin rights to install software, but do not have the authority to disable or uninstall antivirus software as well as other monitoring tools. If I want to use USB media, I have to log into the computer with a different account, which does not have share drive or email access. When first preparing a new computer, local admin is used, but once it authenticates to the domain, the local admin account and password are changed so local IT does not know what it is.

TechGromit

shochan said:
I don't know the specifics, but I wonder if their IT company just had their hands tied due to restricted IT budgets to have safeguards in place or if they just had an incompetent security posture in place. I believe they had their own IT staff but it could have been outsourced to a local MSP.

In my opinion there's really no excuse not to have a monthly offline backup of your network. When i worked at a casino, monthly tape backups went off site, and we had backups going back years. I can see losing weeks of data due to a ransomware attack, where your offline backup are compromised or deleted, but you should have tape backups going back far enough to recover at some point. A tape dive backup solution is fairly cheap.

shochan

TechGromit said:

shochan said:
I don't know the specifics, but I wonder if their IT company just had their hands tied due to restricted IT budgets to have safeguards in place or if they just had an incompetent security posture in place. I believe they had their own IT staff but it could have been outsourced to a local MSP.
In my opinion there's really no excuse not to have a monthly offline backup of your network. When i worked at a casino, monthly tape backups went off site, and we had backups going back years. I can see losing weeks of data due to a ransomware attack, where your offline backup are compromised or deleted, but you should have tape backups going back far enough to recover at some point. A tape dive backup solution is fairly cheap.

The article actually made it to Slashdot about a month ago, I just cannot find it at the moment...From what I read, they were compromised like in Sept or Oct 2019 & tried like hell to get backups restored, but never could. Thus why they had to cease operations as I do not think they could function anymore. I don't recall if they tried to buy the encryption keys or not.

DZA_

Generally here, local administrative rights are disabled unless there is an exception to be made to execute the tasks. This is followed by requesting temporary access to the local admin account (logged) also it's password is changed every couple of hours.

One interesting product that we're testing out here is Beyondtrust's product at our org: https://www.beyondtrust.com/endpoint-privilege-management I'm not sure if anyone here else has this product running in their environment but it's mainly for the developer use case.

LonerVamp

I applaud all the places that run without local admin rights. As someone who's been around a long time, I totally get the risks and the situation that arises when one has to support that environment. I just don't look forward to that.

(I'd have more opinion if I ran the department that handles workstations/endpoints, as really they shoulder the burden of that posture decision.)

LonerVamp

yoba222 said:

Can't remember off the top of my head but I believe this is a control item in the CIS benchmark for Windows hardenings -- to not allow local admins.

Without looking back at it, I believe the benchmark just calls out that you need to be aware of (known list) and limit your local administrators as much as possible.

Other overarching principles such as least privilege should drive it more.

averageguy72

We had deployed managed state across our whole organization about a year before being acquired. Now we're part of a very large company and everybody has local admin, nutty.

TechGromit

averageguy72 said:

We had deployed managed state across our whole organization about a year before being acquired. Now we're part of a very large company and everybody has local admin, nutty.

Things run more efficiently when everyone has Enterprise Admin rights. What could go wrong?

cyberguypr

TechGromit said:

averageguy72 said:

We had deployed managed state across our whole organization about a year before being acquired. Now we're part of a very large company and everybody has local admin, nutty.

Things run more efficiently when everyone has Enterprise Admin rights. What could go wrong?

Wow, had a flashback to my colleague in 2001 who used to do this to solve issues as "recommended by the vendor". True story.

DatabaseHead

Those days are long gone from my perspective. Worked a few short term contracts recently and held some perm roles and none of them allowed it.....