Jump to content

jdashn

Members
  • Posts

    105
  • Joined

  • Last visited

  • Days Won

    1

jdashn last won the day on December 1 2020

jdashn had the most liked content!

About jdashn

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    USA

Recent Profile Visitors

1,879 profile views
  1. 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?
  2. 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
  3. 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)?
  4. Awesome!! thanks a ton to both of you for your quick replies!
  5. 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
  6. 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!!
  7. 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!
  8. 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.
  9. 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.
  10. 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
  11. 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
  12. Sorry to be a pain, but i want to be sure i understand before applying this to (for example) a domain controller. If i implement the logging as you've got the example above: If I browse to a website that ESET in the past has found malware on, and blocks for me, this would be allowed If i browse to a website that has active malware on it, eset should find, and block this (given that it's something that it knows about and regularly blocks anyway, IE not new). So i'm guessing that if i want to have a secure domain controller (one that would be more likely to block a website that could be malicious), and log web activity that happens on that domain controller you're suggesting that i may want to look to another way of logging web activity outside of ESET?
  13. Awesome! Thanks for the warning, and the help!! I had guessed that putting * in under allowed sites, could start logging, but was unsure if that would then mean that i was allowing malicious sites? I'm guessing no? Thanks again!!! Jdashn
  14. @Marcos Thanks a ton for the reply!! These would be application servers, DB servers, Domain controllers - none of which should actually be regularly using the web. So web traffic should be in 0 pages per day range. Not a machine people SHOULD be using for web activity, so i'd guess the logs would actually be very small? (or would this be logging more than i'm thinking?) I dont want to fully block, as you never know what emergency would crop up - But obviously i'd like to monitor and make sure that we're alerted to those situations, and can ask for justification (lets say if we saw someone browsing their hotmail account on a domain controller). Even if the data would just get logged locally, and i could grab the logs regularly and parse them outside of ESMC, i was just thinking that ESET would be the best tool for this job, since it should be monitoring all that traffic anyway. Also, this is in relation to Eset File Security (v7.X) , i think that 'Web Control' rules are only available in the 'Endpoint' products, not the server products-- unless i'm missing something? Thanks Jdashn
  15. I feel like i've seen the answer to this question in the past, but have had no luck in finding the answers. Is there a way in ESET File Security to log all web history? (Blocked + Allowed?) Unfortunately i've got a server where a regular user has Administrative access and i'd like to see if i can utilize ESET to log all web traffic on this machine. Thanks!! Jdashn
×
×
  • Create New...