There is also "Administrator Protection".
Software Review The biggest risk with Windows: LOLBINS
- Thread starter monkeylove
- Start date
Video Reviews - Security and Privacy
226 Replies
16,063 Views
Reviews reflect the reviewer's setup and methods. Check the evidence and limitations.
Thread details
I had to look it up
This feature enhances security by enforcing just-in-time elevation, using a hidden, isolated system account (SMAA) to prevent malware from exploiting persistent admin rights. It replaces the older UAC model with a more secure, least-privilege approach.
You can lock down a system with SUA. But beware of attacks targeting services. Services run with high privileges, and some are toned down. But if an attack on a service succeeds, it can give you a hell of a mess. Don't give me the excuse that it doesn't happen nowadays. I disable services I don't need. I do it my way, you go try your luck. And I can't prove it because I don't have a black belt in forensics,
Last edited:
I do it both for security and for performance.
More effective lock down than WDAC?
RoboMan
Level 39
Verified
Honorary Member
Top Poster
Content Creator
Well-known
High Reputation
Forum Veteran
The fact that installing a random software usually requires administrator privileges is the greatest Windows design security flaw.
UAC was supposed to protect the system. Instead, Windows conditioned users to blindly approve elevation just to do normal tasks.
That’s not a user failure, that’s a design failure. A security system that depends on users not being annoyed is already broken.
UAC was supposed to protect the system. Instead, Windows conditioned users to blindly approve elevation just to do normal tasks.
That’s not a user failure, that’s a design failure. A security system that depends on users not being annoyed is already broken.
Well you can ban a exe or dll via WDAC. But some you cannot ban. Then you try to limit the damage and standard users is one way.
Just did my learning for the day in 5 secs by asking ChatGPT. Learned some basic forensics.
-----------------------------------------------------------------------------------------------------------------------------
how would I prove it that a service has been whacked ?
To “prove a service has been whacked,” you want evidence that (a) its config changed, (b) its on-disk image changed, or (c) it’s being hijacked at runtime—and you want that evidence in places Windows can’t hand-wave away (Event Logs, registry, signed binaries, hashes).
Here’s a practical checklist that produces “showable” proof.
Look for these kinds of entries around the time you suspect it happened:
Event Viewer → Windows Logs → Security
HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>
Key values to inspect:
-----------------------------------------------------------------------------------------------------------------------------
how would I prove it that a service has been whacked ?
To “prove a service has been whacked,” you want evidence that (a) its config changed, (b) its on-disk image changed, or (c) it’s being hijacked at runtime—and you want that evidence in places Windows can’t hand-wave away (Event Logs, registry, signed binaries, hashes).
Here’s a practical checklist that produces “showable” proof.
1) Prove the Service Control Manager saw a change
Event Viewer (best first stop)
Event Viewer → Windows Logs → System → (Filter Current Log…) → Event sources: Service Control ManagerLook for these kinds of entries around the time you suspect it happened:
- 7040 = startup type changed (Manual/Disabled/Automatic)
- 7045 = a new service was installed
- 7036 = service entered a new state (stopped/started)
- 7034 / 7023 / 7024 / 7000 / 7011 = unexpected termination / failure details
Event Viewer → Windows Logs → Security
- 4697 = service installed
2) Prove the service configuration was altered (registry)
Services live here:HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>
Key values to inspect:
- ImagePath (points to the EXE or to svchost.exe -k <group>
- Start (2=Auto, 3=Manual, 4=Disabled)
- ObjectName (account it runs as)
- If it’s svchost-hosted: Parameters\ServiceDll (this is a big one for hijacks)
3) Prove the binary (or ServiceDll) is not what it should be
From Services (services.msc):- Open the service → note Path to executable (or confirm it’s svchost-hosted)
- File Explorer → right-click the EXE/DLL → Properties
- Digital Signatures tab (is it present? valid? expected signer?)
- Details tab (company name/product)
- Check the path: anything running a “system” service out of C:\Users\…, C:\ProgramData\…, Temp, etc. is an immediate red flag.
4) Prove it with hashes (strongest “courtroom style” artifact)
If you’re okay with a single command, this is the cleanest proof:- certutil -hashfile "C:\path\to\binary.exe" SHA256
- a known-good machine
- the same file from installation media
- a trusted vendor hash (if they publish one)
5) Prove runtime hijack (service points to legit file, but runs something else)
If it’s svchost-hosted
- Task Manager → Details tab → find svchost.exe → right-click → Go to services
- Confirm the PID hosting your service
- Use Process Explorer (Sysinternals) on that PID:
- verify the svchost image is signed by Microsoft
- inspect loaded modules: any unsigned or weird-path DLL loaded into that svchost is highly suspicious
6) Prove “someone did it” (attribution to a process/account)
Windows often won’t log “who changed Start=4” unless auditing is on. But you can still build a strong story by correlating:- System log SCM event time (startup type changed / service stopped)
- Security log events near that time (logons, process creation if enabled)
- EDR/ESET telemetry (if you have it) for the same timestamp
- Scheduled task creation (Security 4698) or WMI subscription changes (if logged)
- Audit Other System Events
- Audit Security System Extension
- Audit Process Creation (gives you “what process did what,” if configured)
What “proof” looks like in practice (minimum bundle)
If you were writing this up for a report, I’d capture:- Exported System.evtx filtered to SCM events for the timeframe
- Exported registry key: …\Services\<name>
- Screenshot of service properties (startup type, logon, path)
- Signature status + SHA256 of the service EXE/DLL
- If svchost-hosted: PID mapping + loaded modules evidence
F
ForgottenSeer 123960
You argue that UAC fails because it "conditions" users to click "Yes." This is the classic "Seatbelt Defense", arguing that seatbelts are a design flaw because they wrinkle your shirt, so people don't wear them.
The entire purpose of UAC is to create friction. It forces a pause. It asks, "Did you initiate this?"
The binary choice, you have two options.
The Walled Garden (iOS/Android). You cannot install anything that hasn't been vetted by the vendor. Zero freedom, high security.
The Open Platform (Windows/Linux). You can install anything, but you must verify it yourself.
If a user blindly clicks "Yes" to install "Free_Screensaver.exe," that is not a design failure. That is a failure of Layer 8 (The Human). You cannot engineer a system that allows total freedom but prevents all stupidity.
You want the power of an open OS without the responsibility of a sysadmin.
I am not using either SUA or WDAC; both are good for kids younger to know how to avoid malware, in order to limit post-execution damage.
For experienced users, like you, they make very little difference.
UAC is good, but it can be bypassed, as MD can be, and any other 3rd party AV.
It just adds very little compared to other layers of protection.
F
ForgottenSeer 123960
This is not learning, this is regurgitation.Just did my learning for the day in 5 secs by asking ChatGPT. Learned some basic forensics.
-----------------------------------------------------------------------------------------------------------------------------
how would I prove it that a service has been whacked ?
To “prove a service has been whacked,” you want evidence that (a) its config changed, (b) its on-disk image changed, or (c) it’s being hijacked at runtime—and you want that evidence in places Windows can’t hand-wave away (Event Logs, registry, signed binaries, hashes).
Here’s a practical checklist that produces “showable” proof.
1) Prove the Service Control Manager saw a change
Event Viewer (best first stop)
Event Viewer → Windows Logs → System → (Filter Current Log…) → Event sources: Service Control Manager
Look for these kinds of entries around the time you suspect it happened:
If you have Security auditing enabled:
- 7040 = startup type changed (Manual/Disabled/Automatic)
- 7045 = a new service was installed
- 7036 = service entered a new state (stopped/started)
- 7034 / 7023 / 7024 / 7000 / 7011 = unexpected termination / failure details
Event Viewer → Windows Logs → Security
What you can show: exported .evtx + screenshots of the exact event details (time, account, service name, change).
- 4697 = service installed
2) Prove the service configuration was altered (registry)
Services live here:
HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>
Key values to inspect:
What you can show: an exported copy of that key (Regedit → right-click the service key → Export), and a “before vs after” diff if you have a baseline.
- ImagePath (points to the EXE or to svchost.exe -k <group>
- Start (2=Auto, 3=Manual, 4=Disabled)
- ObjectName (account it runs as)
- If it’s svchost-hosted: Parameters\ServiceDll (this is a big one for hijacks)
3) Prove the binary (or ServiceDll) is not what it should be
From Services (services.msc):
Then check the file itself:
- Open the service → note Path to executable (or confirm it’s svchost-hosted)
What you can show: file path + signature status + a hash (see #4).
- File Explorer → right-click the EXE/DLL → Properties
- Digital Signatures tab (is it present? valid? expected signer?)
- Details tab (company name/product)
- Check the path: anything running a “system” service out of C:\Users\…, C:\ProgramData\…, Temp, etc. is an immediate red flag.
4) Prove it with hashes (strongest “courtroom style” artifact)
If you’re okay with a single command, this is the cleanest proof:
Compare that SHA256 to:
- certutil -hashfile "C:\path\to\binary.exe" SHA256
What you can show: the SHA256 output + what you compared it to.
- a known-good machine
- the same file from installation media
- a trusted vendor hash (if they publish one)
5) Prove runtime hijack (service points to legit file, but runs something else)
If it’s svchost-hosted
What you can show: PID mapping + module list showing an unexpected DLL path/signer.
- Task Manager → Details tab → find svchost.exe → right-click → Go to services
- Confirm the PID hosting your service
- Use Process Explorer (Sysinternals) on that PID:
- verify the svchost image is signed by Microsoft
- inspect loaded modules: any unsigned or weird-path DLL loaded into that svchost is highly suspicious
6) Prove “someone did it” (attribution to a process/account)
Windows often won’t log “who changed Start=4” unless auditing is on. But you can still build a strong story by correlating:
If you want this to be easy next time: enable advanced auditing for:
- System log SCM event time (startup type changed / service stopped)
- Security log events near that time (logons, process creation if enabled)
- EDR/ESET telemetry (if you have it) for the same timestamp
- Scheduled task creation (Security 4698) or WMI subscription changes (if logged)
- Audit Other System Events
- Audit Security System Extension
- Audit Process Creation (gives you “what process did what,” if configured)
What “proof” looks like in practice (minimum bundle)
If you were writing this up for a report, I’d capture:
If you tell me which service (name as shown in Services.msc) and whether it’s svchost-hosted or has its own EXE path, I can give you the exact “look here / expect this” fields for that specific service.
- Exported System.evtx filtered to SCM events for the timeframe
- Exported registry key: …\Services\<name>
- Screenshot of service properties (startup type, logon, path)
- Signature status + SHA256 of the service EXE/DLL
- If svchost-hosted: PID mapping + loaded modules evidence
Pasting a correct technical list from an AI does not confer the experience required to interpret it. It is like reading a medical textbook entry on "How to treat a gunshot wound" while actively bleeding out.
Every step listed here, checking Event ID 7045, hashing binaries, auditing Registry keys, is what we do after the machine is already dead.
This checklist confirms exactly what I have been telling them. Recovery is expensive, prevention is cheap.
Scenario A (Standard User). The malware executes. It fails to write to HKLM. It fails to drop the DLL into System32. It fails to register the Service. Result, you delete the file. Zero forensics required.
Scenario B (Your "Admin" Method). The malware executes. It succeeds. Now you are spending your weekend running certutil hashes, parsing .evtx files, and praying you found all the persistence hooks.
Well, if your environment OK's it, you can have the users do a per-user installation. The app then goes into \user\xxx\AppData ... Some MS Store installs do it tthat way, like Firefox
Totally agree.
But I was talking about a service being whacked scenario. And i WILL learn those forensics steps (just so I progress to a yellow belt; and for the next time you ask me to produce a Mitre Attack T# ), I am copy pasting for readers benefit.
Last edited:
RoboMan
Level 39
Verified
Honorary Member
Top Poster
Content Creator
Well-known
High Reputation
Forum Veteran
I see your point, but the main issue relies: Windows has a poor security design.
UAC isn’t just “friction”, it’s a gateway to a flat trust model. Once elevated, a process doesn’t merely do the one thing the user intended, it inherits broad, ambient authority over:
-system-wide services
-shared registries
-COM objects
-named pipes
-IPC channels
-user and system processes
At that point, Windows isn’t asking “did you initiate this?”, it’s implicitly saying “everything this process touches is now trusted.”
That’s not human error; that’s overprivileged design.
I love the concept of a user account. I also agree with the safety protocols it provides.
At one time I went to all of the trouble to create one. Then when I went to install software or use the PC, that is when the troubles began.
It didn't matter if I installed in the admin account, or as admin in the standard account, or as standard user (not using right click as admin) the installations had problems.
Like what?
Well, the software's wouldn't start, didn't create and couldn't create working shortcuts, program wouldn't run in standard account ETC...
Finally, after a month of that nonsense. I said nty to the standard user account.
In theory I love the idea, for practical purposes, it's lip stick on a pig.
F
ForgottenSeer 116559
Security is always a matter of trade-offs. Microsoft is responsible for catering to a very large public. Straight from the legendary Microsoft engineer Jon DeVaan, "One important thing to know is that UAC is not a security boundary. UAC helps people be more secure, but it is not a cure all. UAC helps most by being the prompt before software is installed."
Sudo on Linux has more safeguards in place than UAC, for example, but it's not as user-friendly.
As of right now, the UACMe project provides 81 different methods/techniques for defeating UAC. SUA is inarguably more secure, but you can also make the case that the risks of using an admin account are justifiable in the right circumstances—in the hands of someone experienced with other effective layers of security.
Sudo on Linux has more safeguards in place than UAC, for example, but it's not as user-friendly.
As of right now, the UACMe project provides 81 different methods/techniques for defeating UAC. SUA is inarguably more secure, but you can also make the case that the risks of using an admin account are justifiable in the right circumstances—in the hands of someone experienced with other effective layers of security.
F
ForgottenSeer 123960
The issues you described, software not appearing, shortcuts missing, are not flaws in the security model. They are flaws in your installation methodology.
When you run an installer as Administrator, many legacy or poorly coded setup wizards default to installing for "Current User Only" (%AppData% or C:\Users\Admin).
You install it as Admin. The files go into the Admin's profile. Then you log in as Standard User.
The Standard User cannot see the Admin's desktop, cannot read the Admin's AppData, and therefore sees "broken" software.
Competent sysadmins select "Install for All Users" (writing to C:\Program Files and C:\Users\Public). If the installer doesn't offer that, it is garbage software, but you can still manually move the shortcuts to C:\ProgramData\Microsoft\Windows\Start Menu.
You mentioned the program wouldn't run. This is almost exclusively caused by developers who are stuck in 1998.
Proper software writes binaries to Program Files (Read-Only for Users) and configuration/save data to Documents or AppData (Writable for Users).
Bad software tries to save your settings directly into C:\Program Files. The OS blocks this because users should not be modifying application binaries.
You do not need to make the user an Admin to fix this. You simply find that specific folder, Right Click -> Properties -> Security, and grant "Modify" rights to the Users group for that one folder.
You have opened a tiny window in the house, rather than removing the front door entirely.
Calling the Standard User model "lipstick on a pig" is a confession of defeat.
Fortune 500 companies, military networks, and banks run millions of PCs on Standard User accounts. The software works because their IT staff knows how to configure Access Control Lists (ACLs).
The Diagnosis: The "trouble" you experienced was not the system failing, it was the system working exactly as designed, stopping a low-privileged user from accessing high-privilege data, and you lacking the knowledge to bridge the gap correctly.
F
ForgottenSeer 114717
It is just a generalized "demo" video. Leo chooses Microsoft Defender as it represents 70% or more market share.
One can achieve the same malicious activities with other popular AV and security software.
F
ForgottenSeer 114717
The "built-in Administrator account" - which is different than the Administrator account created for a user to log into, are not the same.
1. The first one can be disabled.
2. The second one exists only for the purposes of administering the system, software, and OS.
3. Users are supposed to know that they are supposed to use a Standard User Account (SUA) or "Guest" account 99.99% of the time.
F
ForgottenSeer 114717
Microsoft ships a lot of security features that can prevent what is shown in the video.
For Windows Home, there are native Microsoft Security options to mitigate abuse of LOLBins and a lot of other stuff that gets shipped with Windows.
The user is responsible for and expected to know it all and then implement it all with discipline.
F
ForgottenSeer 114717
Rootkits installed via an executable versus one installed by an exploit are two different things.However, you've forgotten one type of malware: Rootkits
This malware seeks to hijack administrator rights in order to prepare for subsequent attacks.
So yes, it can reduce the risk, but it's not a complete defense against everything.
Microsoft Security includes a swath of security capabilities to prevent rootkits.
It is the user's responsibility to know all of this and they are expected to implement the security required to block rootkits.
Recently browsing
Members who viewed this thread in the last 5 minutes
