jdashn

Can i make that IDS rule based on Remote IP address, instead of Threat name?

I'd like for Eset to still block these attempts, but in this case, for instance, it is a known security scan being done against these computers, from a known address. I know i can add a filter to show all detections from a 'source address' , but i was hoping to exclude all detections from a 'source address' . Again, this likely should be in Remote management, but i really appreicate your assistance so far!

In my detection results, I can see results generated by an internal security scan. While i'm glad that ESET is blocking these threats, they are a known source, and not detections i would like to see when looking at a filtered list of detections. I can see that i can filter by Source Address to show all Detections from a source address -- I'd just like to NOT see all Detections from a source address in a filtered view. Maybe this should have been in remote management? Thanks!

I was wondering if it would be possible to filter detections to exclude showing those from a specific origin? Thank you!

I wonder if something can be done with HIPS rules to prevent the exploit? similar to the ACL (deny System modify on the spooler/drivers folder) workaround that is being suggested?

I just wonder why a virus would be content with making your mouse movements difficult, when it'd be data/creds exfiltration and ransomware that'd typically be the goal. I'd also imagine notifying you of infection via mouse difficulties would be the last thing the attacker would want? I wonder if there is a simpler solution? Occam's razor and all? Maybe you've got a bad mouse driver that only fails when loading up windows vs linux? Would there be software by the hardware manufacturer that might be adjusting bios settings in windows (i know i've seen tools from HP and Dell in enterprise env that'll do that, maybe they're shipping them in home versions now too) for you? Have you attempted updating/reinstalling bios? Have you attempted using different hardware? I know you're looking for an AV based solution, but while you've selected the hammer, i dont think your issue is a nail. Jdashn

I'd personally say that the weaponized portion is the crypto-currency that allows for 'Trace-Free' payment. If law enforcement could 'follow the money' there would at least be some risk when that person tried to redeem the giftcard or money order, etc -- with crypto there is no risk of being caught when you collect your funds so ransomware can flourish. Money mules aren't caught, they don't snitch up the line, so ransomware gangs and nation-states can increase the size of their bankrolls allowing them to purchase and find more and more (and more sophisticated) zero days and other hacks (again using untraceable crypto currency) . If crypto didn't represent a potentially HUGE investment opportunity for the wealthy (and more people realized it's direct correlation to ransomware), it'd already be dismantled and illegal. I wonder what percentage of Crypto currency was originally purchased as payment for ransom, and how that has effected it's price, and how many people were made millionaires or more on the backs of that ransom (purchases of crypto result in that crypto's price rising)?

Awesome!! thanks a ton to both of you for your quick replies!

As of this morning i'm getting a lot of alerts across the orginization for: hxxp://ocsp.int-x3.letsencrypt.org/MFMwUTBPME0wSzAJBgUrDgMCGgUABBR+5mrncpqz/PiiIGRsFqEtYHEIXQQUqEpqYwR93brm0Tm3pkVl7/Oo7KECEgRY8NzrWAjZ4J4grl19QqsePQ= For each alert the last bit of the address changes, but this part is the same: hxxp://ocsp.int-x3.letsencrypt.org/MFMwUTBPME0wSzAJBgUrDgMCGgUABBR+5mrncpqz/PiiIGRsFqEtYHEIXQQUqEpqYwR93brm0Tm3pkVl7/Oo7KECEg They all also have a target address of : 104.91.166.211 Just wondering if there is more information on this, what might be causing it, if this is an indicator of a primary infection, etc. Thank you!! Jdashn

Just to be clear, it's still only Ubuntu and Redhat you support for Version 7 right? Are there plans to expand this or should we look for another solution for AV on Linux? (Fedora, SuSe, etc) Thanks!!

Maybe you misunderstood my comment? I said that i wished ESET had our backs on this like they did for eternal blue. Not that the vulnerability is similar, obviously SMB1 is different from this CryptoAPI vulnerability, also different from Apache struts for that matter. All three have been patched to varying degrees by their respective software vendors, all three exploit very different things. I was asking if Eset would block and alert on attempts to exploit the CryptoAPI Vulnerability (as they do with attempts to exploit Eternalblue, apache struts, etc, etc) mostly so i can tell our decision makers that not only are we patched, and our checkpoint firewall will block the attacks, but ESET has our backs as well. If not and our only layers of defense are our firewall (it will alert at attempts of cryptoapi spoofing), and the patching of windows (there is also an event triggered on exploit attempt here), so be it - I was just asking if we had a 3rd layer of protection in ESET on this particular vulnerability. Is this something you know the answer to @itman or is this a better question for @Marcos ? Thanks!

Would have hoped i could tell our decision makers that not only have we patched but Eset would also have our backs on this (similar to eternalblue, etc). Seems this is not the case judging from @Marcos 's comment? Just want to be sure, would hate to sell ESET short.

I am guessing there are parts of what is in pre-release that are more complex to test, and could have further reaching impact than the exclusion of a port for scanning. Which would be why they've not released this 'fix' as it's a part of a larger update package, that is still being tested. I wonder, though, if this piece could be released to the general codebase, before the testing on the rest of the 'update' is completed. I would guess that you're just going to be doing the exclusion of the ports for scanning on the back end, so pretty simple to test and know is working. Is this maybe one of those cases where Dev and Testing don't know that this part of the update is turning away home use customers, and causing a lot of consternation among the client base (likely a TON more than what you see here, we all know in support you only ever get 1% of complaints via forums, or email -- easier to buy a new product than complain). Heck maybe if Dev and Testing knew they'd be able to put this available for release, but I can't see that with a fully functional forum like this that the moderators here aren't regularly working with dev/test and letting them know of the daily buzz on the forums (heck a few might even have accounts and read?). I'd imagine that releasing a portion of an Update is relatively simple, seeing as how everything has been made more modular with eset, but honestly I dont know how development works here, could be that to uncouple this update from others would mean far more work and delays in other areas. Could be that a large enterprise customer is asking for a feature, and that has been fast-tracked, and other projects have to wait. I guess really what i'm saying is that who knows why it's taking so long, yes it could be that they're waiting to click that button for no 'good reason' aside from 'thats how we do it' .. or it's a lot more complex than the minimal information that we get via the forums would lead us to believe.

And just to be sure i'm not missing something, there is no way to install Eset AV or Security on a Windows Server OS? No eset web control possible on a windows Server OS, right? Sorry again to pester! Thank you, Jdashn

Does ESET have any suggested applications that would provide this service? (guessing not?) Or plans to add the webcontrol feature to the Windows server protection applications sometime soon? (If not could this be put forward as a feature request?) Thanks!! Jdashn