@Rasheed, to re-affirm what @guest stated earlier... I've seen for myself an unexpected UAC alert a few years ago on a family member's computer. It appeared highly suspicious so it was not allowed to elevate. No damage was incurred as a result.
Exactly, but in order for such an event to ever occur, the system must be poorly secured. Chances of me seeing an unexpected UAC alert is slim to none. And again, Average Joe who is trained in clicking on "yes" would probably not even care about such an alert. So it would be insane for me, to torture myself with UAC alerts everytime I want to install some app, you even get to see them when you install apps via Sandboxie LOL.
no, you are assuming i think that; i don't need to know the reason why, i just need to know UAC does what it is supposed to do. when unwanted, Average Joe with a bit of brain will deny, idiot happy clickers will allow. When AJ see a board saying "dangerous field!" only the idiot will keep going... Again don't bring wanted elevation in the discussion. only an madman will deny any wanted elevation LOL. And if you noticed, options requiring elevation are usually indicated by the admin icon next to them. I did the comparison to show you, as you are an HIPS user, how the hell can you be disturbed by 2-3 UAC prompt a day (i don't see any reason to have more than that) compared to 10+ HIPS prompts every time you want install/update something... yes , and who cares of the intentions when we don't want any unwanted elevation, that is how UAC is supposed to be used. I don't need UAC to tell me why (like BBs or HIPS), i want it to just prompt me when any elevation attempts are made. stop talking about YOUR config in a general UAC usefulness thread. Average Joe config doesn't use HIPS nor sandboxes or whatever geek softs we see here, most only use what Win10 offers without even touching the settings... so for them UAC is useful. if i own a tank, i wont bring it in a general "does seatbelts are useful" discussion to say seatbelts are useless to me...
I'm not going to respond to everything, because you seem to completey miss the point. So it would be pointless to continue this discussion. I believe that wat0114 does understand my point of view. Speaking of HIPS, I don't mind alerts, but only if they are worth it. For example, EXE Radar will give alerts, but you can't blame it because it needs permission to put some app on the whitelist. HIPS will give alerts, because it will warn about stuff like code injection, service/driver installation, keylogging and more. But in general, I'm also getting a bit tired of HIPS alerts, they are monitoring too many pointless things. And it's best to simply auto-block stuff. But this is off topic.
Appears to me being lost in these discussions is if you keep UAC set at its default level, you're not going to get a lot of elevation alerts. On the other hand, you're not going to be alerted to possible LOL attacks. The truism "pay me now, or pay me(dearly) later" comes to mind …..... Also software like OSArmor are great at protecting you against known LOL misuse. It's the unknown ones that one needs to worry about.
well, no, they're called drive-by downloads. Anyway, for someone such as yourself and others who abhor the UAC prompts, you might be interested in SuRun. It works similar to UAC except you can launch known, trusted applications without the need for a password from a SUA. However, I believe it's no longer under active development, but I can confirm the latest version worked without issues on Windows 10 as of around 6 months ago.
Except Spyshelter, I don't see any valuable HIPS, Comodo isn't what it used to be...others are in suites, so worthless.
I don't agree. I have found Eset's to be very effective. Its problem is the user interface/features to it is something akin to a HIPS from the stone age. Kaspersky's HIPS use on the other hand was outright mind boggling and one reason I have never used the product for some time. BTW -SpyShelter HIPS has its own issues. It doesn't detect process hollowing activities. Eset's does providing a user rule for the process has been created to prevent process modification. In regards to process hollowing, I recently saw a "doozy" of a ransomware sample that did it against svchost.exe.
You can't be serious. I mean, how do we block drive-by downloads? We do this with anti-exploit, white-listing, sandboxing, you name it. Like I said, the chance that you, me and guest (with our highly secured systems) will ever get to see the infamous unexpected UAC alert is slim to none, let's face it. And I have zero interest in SuRun, because I assume it won't help when you're installing apps. No, that's because I've been using HIPS for 15 years. Luckily, you can disable certain stuff in SS, to reduce alerts. But you can't disable the monitoring of certain registry keys. Also, you can't control the white-list in SS, otherwise I would have probably used it. And lastly, SS doesn't auto-block stuff, like protected file access and outbound network access.
You may have misinterpreted my response. It was mostly tongue-in-cheek, because the system was not poorly secured as you had implied, but UAC indisputably triggered on the attempted drive-by installation which attempted to install elevated. There was no danger of that happening because the person using the computer is not click-happy. SuRun is simply intended to address the frustrations some people feel at having to answer UAC alerts with a password when they are opening known, trusted processes. I'm surprised you would have zero interest in it.
Just to clarify, when we are talking about drive-by's, we're talking about automatic exploits. So it's not a drive-by when some person is tricked into downloading malware. About SuRun, will UAC still pop-up when you install software? And you shouldn't be surprised, because what I'm basically saying is that auto-elevation isn't a big deal for me, especially if you're in control over all processes that want to run. Well, except when you will face a "super exploit" of course.
There was no intended download or trick to download. The UAC pop-up happened on the web page. I've never used it to install software, so I'm not sure. Why would you not simply log into your administrative account and install software from there? That's actually the proper, most sensible way of installing software. At most, you're simply clicking once for a UAC prompt-for-consent alert. Surely that can't be such an inconvenience for you, is it?
Here's something to test SpyShelter against: https://personalfirewall.comodo.com/testyourfirewall.html My Eset HIPS rule for explorer.exe nailed it.
Test fails for me. Maybe I'm doing something wrong? And IE is not my default browser. Edit maybe I'm supposed to only type text rather than type then enter?
I looks like you did everything right and whatever security protection you are using most likely blocked the .dll injection. In my case, I received an Eset HIPS alert about explorer.exe attempted process modification right after the "Sending" message appeared. I denied the request and ended up with display messages identical to those you received. -EDIT- Another possibility is the test perhaps doesn't work on Win 10. Perhaps the API shown, ContextRemoteExecute, doesn't work in Win 10 IE11. Hum ….. Appears this test might be "ancient." The below ref. dates to 2005: https://www.codeproject.com/Articles/10275/Remote-Library
I figured out what the Comodo test is doing. First you need to open IE11, then run the test. This also won't work on Win 10. What the test is doing is injecting a .dll into explorer.exe. It is then using the .dll to hijack a thread into IE11 via the .dll. It won't work on Win 10 since IE11 runs under the runtimebroker.exe child process of svchost.exe. In Win 7 and possibly 8.1, it should work since IE11 runs as a child process of explorer.exe. -EDIT- Oops. I forgot I was running IE11 w/EPM enable in Private mode. This is what causes the above execution behavior. In other words, IE11 runs identical to Edge. The test still has value in checking if your security product is detecting the attempted .dll injection into explorer.exe.
Refer to my edited post. When I ran IE11 in normal mode, it does run as child process of explorer.exe. A couple of reasons why the test fails, IE11 w/EPM enabled activates appcontainer which is preventing the thread hijacking. Most likely is ContextRemoteExecute() function is no longer supported by recent Win OS version since this is the call the test fails on. Note that the test windows shows ielowutil.exe x(86) running. This is Internet Low-Mic Utility Tool which is: Appears Comodo has figured out a way to LOL misuse the process to initiate a remote connection which fortunately no longer works.
Well, then it sounds like a poorly secured system to me. With AE, you should never get to see the UAC alert popping up, at least, if it was truly a drive by. I never saw a successful drive-by attack on my system with browsers like Opera, Firefox and Vivaldi so far. Not even with IE, way back. Are you kidding me? That's one of the reasons I hate UAC so much, it will pop-up for each app install.
Thanks again. The test isn't a concern for me anyway, especially since I don't have any anti-injection HIPS security in place. The firewall I use is purely a network filtering program for applications and processes. The family member's computer can't be as tightly secured as my own, because said member will have none of that so I had to strike a balance between convenience and security with more emphasis on convenience. The exploit attempt failed anyway, so I don't see a poorly configured system at play here. Also, arguably the most important measure is in place: system images that can be restored in mere minutes if needed. Well I get where you're coming from, I suppose. If you're that annoyed with a single pop-up, then you must be continually installing apps. Maybe you need a VM?
If you use a static system or don't do more than 2-3 admin tasks a day, UAC is almost unnoticable. Browsing, watching vids, listening music, working on office, etc... Basically what a computer is mostly used for won't trigger any UAC prompts. Any other uses of a computer that trigger rain of UAC isn't conventional computer use, and so must not be taken into account when discussing about UAC in general.
It's poorly secured, because you somehow saw UAC popping-up during browsing, that's my opinion. And you hit the nail on its head, it's about the balance between security and convenience. There's nothing convenient about UAC. When I have already secured my system with multiple security tools, I'm not going to keep clicking on dumb UAC alerts, even if it's only 3 to 5 times a day. BTW, how does macOS handle this? I remember they made fun of UAC on TV commercials, when it was introduced in Win Vista back in 2006.
Here's another example of malware that doesn't even trigger UAC: https://securingtomorrow.mcafee.com...rar-unacev2-dll-vulnerability-cve-2018-20250/
Note that this is exploiting a WinRAR vulnerability in its earlier versions: https://nvd.nist.gov/vuln/detail/CVE-2018-20250 It is a given that an exploit can bypass UAC and a lot of other stuff for that matter. -EDIT- Also this is not a UAC bypass: UAC doesn't monitor the startup folders since they are associated with the logged on user account:
