A security vulnerability report came in that said that a local administrator can attack the system and sign in on the local system as a domain account without knowing the account’s password.
So far, no security boundary has been crossed. The attacker is a local administrator, and a local administrator already has full control over the local system.
While it’s true that the administrator has compromised a domain user account, this ability to act as the user does not extend outside the local computer. You have control over the domain user account on the local system, but other computer systems will recognize you for the fraud that you are.
In other words, the attacker has gained nothing. They started as a local administrator, which gives them full control over the local system. They then attacked a domain account, which gives them all the powers of that domain user on the local system. But this is a subset of the powers they had as an administrator! Nothing was gained.
This compromise of the domain account on the local system does not extend to other systems, so the attacker gained no privileges on other systems.
The finder even acknowledged in their report that the compromised account is not recognized by other computers on the network. I’m not quite sure what vulnerability they were reporting. I mean, maybe they’re just saying that they found something interesting, but “interesting” doesn’t mean that you have a security vulnerability. Really, all they did was find a way to do something the hard way. The easy way is to just use your existing administrator powers.
It's not clear to me from the writeup, although I presume the answer to be "No" - could they use this approach to sign in with a domain account that is a domain administrator? Because then it seems to me that they could rid themselves of any inconvenient group policies set by domain admins, which does seem like a vulnerability. But I'm not very clear on all this stuff so I welcome any correction.
I should...
If you’re a local admin you can already get change any inconvenient group policies and then afterwards change the sync time to ensure they’re not synced with the AD.
May I ask a question please. A process created by System user can`t get clipboard data which format CF_HDROP.
Isn't "identity theft" also a vulnerability? It allows the attacker to cover their tracks for example when doing things as the user is enough to cause trouble. Someone else gets the blame because of the vulnerability. Sure the admin can create an exe that is run by the user. But the exe has metadata that the admin created it. The exe might delete itself, but the audit trail might still be there (defender lets you...
Administrators have the power to tamper with anything in the system. After all, they are administrators. They can install a driver that falsifies the audit trail if they want. If you don’t trust a person not to do that, then don’t make them an administrator!
Installing such a driver should (I don’t know if it does) also leave an audit trail, raise an alert and get reverted. Everything an admin does, whether trusted or not should be auditable. You may trust the admin, but the users and customers not so much – they don’t even know the guy. Especially with high security projects (medical, gov…) auditing is a legal requirement and the possibility of going around it is a problem.
Easy to say, not so easy to do.
There are specialized systems with strict requirements like that. But for the most part, it's not usually built into a general-purpose operating system, because on a single user system, pervasive audit logging is (or could plausibly become) a privacy violation. Windows, like other systems, does not force you to use audit logging if you do not wish to do so.
In cases where auditing is useful, it is usually done at a much higher layer of...
That is true, but it open the door to installing something which then is able to do its thing once the user logs in and does have network access. Of course, the local machine is already compromised – but this makes finding the cause a lot harder. But an admin which isn’t truly an administrator would not be able to be an administrator.
If you are willing to wait until the user logs in, then you can accomplish this without a complex attack. Just drop a rogue program in the global Startup folder. The rest are just style points.