MBAM blocks outbound connection attempt made by ekrn.exe to malicious IP address?

[spc3rd 9]

Good morning everyone,

 

     [using ESS v9 on Win 7 Home Premium SP1 x64 computer]

 

Pasted further down is an excerpt from my Malwarebytes Log yesterday.  I received the Outbound connection block alert to the IP address shown in the log.  The log shows this connection attempt was from ESET file, ekrn.exe.  (Unfortunately, I do not recall what I was doing at the time).

 

The IP address is in China.  I have checked the IP through VirusTotal, Hosts-file.net, and IPvoid, and do not note any security alerts.  Securi.net returns the message it is unable to scan the IP.

 

I have also uploaded the ekrn.exe file to VirusTotal; scanned it with SAS and MBAM.  No issues were found with it.  I have also run full scans of my computer with ESS, MBAM Premium, and SAS - no problems were reported.

 

My question:  Why would the ESET file in question be attempting an outbound connection to an IP address in China which MBAM blocked as malicious?

 

Malwarebytes Anti-Malware Log

Scan, 3/10/2016 4:37 PM, SYSTEM, XXXXADMIN-PC, Scheduler, Start:3/10/2016 4:30 PM, Duration:7 min 49 sec, Threat Scan, Completed, 0 Malware Detections, 0 Non-Malware Detections,
Detection, 3/10/2016 7:12 PM, SYSTEM, XXXXADMIN-PC, Protection, Malicious Website Protection, IP, 119.1.109.121, 60341, Outbound, C:\Program Files\ESET\ESET Smart Security\ekrn.exe,
Detection, 3/10/2016 7:12 PM, SYSTEM, XXXXADMIN-PC, Protection, Malicious Website Protection, IP, 119.1.109.121, 60341, Outbound, C:\Program Files\ESET\ESET Smart Security\ekrn.exe,
Detection, 3/10/2016 7:12 PM, SYSTEM, XXXXADMIN-PC, Protection, Malicious Website Protection, IP, 119.1.109.121, 60341, Outbound, C:\Program Files\ESET\ESET Smart Security\ekrn.exe,
Detection, 3/10/2016 7:12 PM, SYSTEM, XXXXADMIN-PC, Protection, Malicious Website Protection, IP, 119.1.109.121, 60341, Outbound, C:\Program Files\ESET\ESET Smart Security\ekrn.exe,

Thank you for your time and any enlightenment.

[itman 1,659]

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.

[spc3rd 9]

Hi itman,

 

     Thanks very much for getting back with me!  To answer your geo-location question...I'm in the Mid-Atlantic area of the U.S.

Perhaps that IP is somehow legitimately associated with ESS.  The issue of an ESS file attempting to connect with that China-based address + the MBAM block was just a bit concerning to me.  Figured it best to post an inquiry here first - to get an idea of what occurred.

 

Cheers!

[itman 1,659]

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

[Marcos 5,071]

Could you check if that IP address wasn't set as a proxy server in the advanced setup -> proxy server and under update -> http proxy|?

[itman 1,659]

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.

[itman 1,659]

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?

Edited March 12, 2016 by itman

[spc3rd 9]

     Thanks very much for your respective responses to my inquiry, Marcos & itman!

 

My apologies for the late reply.  Not feeling well - having to remain in bed.

 

[sidenote]:  I checked the MBAM log for today and did not see any further blocks being made.  Also, the daily scheduled ESS & MBAM scans done earlier this afternoon were clean.

 

(For Marcos):

 

At the location you indicated...under HTTP Proxy > Proxy Mode, the box on the right side of the page says, "Use global proxy settings".  I have no idea exactly what that means or where to find those 'Global settings'.

 

(For itman)

 

I'm not sure how to do what you're suggesting.  I've only been using ESS for less than a month now, and despite all the reading through the numerous "Help articles", etc....I'm ashamed to say that age and degenerative health issues are increasingly impeding my ability to understand & remember a lot of things, unfortunately.  The 'downward spiral' has reached the point now that I practically need simple, step-by-step instructions on how to perform most any tasks related to AV, Firewalls, & Anti-malware sorts of things.

 

(Just composing this reply alone has taken me well over an hour - something that I could have done in a few minutes only a year or so ago).

 

(Thank you also for the additional scanning info about that Chinese IP address.  A pop-up just alerted me to your reply while I've been typing this).

 

Thank you both again for your time and patience in helping me out!

Edited March 12, 2016 by spc3rd

[SweX 871]

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?

 

...... -> 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.

Edited March 12, 2016 by SweX

[SweX 871]

"I have seen ekrn.exe connections to France; IPs 62.210.11.201 and 195.154.36.97."

 

62.210.11.201 =  hxxp://zulu.zscaler.com/submission/show/0a488f4ae32fed497ee780a13e632fdd-1457747333

 

195.154.36.97 =  hxxp://zulu.zscaler.com/submission/show/f13900d05ca24d742ef31fa4308575f3-1457745695

 

Do they both belong to crdf.fr ? As in this crdf -> hxxp://threatcenter.crdf.fr/?Stats

ESET is not on their partner list: hxxp://threatcenter.crdf.fr/?Partners

Edited March 12, 2016 by SweX

[spc3rd 9]

Thank you SweX for your help and well-wishes!

 

I also want to again express my appreciation to itman and Marcos for your continued help as well!

 

I'll continue to monitor this topic as I'm able to, and see how things go.

 

Best regards to everyone!

[itman 1,659]

"I have seen ekrn.exe connections to France; IPs 62.210.11.201 and 195.154.36.97."

 

62.210.11.201 =  hxxp://zulu.zscaler.com/submission/show/0a488f4ae32fed497ee780a13e632fdd-1457747333

 

195.154.36.97 =  hxxp://zulu.zscaler.com/submission/show/f13900d05ca24d742ef31fa4308575f3-1457745695

 

Do they both belong to crdf.fr ? As in this crdf -> hxxp://threatcenter.crdf.fr/?Stats

ESET is not on their partner list: hxxp://threatcenter.crdf.fr/?Partners

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.

[itman 1,659]

 

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?

 

...... -> 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? 

Edited March 12, 2016 by itman

[SweX 871]

 

"I have seen ekrn.exe connections to France; IPs 62.210.11.201 and 195.154.36.97."

 

62.210.11.201 =  hxxp://zulu.zscaler.com/submission/show/0a488f4ae32fed497ee780a13e632fdd-1457747333

 

195.154.36.97 =  hxxp://zulu.zscaler.com/submission/show/f13900d05ca24d742ef31fa4308575f3-1457745695

 

Do they both belong to crdf.fr ? As in this crdf -> hxxp://threatcenter.crdf.fr/?Stats

ESET is not on their partner list: hxxp://threatcenter.crdf.fr/?Partners

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.

 

The Cloud (LiveGrid) is being used by the Web protection yes. But I fail to understand how a 3'rd party get's involved in real-time, if that is what's happening here. But we are only speculating, and I don't like speculating as there is a chance we draw the wrong conclusion here, and that would be no good. Better if ESET steps into the thread and clarify what's going on. I except that Marcos reads what we write here.

 

I mean, I understand that threat data from 3'rd parties like CRDF get's shared with ESET and maybe pushed to ESET servers -> which the client/software side connects to, but I have never heard of any vendor that let's their client/software connect to 3'rd party servers in real-time as part of the cloud service that the vendor has in-built in the product. I expect the software to have connections with the vendor only, and nothing else. Like this.....

 

3'rd party threat data -> ESET  -> ESET servers <- Software/client communicates with. (Roughly explained.)

 

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?

 

 

 

Well, who knows, lol.  I don't like speculating and sound like I blame someone or something for doing wrong here. I rather see that ESET clears any misunderstanding up that we may have initiated by our speculations in this thread. ESET may not be able to reveal much about these ekrn.exe dial-outs if that would help the dark side, but at least assure that it is normal and nothing to worry about. If not at all in public, then we have a PM system that is made for sharing secrets

Edited March 14, 2016 by SweX

[itman 1,659]

The Cloud (LiveGrid) is being used by the Web protection yes. But I fail to understand how a 3'rd party get's involved in real-time, if that is what's happening here. But we are only speculating, and I don't like speculating as there is a chance we draw the wrong conclusion here, and that would be no good. Better if ESET steps into the thread and clarify what's going on. I except that Marcos reads what we write here.

 

I mean, I understand that threat data from 3'rd parties like CRDF get's shared with ESET and maybe pushed to ESET servers -> which the client/software side connects to, but I have never heard of any vendor that let's their client/software connect to 3'rd party servers in real-time as part of the cloud service that the vendor has in-built in the product. I except the software to have connections with the vendor only, and nothing else. LIke.....

 

3'rd party threat data -> ESET  -> ESET servers <- Software/client communicates with. (Roughly explained.)

 

 

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.

[SweX 871]

 

The Cloud (LiveGrid) is being used by the Web protection yes. But I fail to understand how a 3'rd party get's involved in real-time, if that is what's happening here. But we are only speculating, and I don't like speculating as there is a chance we draw the wrong conclusion here, and that would be no good. Better if ESET steps into the thread and clarify what's going on. I except that Marcos reads what we write here.

 

I mean, I understand that threat data from 3'rd parties like CRDF get's shared with ESET and maybe pushed to ESET servers -> which the client/software side connects to, but I have never heard of any vendor that let's their client/software connect to 3'rd party servers in real-time as part of the cloud service that the vendor has in-built in the product. I except the software to have connections with the vendor only, and nothing else. LIke.....

 

3'rd party threat data -> ESET  -> ESET servers <- Software/client communicates with. (Roughly explained.)

 

 

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.

Yes, I assume you are right, it doesn't sound wrong in any way at least. And since ESET doesn't seem interested in making a comment about this - we can only go by what we believe is happening here.

[spc3rd 9]

Good morning everyone,

 

     I wanted to mention that once again, today at 8:17 a.m. (U.S. EST), MBAM made the same OUTBOUND block to the same IP address shown in the MBAM log excerpt I included in my first post (still shows the Outbound connection attempt as coming from ekrn.exe).  In addition, at the time of this MBAM alert, I had just restarted my computer after updating my ESS version & was viewing the Troubleshooting Log.  At the same time the MBAM alert was displayed, I noted that ESS blocked an INBOUND TCP packet from the same IP address.  The reason given in the log was "TCP packet not belonging to any open connection".

 

The only difference in this MBAM block was the port number, which was 64826 this time.

 

Cheers!

[itman 1,659]

Good morning everyone,

 

     I wanted to mention that once again, today at 8:17 a.m. (U.S. EST), MBAM made the same OUTBOUND block to the same IP address shown in the MBAM log excerpt I included in my first post (still shows the Outbound connection attempt as coming from ekrn.exe).  In addition, at the time of this MBAM alert, I had just restarted my computer after updating my ESS version & was viewing the Troubleshooting Log.  At the same time the MBAM alert was displayed, I noted that ESS blocked an INBOUND TCP packet from the same IP address.  The reason given in the log was "TCP packet not belonging to any open connection".

 

The only difference in this MBAM block was the port number, which was 64826 this time.

 

Cheers!

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

Edited March 17, 2016 by itman

[spc3rd 9]

Hi itman,

 

Yes.  The IP was the same.

[spc3rd 9]

Greetings again...

 

     Just a brief update that today at 1:15 p.m. (U.S. EST) MBAM has again blocked another attempted outbound connection from ekrn.exe to IP address 119.1.109.121.  It occurred shortly after I exported an ESS configuration file.

The difference(s) this time were:

 

- The port number was 51957.

-  ESS did not show a block of an incoming TCP packet from the same IP address like I mentioned in my last post.

 

Given the reputation of the IP address in question & since no one from ESET has entered this discussion to explain why these events are occurring - I consider it unwise to add the IP to MBAM'S Web Exclusions list.

 

Hope this is of some help & thanks very much for your time and feedback.

[TomFace 539]

Given the reputation of the IP address in question & since no one from ESET has entered this discussion to explain why these events are occurring - I consider it unwise to add the IP to MBAM'S Web Exclusions list.

 

 

Yes I agree not adding the IP would make sense, but someone from ESET did comment-see https://forum.eset.com/topic/7690-mbam-blocks-outbound-connection-attempt-made-by-ekrnexe-to-malicious-ip-address/?p=41269. Perhaps an updated comment from ESET is appropriate.

Edited March 18, 2016 by TomFace

[spc3rd 9]

Much obliged for your feedback, TomFace!

 

I should have re-worded my post a bit to reflect what you mentioned.  I'd been hoping someone at ESET would be looking into the issue I presented and be able to provide more info.  Being a new ESS user, it's more than 'just a little disconcerting' to be experiencing an event of this type right from the start.

 

Thanks again!

Edited March 18, 2016 by spc3rd

[itman 1,659]

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:

 

[TomFace 539]

Much obliged for your feedback, TomFace!

 

I should have re-worded my post a bit to reflect what you mentioned.  I'd been hoping someone at ESET would be looking into the issue I presented and be able to provide more info.  Being a new ESS user, it's more than 'just a little disconcerting' to be experiencing an event of this type right from the start.

 

Thanks again!

No problem Pete (I was just being anal -a nasty habit I suffer from -just ask my wife ). I just find it interesting that you, I and itman are basically in the same general geographic area and we are (I believe) are not having that same issue. (I too use MBAM, Prem. not free).

 

You are in GOOD hands with itman and SweX. They are both VERY knowledgeable (and smart too).

 

By the way, welcome to the forum Pete-glad you are here.

Edited March 18, 2016 by TomFace

[spc3rd 9]

Hi again, itman and Tom, and my thanks to both of you for your continued follow-up!

 

(For itman):

 

I appreciate the screenshots you included.  I'm not so adept at being able to do a lot of things as I once was, so the inclusion of such images, and/or step-by-step instructions are a BIG help to me!  I'll try my hand at creating the rule you suggested tomorrow, since I'm getting ready to hit the sack after I finish this post.  (I've never been able to quite get the hang of firewall rule-creation).

 

(For Tom):

 

It does indeed seem a bit odd that despite our Geo-proximity, I seem to be the only one experiencing this issue. 

(My previous internet security suite program was Outpost Security Suite Pro (lifetime license)).  Unfortunately, as you and itman already know......Agnitum was gobbled-up by Yandex, so I began my search for a new application to replace it with, before Agnitum ends all updates and support for it at the end of this year.

 

After trying-out ESS for about 2 weeks or so,, as well as, monitoring the ESS sub-forum here (to get an idea of both the timeliness and 'quality', so-to-speak of responses to various problems users posted about - I decided to purchase the license for it. 

I concur with your comment about itman and SweX!  In addition to the help they provide here, I've seen their respective helpful posts in a couple of other forums as well.  Thanks also for your 'welcome to the forum'! 

 

Reckon I'd better sign-off for the evening.  Again, I really appreciate yours, itman's, SweX's, and Marcos' timely replies and continued follow-up!

 

Cheers!

 

Pete