Jump to content

itman

Most Valued Members
  • Content Count

    4,957
  • Joined

  • Last visited

  • Days Won

    151

Kudos

  1. Upvote
    itman received kudos from fabioquadros_ in ESET failed to protect against a Ransomware   
    This is far from the first ransomware employing XOR techniques. Here are a few other examples:
    https://www.rsa.com/en-us/blog/2017-05/how-ransomware-uses-tmp-files-and-the-temp-folder
    https://www.cybereason.com/blog/the-sodinokibi-ransomware-attack
    https://blog.malwarebytes.com/threat-analysis/2018/04/lockcrypt-ransomware/
    So my guess is how it was deployed is new and this is why it wasn't detected by a number of solutions.
    This is a perfect example of why everyone needs to backup their User files and keep them off-line; or the online backup location locked down access-wise.
    Also another strong case for use of the anti-ransomware solutions like AppCheck or Checkpoint's solution. These use "bait" files to detect file modification and therefore are not dependant upon detecting ransomware behavior methods.
  2. Upvote
    itman received kudos from fabioquadros_ in ESET failed to protect against a Ransomware   
    Of note is none of the Next Gen solutions on VT are detecting this. This would be a clear indication that behavior employed by this ransomware is new and their ML engines haven't been tuned to detect it.
  3. Upvote
    itman received kudos from fabioquadros_ in ESET failed to protect against a Ransomware   
    More details on this ransomware is here: https://translate.google.ru/translate?hl=ru&tab=wT&sl=ru&tl=en&u=https%3A%2F%2Fid-ransomware.blogspot.com%2F2019%2F09%2Fgoransom-poc-ransomware.html
    It is using XOR for encryption activities. Suspect this is why it is "flying under the radar" of security solutions monitoring for specific crypto API's.
  4. Upvote
    itman received kudos from SeriousHoax in ESET failed to protect against a Ransomware   
    This is far from the first ransomware employing XOR techniques. Here are a few other examples:
    https://www.rsa.com/en-us/blog/2017-05/how-ransomware-uses-tmp-files-and-the-temp-folder
    https://www.cybereason.com/blog/the-sodinokibi-ransomware-attack
    https://blog.malwarebytes.com/threat-analysis/2018/04/lockcrypt-ransomware/
    So my guess is how it was deployed is new and this is why it wasn't detected by a number of solutions.
    This is a perfect example of why everyone needs to backup their User files and keep them off-line; or the online backup location locked down access-wise.
    Also another strong case for use of the anti-ransomware solutions like AppCheck or Checkpoint's solution. These use "bait" files to detect file modification and therefore are not dependant upon detecting ransomware behavior methods.
  5. Upvote
    itman received kudos from SeriousHoax in ESET failed to protect against a Ransomware   
    No need for the ASR mitigation.
    Assumed is WD's cloud sandbox has Controlled Folders enabled. Unknown process performing repeated file modification activities to same is enough to flag the unknown process. This is why MS had a sig. for it so quickly.
  6. Upvote
    itman received kudos from SeriousHoax in ESET failed to protect against a Ransomware   
    Of note is none of the Next Gen solutions on VT are detecting this. This would be a clear indication that behavior employed by this ransomware is new and their ML engines haven't been tuned to detect it.
  7. Upvote
    itman received kudos from SeriousHoax in ESET failed to protect against a Ransomware   
    More details on this ransomware is here: https://translate.google.ru/translate?hl=ru&tab=wT&sl=ru&tl=en&u=https%3A%2F%2Fid-ransomware.blogspot.com%2F2019%2F09%2Fgoransom-poc-ransomware.html
    It is using XOR for encryption activities. Suspect this is why it is "flying under the radar" of security solutions monitoring for specific crypto API's.
  8. Upvote
    itman received kudos from hamidhajjialiakbar137@gmai in Firewall: An application has been modified and is now trying to communicate with the network.   
    If its a trusted app and one you know that was recently updated, it's OK to keep existing permissive rules. For example and most frequently, equi.exe, that was replaced as part of the ver. 12.2.29 upgrade.
  9. Upvote
    itman received kudos from SeriousHoax in Controlled Folder feature   
    Another thing about WD is that it can be bypassed as noted here: https://www.bleepingcomputer.com/news/security/gootkit-malware-bypasses-windows-defender-by-setting-path-exclusions/
    My gut is telling me that even if Win 10 1903 WD self-protection was enabled, the registry mod implemented by this WMI event would have bypassed it. Perhaps the ASR mitigation to prevent WMI events from being created would have helped. But ASR mitigations would only be deployed by advanced users and in themselves, can cause operational issues in that they a absolutely block the activity.
  10. Upvote
    itman received kudos from Pete12 in update from 12.2.23 to 12.2.29   
    I was using RS6; i.e. Win 10 1903, with ver. 12.2.23 installed without these new issues. As such, the problem is the new certificate Eset is using.
  11. Upvote
    itman received kudos from SeriousHoax in update from 12.2.23 to 12.2.29   
    It appears to me that Eset is doing some type of "kluge" processing where it fools Win 10 into thinking no other AV/firewall is installed at boot time. That is what is causing the event log entries. My guess is Eset is not loading its ELAM driver. This will cause later Win 10 versions to startup Windows Defender and run it in parallel with the third party AV solution. Or the OS in the mean time seeing that no third party AV is installed, starts up the Win firewall front-end plus Windows Defender.
    Eset then later registers itself with Windows Security Center and all is well in that regard. Once the Eset registration with Security Center completes, then the OS switches over to recognizing Eset as the firewall plus AV real-time provider and terminates the Windows Defender engine process.
    The problem with the above is while Windows Defender is active, it is performing activities like trying to update its definitions and God only knows what else. There is also the issue of malware that runs at start-up "sneaking through" due to the fact two real-time AV solutions are running. What happens if WD detects the malware first but is not fully functional?
    Eset really needs to do its initialization with Security Center properly as was done with ver. 12.2.23 and prior versions.
  12. Upvote
    itman received kudos from fabioquadros_ in Controlled Folder feature   
    Continuing the above posted thought, Eset's Firewall and HIPS both have learning, policy, and interactive modes. It is far more likely that an end user could bork his system processing by improperly employing those features than by applying optional aggressive reputational, anti-exec whitelisting, etc. options. So I can only assume Eset just doesn't want to allocate the resources with resultant cost to provide the more aggressive mitigation options a number of its customers want.
  13. Upvote
    itman received kudos from ECELeader in Ransomware   
    One final comment in regards to Live Grid's performance in this incident.
    Refer back in this thread to the posted Live Grid screen shot showing ransom.exe running. Note the red color. What does that mean? Per Eset online v12 help:
    Hum ........ It certainly appears Eset's front-end heuristic scanning did its job.
    So why can't Eset offer an option to be alerted to "risky" processes pre-execution? It most certainly appears to be the correct and logical action to take. For me, I can only conclude the following:
    1. Eset has such little faith in Live Grid's reputational analysis that it doesn't trust it for user alert purposes. In this case, get rid of the feature and just perform any submission activities in the background.
    2. Eset's avoidance of a false positive detection has reached the level that it is jeopardizing overall system security.
  14. Upvote
    itman received kudos from ECELeader in Are You Still Not Convinced RDP Is A Major Vulnerability?   
    Kaspersky just released their 2018 Malware Incident Report today. Most notable is the following:
    https://securelist.com/incident-response-analytics-report-2018/92732/
    Also:
    https://www.infosecurity-magazine.com/news/the-great-big-ransomware-revival/
  15. Upvote
    itman received kudos from fabioquadros_ in Ransomware   
    Agreed. But if Eset hueristics detects a Live Grid red status risky unknown process, it should throw a suspicious alert and let the user make the decision. Again this should be an advanced Live Grid option with the disclaimer that activating it could lead to a FP detection. Also, it is highly unlikely Live Grid is going to classify a Win base OS process as risky.
    Really, this isn't "rocket science."
  16. Upvote
    itman received kudos from fabioquadros_ in Ransomware   
    This is the problem. I would gladly switch to Endpoint. However, I don't want to buy 5 licenses which it appears is Eset's purchase minimum for the product. Eset should have a single license purchase option with a higher cost which would be perfectly acceptable.
    Another suggestion is Eset offer an "advanced" Internet Security version which in effect would be a "re-bagged" Endpoint version.
  17. Upvote
    itman received kudos from fabioquadros_ in Ransomware   
    Now we are getting "at the meat" of the issue.
    How about an ecmds initiated "aggressive" FP setting? This setting would do globally what you stated; loosen existing anti-FP detection. By keeping the setting out of the Eset GUI, it would prevent Eset "experimental" users from enabling it and subsequently complaining Eset is throwing alerts on some garbage they are trying to install.
    At least, Eset should do something in this area to prevent long time users like myself from moving on to security solutions that have such capability.
  18. Upvote
    itman received kudos from fabioquadros_ in Ransomware   
    Since the above Eset's requested enhancements to Live Grid falls into the category of "wishful thinking," let's talk about a free solution built into Win 10 that has such capability. That is Windows Defender's Advanced Surface Reduction; i.e. ASR mitigations:
    Since we are on that topic, let's list all the ASR mitigations available:
    https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/attack-surface-reduction
  19. Upvote
    itman received kudos from fabioquadros_ in Ransomware   
    Some additional comments on how Live Grid should be configured by Eset.
    1. The risky status alert option would be an "Advanced option" setting for the existing Live Grid setting in Eset's GUI. It would be disabled by default. Hence and God forbid, Eset gets "dinged" on an AV lab test because of it.
    2. It is assumed that Eset already has in place criteria for handling of known assumed safe apps such as OS apps in their respective directories, etc.. I will state that I have never seen any process set to "Red" status in viewing Live Grid's status screen. As such, I am assuming the "Red" status is reserved for unknown reputation apps performing questionable system modification activities.
    3. The alert would display additional descriptive information such as signing status, publisher, creation date, directory location, etc.
    As I see it, the most that could happen in blocking the process from running would be some app installation or some process .exe you purposely downloaded is blocked/borked. App installers can always be rerun.
    The above would allow one to submit the process to VirusTotal for additional verification or Hybrid-Analysis for a detailed sandbox analysis. Win 10 1903 users could additionally run the process in the  Windows sandbox.
    Unfortunately, these Live Grid operational modifications have been suggested by me and others in the past and have "fallen on deaf ears" as far as Eset is concerned. After all, Eset always knows best when it comes to security features.
  20. Upvote
    itman received kudos from fabioquadros_ in Ransomware   
    One final comment in regards to Live Grid's performance in this incident.
    Refer back in this thread to the posted Live Grid screen shot showing ransom.exe running. Note the red color. What does that mean? Per Eset online v12 help:
    Hum ........ It certainly appears Eset's front-end heuristic scanning did its job.
    So why can't Eset offer an option to be alerted to "risky" processes pre-execution? It most certainly appears to be the correct and logical action to take. For me, I can only conclude the following:
    1. Eset has such little faith in Live Grid's reputational analysis that it doesn't trust it for user alert purposes. In this case, get rid of the feature and just perform any submission activities in the background.
    2. Eset's avoidance of a false positive detection has reached the level that it is jeopardizing overall system security.
  21. Upvote
    itman received kudos from fabioquadros_ in Ransomware   
    Most of the dedicated anti-ransomware solutions do the same. BTW - Checkpoint has an excellent anti-ransomware solution that costs around $15 USD w/yearly subscription.
    I believe Kaspersky also works the same way. In addition if its System Watcher feature is enabled, it will use a snapshot to restore any files encrypted prior to its ransomware detection mechanism kicking in.
    As far as Eset goes, your best solution is to create HIPS rules to monitor file modification activities against any of your User folders. This really shouldn't be too much of an inconvenience for the average user since those directories are not updated that frequently in normal daily use. For business environments, process exceptions would have to be created increasing the risk of ramsonware succeeding due to malware modification of those processes.
  22. Upvote
    itman received kudos from SeriousHoax in Ransomware   
    Some additional comments on how Live Grid should be configured by Eset.
    1. The risky status alert option would be an "Advanced option" setting for the existing Live Grid setting in Eset's GUI. It would be disabled by default. Hence and God forbid, Eset gets "dinged" on an AV lab test because of it.
    2. It is assumed that Eset already has in place criteria for handling of known assumed safe apps such as OS apps in their respective directories, etc.. I will state that I have never seen any process set to "Red" status in viewing Live Grid's status screen. As such, I am assuming the "Red" status is reserved for unknown reputation apps performing questionable system modification activities.
    3. The alert would display additional descriptive information such as signing status, publisher, creation date, directory location, etc.
    As I see it, the most that could happen in blocking the process from running would be some app installation or some process .exe you purposely downloaded is blocked/borked. App installers can always be rerun.
    The above would allow one to submit the process to VirusTotal for additional verification or Hybrid-Analysis for a detailed sandbox analysis. Win 10 1903 users could additionally run the process in the  Windows sandbox.
    Unfortunately, these Live Grid operational modifications have been suggested by me and others in the past and have "fallen on deaf ears" as far as Eset is concerned. After all, Eset always knows best when it comes to security features.
  23. Upvote
    itman received kudos from SeriousHoax in Ransomware   
    One final comment in regards to Live Grid's performance in this incident.
    Refer back in this thread to the posted Live Grid screen shot showing ransom.exe running. Note the red color. What does that mean? Per Eset online v12 help:
    Hum ........ It certainly appears Eset's front-end heuristic scanning did its job.
    So why can't Eset offer an option to be alerted to "risky" processes pre-execution? It most certainly appears to be the correct and logical action to take. For me, I can only conclude the following:
    1. Eset has such little faith in Live Grid's reputational analysis that it doesn't trust it for user alert purposes. In this case, get rid of the feature and just perform any submission activities in the background.
    2. Eset's avoidance of a false positive detection has reached the level that it is jeopardizing overall system security.
  24. Upvote
    itman received kudos from peteyt in Ransomware   
    Also on Win 10, native SmartScreen goes much farther in that it will block (default setting) or warn of any executable not downloaded from the Win Store. Problem is I don't fully trust it in regards to stealthy malware code execution such as reverse shell and the like. -EDIT- Also another major issue with native SmartScreen is Microsoft in its "infinite dis-wisdom" runs it as a medium integrity process. As such, it can be easily suspended by malware to run its code.
  25. Upvote
    itman received kudos from L0ckJaw in Ransomware   
    This is the problem. I would gladly switch to Endpoint. However, I don't want to buy 5 licenses which it appears is Eset's purchase minimum for the product. Eset should have a single license purchase option with a higher cost which would be perfectly acceptable.
    Another suggestion is Eset offer an "advanced" Internet Security version which in effect would be a "re-bagged" Endpoint version.
×
×
  • Create New...