jpom18

Okay, I understand now. Thank you for the explanation. That said I can confirm that your suggestion to exclude the package along with limiting to the URL does not work. I currently have the following exclusion: and when launching the game that was just excluded I see: and in the logs: It doesn't really matter at this point since it is no longer detected unless set to aggressive so just FYI. Thank you

Interesting, I'm not sure I like the idea of the detection being excluded so that it will never be triggered but again I was not able to find anything on the .H variant of JS/Agent so I'm not sure exactly what it is. Is there a way I am able to reset this now so that it would be detected again, just for testing purposes? I would be curious to try your solution posted above, originally your posts said to add "https://cdn-*-prod.pogospike.com/*" to the exclusion and my assumption was that the wildcard at the end would cover any part of the address that came after. However I can confirm that did not work and your post above now says to add "https://cdn-*-prod.pogospike.com/*/src/project.js" and I would be curious to see if that works. Does the /* not include everything that comes after? I have not had to use wildcards in Eset before so maybe there is a limitation to them that I am unaware of. Thank you again.

Thank you for your assistance. So just to clarify, you said the sensativity was changed to aggressive but wouldn't that make false positives more likely (that's what it says in the settings). Did you mean that it was changed to Cautious (which is the option down from balanced which appears to be the default)? If so was this done on a global basis or just for the pogo website? My settings still show as balanced detection but I can confirm that the games load now without issue or requiring exclusions. Lastly does Eset contain a way that users can set detection sensitivity for specific sites? I did look but couldn't find anything so that may be something that can only be done by Eset (or maybe can't be done at all). Thank you again.

I'm not sure what you mean by the above. As far as I can tell the JS/AGENT.* are typically trojan downloaders, I can't find anything on the .H variant. So in your above "solution" are you suggesting that this specific type of activity that contains the .H variant will still be detected on other sites. In my understanding if JS/Agent.H is added to a blanket exclusion then any site that triggers detection JS/Agent.H will be ignored, any other variant (i.e. JS/Agent.D) will be detected. As stated I can't find anything on .H so possibly Eset is just using that as a generic name for some sort of suspicious traffic but the fact remains that if any other site triggers that same activity and JS/Agent.H has been added to the exclusion list it will be ignored and allowed, this does not seem like a viable option unless I am misunderstanding something. The second option is not ideal either since as you state excluding the site from content filtering could potentially allow traffic that could be truly malicious. Barring a definition update that eliminates this, the best option would be to allow this specific activity from that specific site, and I can't understand why this would not work on Eset. Being able to do this would be the ideal balance of security and usability as only this "suspicious" traffic would only be allowed for the pogo website, if something else was seen as suspicious on the pogo site it would still be detected and if this particular traffic were seen on any other website it would also still be detected. Is it 100%, no, any exclusion opens a potential risk but it is far better then the other options provided and only requires a single exclusion so it is easy to setup. The only other viable option I can see is excluding each game by hash, so create an exclusion based on hash value instead of detection name. This will prevent the issue with each game added to the exclusion list but will still allow detection on any other site or even on the pogo site since the hash will change if the game is changed. This would be the most secure option however the downside of course is that every game has a different hash value so you will need to create an exclusion for each individual game and if the game is updated and the hash changes you will need to create a new exclusion. This would be the most secure option but is also the most work especially for those that may not be familiar with the program or have strong computer skills. I have a hard time believing (although it is not impossible) that the Pogo site has been compromised and is attempting to drop a trojan on users systems, it is more likely that Pogo has updated something on their site and this is now being detected as a false positive. As an False Positive it should be on Eset to correct this issue without users having to expose their system more then required, unless Eset believes that Pogo is compromised and attempting to drop a trojan on everybody's system. All in all it looks like it is becoming the typical blame game, there is a thread on EA's forum about it with EA blaming ESET and ESET doesn't appear to be interested in offering any valid fixes for it.

I have multiple computers having the same issue. If a blanket exclusion is created just for JS/Packed.Agent.H then it works however this is not ideal since it applies the exclusion to all apps and traffic. Adding any other criteria appears to break the exclusion, for example adding the object or any variation (i.e. using wild cards) into the path field stops the exclusion from working. I have tried https://cdn-*-prod.pogospike.com/*, https://*.pogospike.com/*, and *.pogospike.com/*. One thing I did notice is that if you add the blanket exclusion first, then test, then go back and add the additional criteria (i.e. object) the game will still work for a time but after closing the window and leaving for a bit when you come back it will block with the same issue again. It does appear that adding an exclusion for the hash works, from what I've been able to tell, but every game has a different hash value (again as far as I can tell) so that's not really viable. ESET really needs to correct this or provide a way to add an exception based on the site (a way that actually works).