Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.comp.os.windows-10 > #181620
| From | Paul <nospam@needed.invalid> |
|---|---|
| Newsgroups | alt.comp.os.windows-10 |
| Subject | Re: More on disabling unneeded services in Windows 10 |
| Date | 2025-01-20 21:24 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <vmn0gf$3k5l1$1@dont-email.me> (permalink) |
| References | <vmlk1t$35lk3$1@dont-email.me> <vmlokq$37d3t$1@dont-email.me> <vmm8c4$3clor$1@dont-email.me> <vmmi91$3frih$1@dont-email.me> |
On Mon, 1/20/2025 5:22 PM, Newyana2 wrote:
> On 1/20/2025 2:32 PM, Paul wrote:
>> On Mon, 1/20/2025 10:04 AM, Newyana2 wrote:
>>
>>>
>>> An interesting side note: Windows Update Blocker does a good
>>> job of stopping Windows Update, despite the built-in tricks to
>>> re-enable it. I'm not sure how it works, but I suspect it's changing
>>> permissions on the Registry keys, so that only Administrators
>>> can change them.
>>
>> The highest level of permission, is a Registry key owned by TrustedInstaller.
>>
>> That is the owner that malware uses, when it injects a key into
>> your Registry. That's how you know "kwality", is when a malware
>> does a thing, it must be double-plus-good way of doing it :-)
>>
>> Administrator or SYSTEM account ownership of keys, might be considered
>> a tiny bit weaker. The purpose of Administrator, is to "impersonate"
>> other accounts. administrator is not royalty, it's merely
>> "our man in Istanbul". A useful account to know.
>>
>> Now the bad news. Security has been improved on the OS.
>> Sysinternals "psexec" no longer works. Similarly, the two
>> utilities I have, one of which elevates a Command Prompt
>> window to the TrustedInstaller token, those no longer work
>> either. This means, if someone asks you to remove a malware
>> registry entry today, there's no way to do it! Unless you know
>> someone who has hacked a new version of such code. the simplest
>> explanation for this, is some privilege of the Administrator Group
>> has been modified, as it's not obvious that Windows Defender
>> is running interference on this issue. It's not a heuristic
>> gun battle. the machine is relatively quiet when these "features"
>> fail to work.
>>
>> The TrustedInstaller token is copied from msiexec or something.
>> To utilize the TrustedInstaller capability, you have to start
>> the installer service, and within five seconds or so, run the
>> utility that will copy the token. The utility can then
>> elevate a new process such as cmd.exe and it then runs with
>> the actual highest permissions on the machine. That, at least,
>> is how it used to work. I that cmd.exe, you could type "regedit"
>> and then reach in and remove a malware key protected by
>> TrustedInstaller. (These are decorative keys which no longer
>> do anything, but the presence of the key might set off AVG
>> and it raises a stink unless you remove the key. That is
>> a typical reason for removing a Malware key. There is no point
>> removing a Malware key if the malware is resident and in
>> control of the machine.)
>>
>> If they keep gunning down these utilities, if they keep
>> plugging osk.exe holes, then the OS really will be a
>> "secure piece of crap". Then the scenario will arise,
>> where you'll be locked out of the machine via a local
>> account problem, and there will be no recovery path for you.
>>
>> I helped someone in another group, recover their administrator
>> (they had a "problem" they had trouble explaining to me,
>> where suddenly they had no administrator account), and I
>> used one of those osk.exe methods to get them a cmd.exe
>> that was running as real administrator, and from there it
>> was possible to make a regular account belong to the
>> Administrator Group and that put them back in control of
>> their machine. Well, if I want to do that today, there may
>> be one remaining method, but I'm certainly not going to
>> tell you what that method is, even if I knew, in a public
>> space. That would be an email recipe only We cannot raise
>> the profile of these methods, or Microsoft will expunge them.
>>
>> You can still use Kali to crack a local account, as far as I know.
>> Or use one of the other recipes for flattening a password.
>> but if you've lost all your Administrator accounts, all the password
>> flattening in the world is not going to help you then. Only
>> if the Real Administrator was enabled, would you have
>> "something to crack" :-)
>>
>> The OS has changed significantly, in the last couple of years,
>> in terms of security posture. The casual insecurity is almost gone.
>> They've been cleaning up the driver exploits too. I was told
>> by Defender to remove Asus Ai Suite driver, which I did. As
>> no purpose is served in the OS, by leaving malware-exploitable
>> drivers in System32 area.
>>
>
> I'm having a hard time following this. Are you saying it's no
> longer possible to take ownership of a Registry key? I haven't
> encountered problems, with either keys or folders. But I don't
> do it a lot.
>
> My impression would be that if I took ownership of a key from
> TrustedInstaller then it might be possible to actually block Windows
> system processes from changing the value. Does that make sense?
> I don't know how to test it, but I'm guessing it's what WUB does.
If a key is owned by TrustedInstaller, you won't be owning it.
If you had the ability to elevate as TrustedInstaller, then some
sort of plan could be formed to become the owner (or more likely,
to delete it). There aren't normally keys that you need to access
that are protected by TrustedInstaller. The most likely situation
is a key installed by a malware, and the malware people know
how hard it is for mere users to undo such things. You would most
likely be trying to delete the key, and TrustedInstaller is the
only "owner".
It's possible a registry editor that does not respect permissions
could be used to edit a key.
I'm just annoyed I can't run a Command Prompt window while
holding the TrustedInstaller token, as that enabled a lot more
freedom to get things done. Sooner or later, someone will find
a new way to do that. It all depends on whether the Administrator
account has been gutted or not (had the Impersonate privilege removed).
No, it's not Impersonate, it's a problem with communicating with WMI
and getting the token.
OpenProcessToken: Access is denied
[Picture]
https://i.postimg.cc/1tr0T6MF/WMI-Run-As-Token-W10.gif
Paul
Back to alt.comp.os.windows-10 | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
More on disabling unneeded services in Windows 10 "John C." <r9jmg0@yahoo.com> - 2025-01-20 05:45 -0800
Re: More on disabling unneeded services in Windows 10 Newyana2 <newyana@invalid.nospam> - 2025-01-20 10:04 -0500
Re: More on disabling unneeded services in Windows 10 Paul <nospam@needed.invalid> - 2025-01-20 14:32 -0500
Re: More on disabling unneeded services in Windows 10 Newyana2 <newyana@invalid.nospam> - 2025-01-20 17:22 -0500
Re: More on disabling unneeded services in Windows 10 Paul <nospam@needed.invalid> - 2025-01-20 21:24 -0500
Re: More on disabling unneeded services in Windows 10 Newyana2 <newyana@invalid.nospam> - 2025-01-20 22:28 -0500
Re: More on disabling unneeded services in Windows 10 wasbit <wasbit@nowhere.com> - 2025-01-21 09:41 +0000
Re: More on disabling unneeded services in Windows 10 Newyana2 <newyana@invalid.nospam> - 2025-01-21 08:21 -0500
Re: More on disabling unneeded services in Windows 10 Marion <marion@facts.com> - 2025-01-20 16:35 +0000
csiph-web