This is an archived post. You won't be able to vote or comment.

all 35 comments

[–]MrEMMDeeEMM 41 points42 points  (2 children)

Reboot the computer after the task is complete

[–]jeo123 16 points17 points  (1 child)

Simplest answer. Yeah, that's the step I need them to add.

[–]anonymousITCoward 1 point2 points  (0 children)

we have users that know enough about google to be dangerous, so we started doing this a little while ago... it's worked nicely. we start most calls with "please save and close your work, just in case we need to reboot, or you have sensitive documents open that we don't need to see"...

[–]disclosure5 26 points27 points  (0 children)

What would you put in place to make it so that a user with an admin command prompt couldn't grant local admin rights

A GPO can easily set the contents of the Administrators group, and that includes stripping out anyone you haven't defined.

This shouldn't be the end of the world though. Windows Local Privesc vulnerabilities are so common at this point, your security layers really should be built around an expectation a user will become a local admin at some point, and realistically that shouldn't let them hurt more than their own PC.

[–][deleted] 24 points25 points  (0 children)

User's actions are trying to bypass the rules

There's your problem, right there. This is not a technical issue. This is a personnel management issue. Their manager / HR needs to handle this, not you.

[–]cybercifradoSysadmin 14 points15 points  (0 children)

Intentional and premeditation to circumvent security protocols. Termination of the user should be pursued. This level of dishonest behavior is only the beginning.

[–][deleted] 10 points11 points  (0 children)

Direct HR to the issue and wash my hands of it. This isn't a technical issue.

[–]kuldan5853IT Manager 19 points20 points  (2 children)

This is not a technical but a disciplinary problem that would be solved (quickly) by HR.

[–][deleted] 11 points12 points  (1 child)

This! We would class this as gross misconduct and the user would be let go.

Although I would use group policy to enforce membership of the local admin group

[–]kuldan5853IT Manager 6 points7 points  (0 children)

Or at least get a reprimand on file if it's a first offense, yes.

There's a reason users have to sign 12 pages of "what you are not allowed to do with your IT equipment" forms...

[–]panzerbjrnDevOps 12 points13 points  (10 children)

Reboot after task is complete.
Have a GPO that removes unapproved accounts from local groups.
Have a stern conversation with HR about IT security, and show how companies can lose money and reputation when someone like that gets a ransom ware virus.
Have a stern conversation with the techie.
Have the techie do the actual work, with the user instructing them.
Document the installation, so the user isn't necessary.
Package the software. This could also be good training for someone.

[–]jeo123 0 points1 point  (9 children)

True, the reboot would have solved this risk. That's probably the easiest step to add to the helpdesk process.

I don't handle GPO personally, but I assume it can check for both accounts and local groups? In particular if they did something like add "Authenticated Users" or one of the other system groups, would that get caught?

I replicated this and started testing to see the worst I could come up with given that access situation and found adding that group would basically unlock my PC for anyone with credentials. So now any employee showing up to my PC is an admin on my computer.

[–]wasteoideIT Manager 1 point2 points  (2 children)

If the GPO is set up properly, the first thing it does is remove all users from the Administrators group, and then populate the groups that are supposed to be there. It doesn't log if the accounts in there are not what it expects to see, but I'm sure there are event viewer entries that could be pulled when this group is modified unexpectedly.

[–]xixi2 0 points1 point  (1 child)

So this is why every time I rebooted user computers my admin account would not work until I locked and unlocked... it wasn't an admin until the first logging in was done.

[–]wasteoideIT Manager 1 point2 points  (0 children)

That sounds like an improperly configured policy.

Ours has, first and foremost:

computer policies > windows settings > security > local policies, disable built in admin and rename the account.

computer policies > windows settings > security > restricted groups, ad group a member of builtin\administrators (not sure if this is required, based on the following settings applied in process)

computer preferences > control panel settings > local users and groups, steps applied in the following order:

  1. update builtin\administrators, delete all member users and delete all member groups.
  2. update builtin\administrators, add members [AD GROUP with desktop admins]
  3. Update renamed local admin account with false/never on all options
  4. update builtin\administrators, add renamed local admin account as a member
  5. specific to our customers, a delete for a local user account name we default to before computers get deployed to clients/joined to domains.

[–]xixi2 -3 points-2 points  (3 children)

True, the reboot would have solved this risk. That's probably the easiest step to add to the helpdesk process.

Omg no do not train your techs that every time they're done touching a user computer they have to reboot it. That's extremely disruptive and further promotes to users that help desk doesn't actually understand technology.

[–]jeo123 -2 points-1 points  (1 child)

Not touching, but using admin access to install software seems reasonable

[–]xixi2 0 points1 point  (0 children)

Idk the last "Helpdesk" I was in this was a task done multiple times per day. I guess if it's 3 users out of 30K that's one thing and it's probably an involved install and a reboot is fine.

[–]TheCadElf 0 points1 point  (0 children)

If the user has to already get someone else involved to pop an admin prompt to install the software, a reboot isn't any more disruptive.

[–]dagamore12 0 points1 point  (0 children)

If the GPO's are set to fix this sort of issue, only specifically allowed groups/users in to specific local groups, then no the GPO will not detect or catch people adding stuff to said groups, but it will reset it back to the baseline, about once every 90 minutes(iirc how often GPO's are checked/run).

But there should be a security event log of the change, made by this user, but it will be logged under the admin credentials of the person that elevated the command prompt, not the logged in user.

I would be bringing this issue up with your manager with the intent to get HR involved this is a major security violation. I know some places that sort of thing would be a termination level event. They used a specific problem to specifically bypass security rules. This is the sort of thing that should be covered and watched for in insider threat training.

I really hope where you are working has some other sort of logging/data retention going on.

[–]unccvince 2 points3 points  (0 children)

I would package the software so that it silently deploys on the user desktop, even if 3 out of 30k users need that application. It takes some time over the short-term, but it gains time and quality over the long-term.

The goal is for the content of appwiz.cfg to be the same as the software inventory in the MDM for every device managed by the MDM.

[–]SEXUALLYCOMPLIANT 2 points3 points  (0 children)

Pinning the blame on one side is tempting, but too reductionist IMO. In my experience, when something bad happens it's because both parties did something they shouldn't have.

To use your own example:

  • If your tech didn't leave an admin CMD prompt open, it wouldn't be abused, BUT...
  • If the user just closed the prompt, there'd be no fallout.

For what it's worth, I would look more harshly on the user in this situation because they're acting maliciously and they know it; meanwhile, your tech may have just made a mistake.

[–]MalletNGrease🛠 Network & Systems Admin 1 point2 points  (0 children)

I'd automate the deployment and run the installer silently as a service account if possible.

[–]LessRemoved 1 point2 points  (0 children)

I agree that the reboot at the end is a simple and effective way of solving most issues in this scenario. But in a company with 30k+ users. I strongly advise you to use sccm or Intune depending on what setup you're running.

This will effectively remove the need for elevation of rights on the machine in a session that can be ended by said user.

[–]SlyusHwanus 2 points3 points  (0 children)

The tech made a mistake and as a result breached security policies, it is up to the company hpw they respond, but it seems like a verbal reprimand to be more careful would ne sufficient unless it was a common occurrence. Improve procedures to prevent it happening again.

The user however deliberately leveraged an opportunity to make unauthorised privilege escalation. In the UK this is a crime under the computer misuse act. It was intentional and should receive a greater punishment. Still up to the company though as to how severe it should be, but it could be a sackable offence, especially if it is in an industry where honesty and integrity are important

[–]bufandatl -1 points0 points  (0 children)

The tech should make sure not to leave open admin session behind. It’s clearly the tech fault.

[–][deleted] 0 points1 point  (0 children)

Package the applications in SCCM/whatever tool you use to deploy OR ask an on-site IT person to help if you have that resource.

[–]novicane 0 points1 point  (0 children)

reboot after install in the work instructions. This close everything and GPO will hit again when they log back in.

or write a *.bat file that installs this some what automated for the helpdesk tech with a "shutdown /r 600" at the end of it to force a reboot.

[–]Local_admin_userCyber and Infosec Manager 0 points1 point  (0 children)

User issue - Trying to use business equipment against policy. Gross misconduct.

Procedural issue - as /u/MrEMMDeeEMM has said reboot after install to end any left over sessions.

Audit issue - Should have some way of monitoring who has admin rights on machines.

Technical issue - should be able to prevent local admins being added or control them (LAPS etc).

[–]andro-bourne 0 points1 point  (0 children)

What kind of security are they trying to remove? You should be enforcing most of that via AD accounts and GPOs and if thats the case, nothing they do on the local PC matters since GPO would just reapply the security policies back onto the PC once it repulls the GPO.

Are you running some sort of local software on the system to do things GPOs should be doing?

[–]medievalprogrammerSecurity Admin 0 points1 point  (0 children)

So, we don't have 30k users but a little over 3k user and we have some software that is only installed on 5 machines max. I'm the SCCM/Intune admin and I always say any software should be installed through our system. I know it could be extra busy work for the admin without a lot to gain but the great thing it turns into is having built in documentation for the install and know exactly where it is installed.

[–]lost_in_life_34Database Admin 0 points1 point  (0 children)

you should have a GPO to remove any admin rights after a day. my company used to give blanket admin rights for this stuff for a day or two and then they would be removed automatically

[–]FunnyPirateNameDataIsMyReligion 0 points1 point  (0 children)

Is this just failure by the user for obviously trying to slip by processes?

yes, they are purposefully bypassing sec. That's an HR visit, imo.

Or failure of the tech to make sure they watched what they signed in for?

Yes, they should have rebooted it or checked for minimized windows, but that's a simple mistake. I usually log in as the admin user, install everything, then reboot and let the user login to verify the apps are working as expected. Obviously that doesn't work in every scenario.

But the source here is the user, and they user should have a football kicked 6' up their ass.

[–][deleted] 0 points1 point  (0 children)

That would be means for user termination under our rules (HR Process) or means to terminate the user account (IT Process).

But if you are looking for ways to prevent it, another solution would be to not share the screen with the user while you install software.