persian-boy

I see ppl in Persian forums that got infection from Anti-Theft! I suggest them to disable this feature and also reset their passwords from my.eset.com!idk how but someone could access their windows and create a new user!

Don't exclude it! that application is not safe.Use wise diver care which is safe and reliable.

Whats the point of this rule?! it doesn't work! Macros don't you consider this as a bug? Itman do you mean if smth want to load a driver outside the c: Windows\system 32\driver then hips will alert? Eset even comodo garbage which is free can monitor the loading drivers! I already mentioned this issue when I was talking about the PChunter! remove load driver rule from the HIPS or fix the problem!

Action: ask file operation: Load driver files: all files This rule doesn't work! never got any alert from Hips :-) any idea?!

Hi macros, I never used the firewall in the learning mode. No problem! let the user end up with billions of rules(2 weeks is enough for creating all rules). The hips will not protect me in this situation! ye maybe just block smth unknown from starting!but it will not protect my Pc! the interactive mode+plus some costume rule is the only way to make sure everything is okay.

What is it mate?am i joking?!lol

Hi, whats up? if I set the Hips in learning mode and at the same time my browser wants to write to a folder/file then Hips will assign a rule like This: Source: browser//operation: write to file//Traget: All files Why all files? seems the hips don't understand it should only set the allow rule for a specific file(user:\broswer\browser folder), not my whole hard drive!The same story for registry and ... I Want Hips to set Rules based on the what is happening and in real time! it won't limit the actions it just allows for everything(like that auto allow rule for ask mode lol)! whats the point of learning more?! what if smth want to exploit that application?(in my case browser) Eset I consider this as a bug! pls, consider a fix for this issue!

Happy to hear that:D keep up the good work.

That's bad

https://browser.yandex.com/beta/ try your hacks against this browser. I'm using it! it has an anti-keylogger and anti screen recorder install it then enable the protect and run your keylogger after that open the browser and start typing! report what you see:D I use this combo: Yandex beta+Ghostpress+Eset! good combo!

Probably bug! I think I found the same problem too...

Av test!? Ese is the lightest av! hardcoded for best performance.according to av test Bitdefender is one of the lightest av!but this is not true lol.

https://www.wired.com/story/quantum-computing-is-coming-for-your-data/ Hi, I will be happy if Eset tells me what kind of plan they have to Protect me or Endpoints from such attacks?

Banking mode doesn't work with Yandex browser but IDC!!why you do care?it's not important!

I think there is smth wrong with your DNS, Isp or VPN because I don't have such problem!change your DNS? turn off VPN or reset internet settings? Yes normal but sadly Eset refuse to provide a changelog for these micro updates :-) I think you are talking about the HIPS?!if yes then set it to learning(since you don't understand this)mode and your problem will be gone!the learning mode won't alert to anything!you have to provide some screenshot. You shouldn't install the version 10! because Eset added many features to the new version! not a wise choice! but you can try to remove Eset from safe mode: https://support.eset.com/kb2289/?locale=en_US

Does it apply to chromium forks? or only chrome?

I think macros will report it if he considers it as a bug! it's not a bug but like a bug!this is a weakness in windows!but Eset can fix it!

What? The moderators already saw my comments! no need to submit anything to Eset!they are not blind.

Eset windows 7 users are in danger because there is no Signed Driver Enforcement.pls, find a solution to this problem! I'm wondering why no one answer!isn't important?Lol, this tool bypass the whole protection!and Eset is silent!

Suggestion: Pls make Hips to ask when a process wants to load a driver!

I know about Signed Driver Enforcement but I'm not talking about this!the problem is more than that. Hips is there to protect my files:D idc! Whats the point with Hips?its suppose to protect me :-)? Also, ESET hips don't alert you when smth wants to load a driver! while comodo ask! What if it's signed?I know it's not common but what if?PChunter can dmg every protected file by Eset! ppl paid for protection!xd while the hips not gonna work in this situation! Look at comodo: it's smarter that Eset in this situation.

Sorry, but I lost my mind:D When the user locks His files with Hips then he wants Eset to protect them!right? not everyone is malware analysis Lol ! not everyone knows an allowed driver can bypass the whole protection?!btw with or without an infected driver Hips should protect the files because the user relied on it!just imagine if it was a zero-day, not Pchunter! then what?

I could even remove the Eset files and folders with this tool! that's sound bad! I gtg! but will back for an answer! P.s This tool made by Chinese! keep up the bad work Eset:P

Hi, There is a tooL call Pc Hunter!it can remove every file, folder, driver and... with one click! I tested it against comodo Hips and Comodo failed to protect my protected files form change!! Just tested it against Eset and the same story! I asked hips to protect some files! then run my tool and force remove those files! Not even one alert from HIPS!the files gone :-( my next generation protection failed. An expert told me how it works(all from that guy): It probably bypasses API hooks for file removal with a system call to NtDeleteFile, or it uses a kernel-mode device driver to remove files without triggering NtDeleteFile hook on SSDT/FltRegisterFilter callback. I'm betting on the latter being the reason why it bypasses your HIPS. If it installed a driver without consent according to your HIPS configuration then it probably used a work-around for that too. There are many ways to work-around HIPS, you just need to know how the monitoring is applied. I mean I've never used the software you're referring to but I know it is genuine security software and appears to be aimed at cleaning rootkits infections, so you'd expect them to have great knowledge on Windows Internals which is more or less the entry point to bypassing features like HIPS. There are many ways to install a device driver. The first method would be relying on the normal service manager to create and start a Windows Service for a device driver. The second method would be applying registry modifications to setup the device driver installation (basically replicating what the service manager will do for initialisation before the start operation) and then using Native API functions like NtLoadDriver to start the service. The third method would be using an undocumented Native API function called NtSetSystemInformation, which is something that Microsoft used in the past for this same thing (which is how the technique was discovered). Another method could be injecting code into another process and have it load the driver for you. Another method could be patching an existent driver which isn't active but can be accessed on disk for read/write and then have that utilised automatically at boot, etc. The NtLoadDriver and NtSetSystemInformation techniques are commonly only ever used in malicious software, but their use is not prevalent. Especially not nowadays at-least. Genuine software usually uses the documented service manager APIs, but when it comes down to security software, it would be reasonable to expect a sense of undocumented things going on because sometimes it is the only way to achieve the desired result. This is also why some security software causes crashes on new updates to Windows (e.g. new OS version won't be supported for X amount of time because the vendor needs to start reverse engineering and maintain support for "undocumented" things it may have been previously doing for specific features). We also would need to look at how the HIPS product you are using actually works. It may be the case of both kernel-mode and user-mode components, and reverse engineering the software would reveal the technique the vendor is using to have implemented the specific feature of discussion - of course I am not going to reverse engineer genuine security software since this is unnecessary and illegal, but you should get the understanding of what I am trying to say. If a security product is injecting code into running processes to control execution flow for when specific APIs are used, but the author of the software decides to make a "custom" wrapper for the targeted controlled function (or in the case of NTAPI invocation, relying on a direct system call), then that would be bypassed. Whereas, if a specific feature is implemented from kernel-mode, then the user-mode program would not be making progress by using undocumented tricks like a system call because it'd still pass through the security software's interception once it reaches kernel-mode level. In a situation like that, it would require a zero-day exploit or a work-around overlooked by the vendor which implemented the feature (e.g. a vendor may block X action but may have forgotten there was another way to do the same action which isn't under the scope of their monitoring yet). Malware can do these things and it could have done them for years. If we take a step back to the times around 2006 - 2012 there was some really deadly threats from those times surrounding rootkit infections which could do complex and sophisticated things, applying techniques to surpass behavioural prevention. However, without a bypass for PatchGuard (Driver Signature Enforcement feature specifically), you must have a signed device driver on 64-bit systems. Due to this, and due to many people moving to 64-bit over the many years since such a feature was introduced back on Windows Vista, the malware in the wild has significantly changed. It isn't normally about virus infections or rootkits to subvert even security software to hide other malicious software nowadays, but about generating income through ransomware and adware - those are the prevalent threats nowadays as far as I am aware. In fact, even banking malware has plummeted down a lot recently in my opinion - still popular though. It would have been common to find samples for Carberp, Zeus, SpyEye a few years ago, not as common nowadays. You have more chances of finding BadRabbit nowadays or a similar ransomware outbreak. As for removing system files, you can delete files which are even in use as long as you have the correct privileges. For example, you cannot delete a file in a protected directory without having the rights to access those files with delete requests (e.g. acquire administrator rights); files in use can be deleted via a Native API function called NtDeleteFile. You can do this from user-mode thanks to NTDLL which sends requests up to a kernel routine which eventually leads to the real function within ntoskrnl.exe (kernel-mode image -> the Windows Kernel to be precise). Explorer.exe and most other software relies on the normal Win32 API which will lead down to the Native API calls in NTDLL (-> Kernel), but when you use Native API functions from NTDLL to pass to kernel-mode directly in this way, you bypass the checks performed by the documented and Microsoft supported-for-use functions which are supposed to be used by developers. Alternatively, just use a kernel-mode device driver and then you can invoke kernel-mode only functions (instead of the original Zw routines) to make a wrapper for the Nt* functions using the kernel-mode only functions instead (which they would have originally called anyway), whilst bypassing kernel-mode callbacks registered by other device drivers (e.g. maybe by a security product) or potential kernel-mode patches which may be present (32-bit systems). The documented APIs will perform checks and put up restrictions for removing files in-use by other processes. The undocumented APIs won't necessarily have those checks, unless they are enforced from kernel-mode level under the original Windows Kernel routine which ends up being executed for the desired functionality which would be the end-result. This explains why you may not be able to delete GenuinePhotoshop.dll which is executing under GenuinePhotoshop.exe from the normal Windows File Explorer, whilst an external security tool like you have referred to will be capable of doing so. it uses a kernel-mode device driver to remove files without triggering NtDeleteFile hook on SSDT/FltRegisterFilter callback. It is because of x64 limitations for kernel-mode interception and ethical requirements. If an AV vendor patches the kernel and it all goes pear shaped, that is on them - they lose customers because of crashes and maybe even have to spend trouble dealing with law-suits if the data-loss was really bad. Btw Eset idc! what can you do for such thing?! I didn't know an allowed driver can bypass the whole Hips! where is my protection? you left me unprotected - _ - same for comodo hips! still didn't test the spyshelter! but probably the same result:D

Eset don't you want to fix this auto allow? more dangerous than useful!omg. Every HIPS(Comodo.spyshelter, Rehips and...) freeze the operation till the user answer the alert! whats the point of asking rule if its gonna allow it without my permission?! make no sense! Itman I know about those internal rules but I'm saying the interactive mod doesn't cover all operations! This is dangerous!Eset pls fix the bug! Eset updating the hips module in silent and without any changelog or information!that's bad!