36 replies to this topic

[+BudMan]

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

[Kaedrin]

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.

[arachnoid]

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.infosecis...e-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.

[arachnoid]

Remove notepad!

[arachnoid]

Sorry posted in error