Stop users from adding local admins

[n_K]

Security implementations are in many places - awful.

The random thing is good practise, heck you can do it easier - set all PC passwords the same then change them remotely using a script which saves the passwords (unique for each machine) to an encrypted USB and once done - remove the USB!

Also I like that you're trying to check out about the security but remember, the kid might be breaking the law but unless you've got it written into the agreement that the kid has with you and local laws allow, it's illegal for you to keylog him.

Oh and just a reminder for ANYONE involved in ANYTHING like this - decrypting or attempting to decrypt SSL data or capture data sent over SSL [including keystrokes] is illegal in the UK and EU, not sure about america - and you will get in serious trouble if you attempt to use that as evidence as anything because the data could be confidential such as the user's credit card details.

[sc302 Veteran]

What is in the UK is not in the US, when it comes to this topic at least.

[bowl443]

Friday afternoon was spent changing the local admin passwords on the labs that the students have access to. We also set the HDD as the only boot device and locked down the bios with a stong password. This can be reset very easily with the jumpers on the motherboard, so now we are looking at locks for the cases.

Luckily with the security that was already in place(I've been at this job since Thanksgiving), the user's 'hack' was isolated to the local machine. Sure, he knows a local admin password, but we caught him in another lab trying a series of passwords and none worked since each lab has a different local admin password. So that policy was effective as well.

Thanks for all the input.

[bowl443]

We interviewed the kid this morning and now we know how he did it.

This is a big problem... short of disabling sticky keys with a registry entry, there is no way to stop this.

Thoughts?

[sc302 Veteran]

where do they save their documents?

smartshield http://www.centurion...martshield.aspx

have fun with breaking things...reboot they revert back, the downside..don't save anything to the c drive or do installs/updates with the it enabled. You can set specific times for auto updates to execute so that it unlocks.

[+BudMan MVC]

So why would his account have access to windows system32? Are you saying he booted the recovery tools that are installed on the disk or did he just have access to the folder in the first place?

A known way to access the windows system32 folder is via startup recover and then using the notepad file browser, etc..

Can you just disable those from booting with something like

bcdedit /set {default} recoveryenabled No

bcdedit /set {default} bootstatuspolicy ignoreallfailures

I thought there was a way to remove them completely or not install them in the first place. Its been awhile since I had to play with this sort of stuff.

Normal account should not be able to access the windows/system32 dir, and if you prevent boot from media remove the option to get to the recovery tools that might be installed on the disk you should be able to still allow for sticky keys ;) While preventing this sort of attack.

edit: So curious is this a OEM sort of installation, custom image your dept deploys? is there a recover folder with a winre.wim file? Having the recovery tools on the HDD that anyone with local access could boot is going to allow for all sorts of nasty things to be able to be done. I would completely remove those features. Admins should have to either reimage the machine or boot their tools after knowing the bios password so they can alter the boot menu, etc. Yeah it can be pain -- but if you want to prevent this sort of thing, then some pain has to be felt ;)

[ITFiend]

  On 25/01/2013 at 14:47, eXtermia said:

However if you enforece bitlocker with the key being backed (with hardware TPM) up to AD and only recoverable from AD admins there is no way they can use any off the street tool to add thierselves as Admin.

This is only true if it?s TPM 2.0. TPM 1.2 key security is defeated, as it has had known vulnerabilities for years that allow attackers to extract stored encryption keys. Also, motherboards that have the TPM as a removable card suffer from Man in the Middle attacks that allow you to observe the key in transit when released to the system assuming measured boot thinks no changes have occurred. TPM 1.2 keys are only secure when used in conjunction with +PIN, +USB, or +Network Unlock.

The primary reason to use TPM 1.2 without two-factor authentication is for a measured boot.

As of yet I haven't encountered any devices containing a TPM 2.0.

[Arachno 1D]

See the response in this article and see if it helps

1. Consider a BIOS boot password

2. Consider an FDE PIN based system

3. Consider 2FA for interactive logon

4. With Windows consider domain auth (no cached credentials) for interactive logons

5. With Windows consider do not store LANMAN Hash

6. With Windows consider protect the SAM DB using SYSKEY

7. Consider Require Smartcard for interactive logon.

8. Or a combination of the above.

http://www.infosecisland.com/blogview/15031-How-to-Log-In-to-Windows-Without-the-Password.html

[bowl443]

BM - he used the driver signing option at boot and broke Windows so that it would launch its own repair, from there he used notepad to open a file browser. His student account did not have access to the system32 directory.

Yes, the techs image the labs and do mass rollouts of the computers. And yes, you're right- more security = more pain. But it's for the chillren, right? I'll start looking at ways to disable the recovery feature. Thanks for pointing me in that direction.

[#Michael]

I have been reading this topic with a lot of interest...you have to give the kid some credit for his ingenuity. But I have a couple of observations:

1. Since he reset the password for the local admin and not for domain (which is a big headache I admit)...how much trouble can he cause. Since it is local he cannot access domain shares, accounts, etc...

2. I love budman's last post to edit the boot process and prevent access the recovery console. Between that and disabling boot options within the bios you should be able to prevent this in the future.

[Arachno 1D]

Remove notepad!

[Arachno 1D]

Sorry posted in error