Changed LiveGrid Behavior Under Ver. 11.1.42

[itman 1,806]

To begin with, I have all LiveGrid upload settings disabled.

What I am observing is LiveGrid upload/download activity upon close of a browser session to IP address 91.228.166.150 for example. If Eset is now scanning browser cache,  temp file, etc. data in the cloud, that is fine. However, they should publicly state they are now doing so.

[Marcos 5,462]

It's most likely just a coincidence. If you enable logging of submitted files, do you see some files submitted at that time? I'd suggest the following:
- enable diagnostic logging verbosity
- enable advanced firewall logging
- reproduce the above mentioned behavior
- disable logging and also change the logging verbosity back to standard
- collect logs with ELC.

When done, provide me with the generated archive.

[itman 1,806]

Enabled LiveGrid logging and nothing shown in the Event log.

Below is a TCPView screen shot what I am observing. Also packet count, 6, and byte count, in the 3K range, are what I am observing. Will get the logs to you shortly.

[Marcos 5,462]

Could you try it with Banking and payment protection disabled?

[itman 1,806]

18 minutes ago, Marcos said:

Could you try it with Banking and payment protection disabled?

Disabling OPP has no effect.

Also, I was wrong about it being related to browser use. Connections are occurring long after browser has been closed as shown in the below screen shot. They are also quite frequent. If this is blacklist updating, it is occurring almost continuously:

 

 

[itman 1,806]

I PM'd the ECL log to you.

[itman 1,806]

Also tsmxx.eset.com inbound/outbound connections are being made when I close the browser. Also when the browser is open. These are for LiveGrid statistical, etc. uploads. As I posted previously, I have that disabled. So something clearly has changed with LiveGrid network activity. Screen shot below is with browser open.

Edited March 22, 2018 by itman

[itman 1,806]

Here's what is going on. Every 1 - 2 mins., ekrn.exe is establishing a quick connect/disconnect to Eset servers. It almost appears to me it is performing a network connectivity check similar to what Windows does at boot time.

[cvvorous 4]

might just be a keepalive. wireshark would be more helpful, tbh.

[itman 1,806]

@Marcos where do we stand on this?

At least 12 ports are tied up supporting what appears to be almost continuous LiveGrid blacklist and possibly signature updating activity. Whereas the increased updating activity is a much wanted improvement, the method employed needs improvement.

[Marcos 5,462]

I'll check with developers if we could prepare a logging version of the AV/AS module for you that would help us find out communication details.

[itman 1,806]

19 minutes ago, Marcos said:

I'll check with developers if we could prepare a logging version of the AV/AS module for you that would help us find out communication details.

I am not the only user observing this activity, so this is not unique to my installation.

[cvvorous 4]

my client fires the same 6 requests over and over, with different values based on date/time. afaict, this telemetry hasn't changed since 2013 or so (if you search for chsquery you'll find weirdos posting stuff about ESET participating in NSA/CIA SIGINT ops, lol)

 

POST https://ts.eset.com:443/query/chsquery.php HTTP/1.1
Host: ts.eset.com:443
Content-Type: multipart/form-data; boundary=------------------------3kMBisMe5ab5274
Content-Length: 3021
Connection: Keep-Alive

--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="chc_pversion"
Content-Transfer-Encoding: 8bit

6
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="chc_sversion"
Content-Transfer-Encoding: 8bit

88
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="chc_gmdatetime"
Content-Transfer-Encoding: 8bit

2018-03-23 16:11:56
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="chc_datetime"
Content-Transfer-Encoding: 8bit

2018-03-23 10:11:56
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="datatype"
Content-Transfer-Encoding: 8bit

�f
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="key"
Content-Transfer-Encoding: 8bit

<redact>
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="priority"
Content-Transfer-Encoding: 8bit

�
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="hitcount"
Content-Transfer-Encoding: 8bit

�
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="firsthitdate"
Content-Transfer-Encoding: 8bit

�gT�[U�L^^ ZV[BS�G_
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="lasthitdate"
Content-Transfer-Encoding: 8bit

�gT�[U�L^^ ZV[BS�G_
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="firsthitdatedelta"
Content-Transfer-Encoding: 8bit

�fQ�O
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="attributes"
Content-Transfer-Encoding: 8bit

<redacted encoded data>
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="sessionid"
Content-Transfer-Encoding: 8bit

�gS�C]�U^
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="file"; filename="file"
Content-Type: application/octet-stream

<redact encoded data>
--------------------------3kMBisMe5ab5274
Content-Disposition: form-data; name="chc_valid"
Content-Transfer-Encoding: 8bit

1
--------------------------3kMBisMe5ab5274--

 

Edited March 23, 2018 by cvvorous

[itman 1,806]

I have identified the problem. I don't know what to fully make of it, so I will just post what I have found so far.

I first did something I should have done yesterday, That is use netstat to identify the processes involved in this constant LiveGrid network activity. Below is a screen shot of this activity:

The Win service RpcSS is basically DCOM/COM. Appears Eset has modified ekrn.exe as such?

Below is Microsoft's write up on ports used by RpcSs:

Quote

System service name: RpcSs

Application protocol Protocol Ports
 
RPC TCP 135
RPC over HTTPS TCP 593
NetBIOS Datagram Service UDP 138
NetBIOS Name Resolution UDP 137
NetBIOS Session Service TCP 139
SMB TCP 445

https://support.microsoft.com/en-us/help/832017/service-overview-and-network-port-requirements-for-windows

As far as I am aware of RpcSs network traffic is restricted to the local network. Why Eset is using it to perform Internet traffic is beyond me. And if HTTPS traffic is deployed, it should be using port 593. Something is very wrong here I believe.

Edited March 23, 2018 by itman

[itman 1,806]

One other comment about this constant upload/download activity by ekrn.exe. It has nothing to do with LiveGrid. I disabled LiveGrid and the activity persisted.

Edited March 23, 2018 by itman

[itman 1,806]

I finally figured out what is going on. I had to use a different network traffic monitor to do so. It is both interesting and unique I believe.

For starters, only one Internet connection is being established by ekrn.exe and for all practical purposes, it is continuous; connection intervals are around 30 secs. or less. Eset is using its hidden localhost proxy server to implement in effect, a multi-thread network connection. The multiple ports allocated are to the hidden proxy server. I believe half the ports are allocated to packet send activities and half for packet receive activities. This allows for keeping the Internet connection used by ekrm.exe open for only a very short interval; a couple of secs.. 

 

Edited March 25, 2018 by itman

[itman 1,806]

On ‎3‎/‎23‎/‎2018 at 12:18 PM, cvvorous said:

you'll find weirdos posting stuff about ESET participating in NSA/CIA SIGINT ops

http://www.dslreports.com/forum/r28632731-warning 

Actually, this nonsense relates back to the Kaspersky "foo bar" incident in 2015: https://www.forbes.com/sites/thomasbrewster/2015/06/22/foreign-av-companies-targeted-by-nsa/#53cf84a55b8c

[itman 1,806]

I also came across an older Eset forum posting that fully explains this activity. In corp. installations that deploy an Apache server, it monitors for suspicious hidden local proxy server activity. Appears it is triggered when byte transfer count exceeds a certain threshold. Eset as a result modified its internal byte transfer rate for its proxy server to remain below this threshold by splitting the transfer rate to multiple ports.

The question now is why am I observing this activity whereas in prior vers. I did not? Does this mean, we finally have the same ver. deployed to Eset Endpoint? Do I finally have HIPS file wildcard capability I have been requesting for years?

Edited March 25, 2018 by itman

[persian-boy 22]

I also have the same issue! telemetry in new version increased for no reason.

[itman 1,806]

1 hour ago, persian-boy said:

I also have the same issue! telemetry in new version increased for no reason.

I wouldn't be concerned about it. @Marcos explained in another thread Eset's pico updates are being streamed this way.

Hopefully, this will eliminate past LiveGrid update "snafu's."

Edited March 27, 2018 by itman

[itman 1,806]

I want to inform that this continuous pico updating business is "leaking" ports. It appears each day, more ports are being tied up by the processing. After updating to ver. 11.1.42.1, currently 40 ports are tied up. That is way to high of an allocation in my opinion.

[cyberhash 201]

@itman I can only assume that these port WAIT's which you describe as "leaking" have increased in frequency with the latest 11.1.42 update are down to 

Improved: More frequent update checks for detection engine and modules (part of the 11.1.42 release notes/changelog)




 

[itman 1,806]

11 minutes ago, cyberhash said:

I can only assume that these port WAIT's which you describe as "leaking" have increased in frequency with the latest 11.1.42 update are down to 

I well realize that.

My point was that when 11.1.42 was initially installed, 12 ports were tied up. I now observe at times over 40 ports being allocated. At this rate, soon all my ports will be tied up by Eset pico updating and I will not be able to use the Internet.

[cyberhash 201]

2 minutes ago, itman said:

My point was that when 11.1.42 was initially installed, 12 ports were tied up. I now observe at times over 40 ports being allocated. At this rate, soon all my ports will be tied up by Eset pico updating and I will not be able to use the Internet.

I have the same amount of (internal) waiting ports tied up as yourself , but they eventually kill themself and open up new waiting ports (of the same quantity on different port numbers). I can only assume that this is only to increase the reliability of updates. I have been watching this myself for the past few months and it does not appear to affect (My Internet) connection.

If it does, i will be back here complaining along with you @itman

[itman 1,806]

I will also add that as far as retail vers. of Eset go, there is no reason to allocate multiple ports to this processing.

As I posted previously, these ports are being allocated to Eset's hidden localhost proxy server. The actual connection to Eset's LiveGrid update servers is being made via a single port 443 connection. Eset then splits the incoming connection from port 443 to multiple ports allocated to 127.0.0.x. Again as noted previously, the only reason for doing such port splitting activities is to get around some local server, namely Apache, security protections that monitor for the existence of hidden proxy servers. They do so by monitoring byte count being transferred back and forth from the hidden proxy server. If that byte count exceeds 4K bytes or so, Apache will throw and alert and shutdown the hidden proxy server.