Jump to content


  • Posts

  • Joined

  • Last visited

About Parsh

  • Rank

Profile Information

  • Location

Recent Profile Visitors

273 profile views
  1. It's almost always trial and error when you dig deeper where potential is unlimited. Thank you! I am keeping rules tested over a few weeks and the system is doing fine. Backups are on point. I do not like to keep fiddling with the rules, to be able to focus on my work projects. But every once in a while your hand itches to improve on something. I'm always open to learning from other's experiences 😄
  2. Hello folks! I could not gather an explanation regarding point 5. I wonder whether svchost is just launching a service required by the browser OR trying to inject a DLL indirectly required by the browser itself OR Windows Security does it (though I've removed exploit protection rules) OR done by ESET (eplgChrome.dll / eOppMonitor.dll) ... The last point is mostly not the case because if the 2 DLLs failed to load due to Code Integrity Guard (now disabled), I used to get an error that I now don't. The browser works well. My concern is that an essential security mechanism should not get broken. ESET generates a similar alert that svchost is trying to modify Adobe Reader process space when launching it. @itman I tried allowing svchost to modify the browser, and protecting it from modification - this as you say, could be ad infinitum. I am however not getting any alert that a process is trying to modify an svchost process. Have you set rules to block other processes from modifying the browser or vice versa? If yes, could you share an insight into that and the exceptions you've used? Thank you.
  3. Thanks! I have read quite a few observations of yours on WS. However, I see a lot of them were about you experimenting with custom rules Yes. I do that. While I've restricted modification (some checkmarks from file ops and some from application ops) of browsers and browsers from modifying others, some actions like the updaters and msedge_proxy are allowed to modify the browser. And the browser is allowed to only start print spooler. Similar thing with WPS Office. I will confirm the svchost thing from MS support. Allowing svchost to modify browser in usual case could be fine. But as you rightly said, the svchost could have been maliciously injected and it might be difficult to categorize it even keeping a watch on svchost (perhaps not if you have a profound knowledge about the activities). Ad infinitum for sure! I try to compensate by monitoring firewall connections of such processes (possible attacker-victim chain) carefully. I have limited for sure, but decent idea of the uses of such system processes and related services. I had read that "AppContainer" flag has been set default in chromium browsers and the optional is GPU-AppContainer Lockdown. However, PE or PH does not show integrity of any browser process as 'AppContainer", except for the GUI process that is set when the optional "GPU AppContainer Lockdown" is turned on. Sandboxie now has its processes set to untrusted, so better than before. It's not being actively developed but a very occasional fixes is a sight from Sophos. I have been contemplating - if using the "Application operations" from the HIPS rules settings on the browser processes could more or less act like a sandboxie replacement.
  4. I agree about the technicality part. However I believe this is not a sensitive info. I wondered about this since Kaspersky's 'Application Control' rights customization for individual apps has a section of "Intrusion into other processes" that states "Perform code injection" and "Modify memory of other processes" as two different sub-entries, among others. Hence, whether code injection is a part of the "Modify state of another application" or not in ESET HIPS is doubtful but important to learn for a user relying on the same. Sorry about having complicated my query. It's not about files a user downloads and that get scanned by the static engines. Whether some HIPS rules can be made to prevent different in-memory attacks to some level (limited to the scope of ESET's knowledge)? An analogy could be that, say if I block browser from "starting new apps" and from "modify memory of other processes" etc, it would probably limit/block browser attacks from affecting other processes ie. non-browser processes. This - by creating a wall, instead of just detecting specific attacks and allowing the rest of activities not known as malicious. You answered the latter part? means that activities of trusted/reputed processes are not monitored by Smart Mode right? Sure thing. Thank you. I see it's a common scenario with browsers and blocking it doesn't affect the browser usability at least.
  5. I would like to understand a few things about the HIPS rules and scope: Does enabling option "Modify State of Another Application" include monitoring and asking/blocking of process hollowing and other ESET-known process injection techniques, among the in-memory attack detection that the option resembles? What HIPS rules (if feasible, and what could be their scope if used) can be used when surfing the web, to always ask/block (1) all detected drive-by downloads and (2) various in-memory attacks (ESET-HIPS-known)? Does the HIPS in Smart Mode alert of very suspicious activities of unknown/less reputed applications only, or are trusted applications monitored too? Do the new parameters (Aggressive/Balanced...) for the "Suspicious applications" in the Detection Engine tab belong to the Deep Behavioral Inspection/HIPS, or no? I've set "block" rule for "Modify State of Another Application" to protect Edge and Vivaldi. Everytime I start the browser, I get a notification "svchost" blocked because of this rule. Can someone explain in short why svchost needs to do this and is it safe to let it be blocked? In the sense if this is a windows security mechanism that is being broken. I'm aware that ESET by default monitors for browser exploits, known process injection mechanisms and such. However, my questions revolve around whether hard HIPS rules can be set to deal with the same and get ask/block alerts in respective cases above. I have set rules with these regards, however not sure about the scope and efficacy. Eg. If a trusted application has been maliciously modified (say supply chain attack) and a part of it does something unexpected, something malicious. Will that be monitored and likely alerted about? Eg. In the browser case, I'm trying to figure out if ESET HIPS rules could more or less achieve what Excubits MemProtect application does. To cage internet facing app processes like the browser and prevent other processes from modifying its memory/ perform code injection. And also not allowing the browser to do so with other processes (exclusion to allow the browser, browser_proxy & the updater to modify the browser...) Thank you very much!
  6. Must be that. I'd updated to the new version just yesterday. However, the build date of HIPS support module is from February (no recent changes). Some other related module, that got fixed, might have been the culprit.
  7. I have restricted PS via registry changes, HIPS, OSArmor custom rules >> common PS commandlines, so couldn't test that. I tried the same procedure on cmd.exe a few times, without admin rights and then with admin rights. HIPS: Smart mode Detection Engine (malware): Aggressive Detection Engine (suspicious apps): Aggressive and I could not simulate. The HIPS alerts followed the UAC prompt and only after allowing the sequence, did the cmd window open. Cannot say if the behavior is random or has a less likely scenario.
  8. I updated to the latest version yesterday. Besides the mentioned changes and the new provisions in the Detection Engine, I can see that the option to disable "Access Setup >> Require full administrator rights..." has been removed from the GUI and subsequently from the config file ---> <ITEM NAME="EKRN_CFG"> ... <NODE NAME="RequireElevation" TYPE="number" VALUE="0" /> Now, the user has to answer UAC prompts everytime when saving a rule through (interactive) Firewall alerts. Not the same for HIPS alert, as expected from earlier behavior. Is that it or there's a workaround? Kindly let know. Thank you.
  9. ESET sure has hidden rules constituting integral and critical rules w.r.t. the OS. That would be for every well-built HIPS. However, as Macros generalized and indicated, the action is to simply Allow in such use cases. No idea about relation with pre-defined rules. Very true about Comodo. HIPS alerts in Comodo vary by mode, however, the USP of Comodo is its auto-containment. While many contextually educated ESET users tend to rely heavily on HIPS as that's the only and highly configurable dynamic component.
  10. So I can infer that it doesn't take any rules into account, but auto-allows the action. The purpose of blocking VS asking about some operation may differ. However, the risk you're mentioning will lead to something equivalent to a 'block' action that would have been set for that action (instead of 'Ask'). Rarely would someone make an 'Ask' rule for something he/she considers to be safe. So, when there's a less likely failure of an 'Ask' alert, blocking will more likely not be disastrous, but for good. The user can brick the system with a bad 'block' rule too. At least, there could be an option in HIPS settings where the user can select whether ESET should auto-allow / auto-block / keep the popup (ie. action is blocked until alert is answered) giving a finer and desired control to the user, and he'll be responsible, for good. And the default option can be set to what it is currently --> auto-allow (to prevent any mishap). Could you please forward this suggestion to the ESET Technical Team for consideration? The current behavior almost defeats what the option name stands for, Ask.
  11. Hello, I've configured some HIPS rules to 'Ask' when some apps are started/ their states modified/ they launch other applications. Eg 1. I have set an 'Ask' rule (among other browser rules) when any app tries to modify the state of browsers. So when I launch Yandex browser from Taskbar, I'm alerted that svchost.exe is trying to modify browser.exe (run inside Sandboxie). If I do not answer the Allow/Deny call within ~1 minute, it automatically allows the action 1️⃣. Eg 2. Same is the case when I restrict apps (Ask rule again) from modifying certain folders to protect them from modification/deletion. I referred to the Help section of ESET IS ... My queries w.r.t. the 'Ask' alerts are Does ESET HIPS always auto-allow if the Popup alert is not answered within a minute? OR Does it decide action based on the source app reputation? OR Does it decide based on the rules (as quoted above)? If yes, could you please elaborate? I find this behavior 1️⃣ not desirable or intuitive at all. If some user is choosing to 'Ask' for a use case, he/she really wants to be alerted and manually address the scenario. I would not want that HIPS allows some suspicious action (for which I've set an 'Ask' rule already) automatically when I've been for a nap or a coffee break! Thank you.
  • Create New...