itman

I was having an issue similar with my income tax software. I assume your backup software is 100% trusted? Also note that what I am going to recommend will disable all protocol filtering protection for the application i.e. the network traffic will not be scanned for malware. The following instructions apply to version 8. Navigation might be slightly different for version 9. From the lower Eset desktop icon, select "Open Eset Settings." Then select Eset "Setup" setting. Then select in the following order; Web and email -> Web Access Protection - configure -> click on the Protocol filtering "+" sign to open its options -> Excluded applications. Then enter a checkmark for any applications related to your backup software as noted below: Finally click on "OK" box and "Yes" for any subsequent UAC prompt. Then close Eset settings GUI and test your software.

Personally, I would create a "block all" user firewall rule with logging for that IP address. At least, the Eset firewall log should point you to where those connections are originating from. An example of such a rule is shown below:

Appears you traced the problem back to MalwareBytes Anti-Malware: Thanks for help! You are the best support! You answered fast and you were really helpful! I uninstalled Malwarebytes Anti-Malware and now everything is fine! Was MBAM running in realtime mode? Even if used as a second on-demand solution, the later versions of MBAM can cause problems with any other AV solution running in realtime.

Was the IP address blocked the same as you posted previously, i.e. 119.1.109.121?

Just ran the lastest ver. of GMER that now supports x64 OSes. Just love how it dropped a driver in %AppData%\temp directory. I definitely need *.filename suffix support Eset!

Did you do the restore in "safe mode?" I have never had an issue when do it this way.

I check your settings and yes is online but 0 protection The only way to protect my internet It was to buy this router TL-WR841N and have firewall online protect against hackers or ddos attacks Second protection I buy this Outpost Firewall Pro 9.3 protect against hackers or ddos attacks I check google new firewall is name Anti DDoS Guardian 3.4 secure against Stop SYN flood, TCP flood, UDP flood, ICMP flood, bandwidth attacks etc eset smart security 8 and 9 the firewall is to weak against this attack and 0 detect and 0 block sorry You must work seriously with this firewall We are 2016 and flood is nr 1 most dangerous If someone is launching a full scale DDoS attack against you, simply shutdown your network by selecting "Block Network" from the Eset lower toolbar icon as shown below: Eset has its "warts and all" but the retail firewall is not one of them. It is one of the few that has full IDS protection - Comodo's firewall doesn't have like protection. As far as the Google firewall settings you noted, the IDS and packet inspection configured as noted below equate to those:

Interesting comments. Appears Eset dials out every 1/2 hour, which I believe are the LiveGrid blacklist updates. And the connection is to their servers. So I an sticking with the botnet checking as the reason for the port 443 dial outs by ekrn.exe within the 1/2 hour intervals.

...... -> hxxp://www.senderbase.org/lookup/?search_string=119.1.109.121-> -> https://www.spamhaus.org/query/ip/119.1.109.121 https://www.spamhaus.org/sbl/query/SBL156393 https://www.spamhaus.org/sbl/query/SBL171415 https://www.spamhaus.org/pbl/query/PBL188929 "chinanet-gz is providing services to spammers and botnet operators since years and ignoring all abuse complaints sent by Spamhaus and 3rd parties" (Guess that could be one reason why MBAM blocks that IP) hxxp://www.senderbase.org/lookup/?search_string=195.154.36.97-> -> hxxp://www.abuseat.org/lookup.cgi?ip=195.154.36.97 "IP Address 195.154.36.97 is listed in the CBL. It shows signs of being infected with a spam sending trojan, malicious link or some other form of botnet. It was last detected at 2016-03-07 02:00 GMT (+/- 30 minutes), approximately 4 days, 23 hours, 30 minutes ago." @spc3rd, Sorry to hear about your health issues, I hope you get better and feel better soon again.Take care. Here's an interesting tidbit. That IP address,195.154.36.97, scans 100% clean at VirusTotal. Not a single AV product flagged it. Also didn't previously noticed the "botnet" reference. Perhaps that is what is ekrn.exe port 443 dial-out is checking for?

Open up Eset's advanced settings -> Network -> Personal Firewall -> IDS and advanced options -> Packet Inspection. Then ensure "TCP protocol overload detection" is checked marked as shown below. Then re-test.

That might partially explain what is going on here. I did do a lookup to hxxp://threatcenter.crdf.fr/?Stats yesterday. Had no idea that that they had a rep problem. So will stay away from there from now on. Marcos, take note. So the question is does Eset use the clould for rep scanning and the like while browsing? And why would ekrn.exe be connecting to an IP address using port 443 to do so? This link is a http link, not https. This does look like something to do with Eset's web filtering but would like an explanation.

I just scanned that Chinese IP address here:hxxp://www.borderware.com/lookup.php?ip=119.1.109.121&Submit.x=29&Submit.y=12. Definitely a bad IP. I have seen ekrn.exe connections to France; IPs 62.210.11.201 and 195.154.36.97. 195.154.36.97 is a bad IP! What is going on here Eset? I noticed these are port 443 connections. This have anything to do with SSL protocol scanning?

I came across a past posting that Bitdefender was having memory leak issues on certain Win OSes. They traced it back to Windows Filtering Platform. Perhaps an area for Eset to look at as the possible source. Maybe something changed in WFP and Eset's NDIS mini-port filter is now causing issues?

I am located geographically close to OP's location in the U.S. I created a firewall monitoring rule for ekrn.exe. All my ekrn.exe connections have either been to Eset servers or to U.S. based servers of Akamai, Cloudflare, or Microsoft. So it appears OP has a problem here. The problem also might be related to MBAM which I strongly suspect. @spc3rd - why don't you likewise create an allow firewall rule with logging enabled for ekrn.exe. Then verify that that log entries show a connection to 119.1.109.121.

Since you are in the U.S., I would like an answer from Eset if they are indeed routing traffic through Chinese servers.

That IP address is associated with CHINA-TELECOM China Telecom. Possible they are part of some backbone network Eset uses? Are you located somewhere in the Far East? I scanned that IP address here: hxxp://www.ipvoid.com/scan/119.1.109.121/ and it is 100% benign. MBAM will block any IP address range associated malware although the individual IP address is clean. Might be what is happening here.

Here are the thumbprints for its code certs: Additional Code Signing Certificates The certificates below are also signed by Ontinet.com S.L.. 7660462ABD475DB5CBDC286B282B950C (Jan 22, 2016 to Nov 15, 2017) 0179EADD1F311E7E3B67BE1F53929BDC (Jun 28, 2013 to Oct 03, 2014)

I believe this has to do with the certificate pinning feature Chrome implemented a while back. You might want to "play around" with that setting in Chrome to see if it resolves the issue. Appears to be a conflict with that feature and the cert. pinning that is being performed via Eset SSL protocol feature.

A comment about memory leak: Note that constantly increasing memory usage is not necessarily evidence of a memory leak. Some applications will store ever increasing amounts of information in memory (e.g. as a cache). If the cache can grow so large as to cause problems, this may be a programming or design error, but is not a memory leak as the information remains nominally in use. In other cases, programs may require an unreasonably large amount of memory because the programmer has assumed memory is always sufficient for a particular task; for example, a graphics file processor might start by reading the entire contents of an image file and storing it all into memory, something that is not viable where a very large image exceeds available memory. To put it another way, a memory leak arises from a particular kind of programming error, and without access to the program code, someone seeing symptoms can only guess that there might be a memory leak. It would be better to use terms such as "constantly increasing memory use" where no such inside knowledge exists. Ref.:https://en.wikipedia.org/wiki/Memory_leak

Appears there is no way to protect a folder without path transversal? Almost all HIPS's have this capability. For example, McAfee's Endpoint uses the "&" character coded as; C:\Windows\& to indicate only files within the Windows directory but no sub-directories.

I run as limited admin, that Eset option is enabled, and UAC is set to max. level. I never once have received a UAC prompt from Eset for an Internet connection. Only Eset elevated prompts I receive are for changes to Eset settings. Sounds to me like this has more to the user has some Group Policy/Software Restriction Policies settings that force the browser to start with regular user privileges or the like? And I don't why Eset's firewall would interfere with UAC? Wireless connections do update registry TCPIP keys upon access though.

hxxp://www.eset.com/int/about/technology/#advanced-memory-scanner "Advanced Memory Scanner complements Exploit Blocker, as it is also designed to strengthen protection against modern malware. In an effort to evade detection, malware writers extensively use file obfuscation and/or encryption. This causes problems with unpacking and can pose a challenge for common anti-malware techniques, such as emulation or heuristics. To tackle this problem, the Advanced Memory Scanner monitors the behavior of malicious processes and scans them once they decloaks in the memory. This allows for effective detection of even heavily obfuscated malware. Unlike Exploit Blocker, this is a post-execution method, which means that there is a risk that some malicious activity could have been performed already. However, it steps into the protection chain when everything else fails." I assume you had something like Emsisoft's Behavior Blocker in mind when you made this request. Just wanted to mention the purpose of AMS and what it does. hxxp://static3.esetstatic.com/fileadmin/Images/INT/Docs/Other/ESET-Technology-Overview.pdf Edit: This PDF literally explains the ins and outs of the software itself and what happens behind the scene on the back-end systems. Every customer/user that is interested in this kind of geek information (it is very informative) should take time and read through the whole PDF. Sorry for the late reply. I have not been on the forum in a while. I didn't think I was going to get a reply to my post. Thank you for the .pdf manual. I will have to look more at AMS, but I don't think it is the same as something like Emsisoft's BB. Marcos said AMS only triggers a memory scan here. https://forum.eset.com/topic/5283-behavior-blocker/So the question is if it only triggers a memory scan then is it only looking for already blacklisted executables. The equivalent to Emsisoft's behavior blocker in Eset is advanced heuristics using DNA signatures with internal sandboxing. It is part of the Threat Sense real-time engine. As far as which is more effective, only testing with some previously unknown malware will determine that.

Administrator didn't work for me doing a boot scan. I have 3 HDDs configured as follows: C: DSK2-VOL1 WIN 7 w/Eset SS ver 8 installed D: DSK1-VOL1 WIN XP E: DSK3-VOL1 Data only F: DSK1-VOL2 Empty partition K: DSK3-VOL2 Data only Here's the scan log:

For a very long time, I have been trying to create a registry HIPS rule to monitor creation of new services. I originally created this rule for example: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\*\ However, the HIPS would ignore the "\" following the "*" and alert at all levels subordinate to services. After much experimenting, I found that the following will accomplish alerting for only the first level subordinate to services: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\*\\ So Eset should update there documentation to include this fact. Next through testing, I found that the HIPS will not block any new key creation but any new value keys subordinate to the new key. I verified this by running in interactive mode. For example, the HIPS allows the following key to be created: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\xyzservice but will alert on the creation of; HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\xyzservice\some dword field value; and only for xyzservice. If I create a new key subordinate to xyzservice, the HIPS will not alert for any new field values created for that key! So I am still at wits end on how to block key creation with this HIPS immediately subordinate to services? -EDIT- I did one last test. This coding: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\\ will alert on renaming or deletion of HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\xyzservice key. However, it will not alert on its creation. So as far as I am concerned, this is a bug.

Thanks for the reply. My gut is telling me that the HIPS is checking driver loading at boot time against the default allow rule. But ignoring the fact that drivers can be dynamically loaded anytime. And unfortunately from places other than from places other than C:\Windows\System32\drivers\* . BTW - I am still awaiting the use of wildcards feature for filenames.