Jump to content

itman

Most Valued Members
  • Posts

    12,102
  • Joined

  • Last visited

  • Days Won

    319

Everything posted by itman

  1. Proofpoint published an article titled, LCG Kit: Sophisticated builder for Malicious Microsoft Office Documents, which highlights two main points: 1. MS Office malware attacks are becoming increasingly sophisticated. 2. These attacks are now being sold on the dark web as kits enabled those without advanced programming skills to create advanced malware attacks that difficult to detect. https://www.proofpoint.com/us/threat-insight/post/lcg-kit-sophisticated-builder-malicious-microsoft-office-documents It is therefore imperative that organizations employ mitigations to defeat the above attack methods. I posted previously about OLE mitigations. JavaScript should be disabled via in-product Adobe Reader setting, RTF objects should likewise be blocked via MS Office in-product settings. Etc,, etc.
  2. https://support.eset.com/kb5657/?locale=en_US&viewlocale=en_US Also noted in the article is for best compatibility with BP&P, it is recommended that you set your default browser to IE11.
  3. Also, Rapid 3.0 Ransomware uses the .nano extension. So it is imperative the ransomware be positively identified which can be done here: https://id-ransomware.malwarehunterteam.com/
  4. If this is Scarab ransomware, this is a very recent variant: https://twitter.com/demonslay335?lang=en
  5. Microsoft has an article on firewall ports and connections used by Visual Studio: https://docs.microsoft.com/en-us/visualstudio/install/install-and-use-visual-studio-behind-a-firewall-or-proxy-server?view=vs-2017 . One easy solution might be to just switch the Eset firewall to its default allow all outbound connections when performing your debugging activities.
  6. This is a long shot suggestion but the process crashing activity might be related to a known 1809 bug in which desktop notifications are not working after the 1809 upgrade. This would be more the case if you are no longer receiving any Win notifications after the 1809 upgrade. If this is the case, you could try this fix: https://pureinfotech.com/fix-action-center-notifications-not-working-windows-10-1809/ or Google search for other fix suggestions. The missing desktop notifications was really the only issue I encountered after upgrading to 1809, and the above posted link fix worked for me.
  7. Interestingly today when I went to pause Eset protection, I received the normal alert with specification on how long to pause for. So it appears, my posted screen shot is a one-time thing. Anyway, I paused Eset w/o issue. No ShellExperienceHost.exe crash or anything else for that matter. So I can't duplicate the issue on my Win 10 x(64) 1809 build w/EIS 12.0.61 installed. Again, this ver. of Eset was installed on 1803 when I upgraded to 1809. What is a fact is I had multiple failures trying to upgrade to 1809 via Win Updates download. What I finally did was disable Virtualization in my BIOS settings which in turn disabled Core Isolation in 1803. I then did an in-place upgrade to 1809 as previously described. What I can state is as a result of this in-place upgrade, 1809 has been running w/o issue. In fact, it has been the most problem free Win 10 upgrade I have done to date.
  8. In theory, KIS 2019 should have performed better than EIS 12.0.31 in this test because it already has behavioral monitoring; i.e. System Watcher, in place. Note that EIS/NOD32 doesn't have behavioral monitoring until ver. 12.1. As far as no Internet connection, it would have no effect on detection in this test since neither product goes to the Cloud to perform to decision making activities to block or allow the malware process from running.
  9. Just tried to duplicate this on Win 10 x(64) 1809 w/EIS 12.0.31 installed. When I tried to disable Eset, I get what is shown in the below screen shot: Never ever saw anything remotely similar to this on any prior version of Eset I have installed. Also, the date of last threat detection in my Eset corresponding log file is 12/21.
  10. To satisfy "our friend" uninstall KIS 19 so that only WD is running. Make sure its signatures are updated. Leave Controlled Folders and other settings at default. Rerun the same samples and see if anything is encrypted or if Emotet was detected.
  11. This issue is a mystery to me since I am running Win 10 x(64) and EIS 12.0.31 w/o such problem. I suspect this might be related to how the Win 10 1809 upgrade was performed? I performed the upgrade by doing an in-place upgrade from 1803 using a prior 1809 .iso file downloaded using the MediaCreator tool. I would suggest opening an admin level command prompt window and run this command: DISM.exe /Online /Cleanup-image /Restorehealth This will run for a while and will fix any system issues it finds with your 1809 build.
  12. As far as AV lab malware sample selection goes, I believe it is logical to assume some qualification of samples is used. Besides the obvious selection by malware category; e.g. Trojan, ransomware, etc., it can be assumed that prevalence is also a factor. If a lab always used the most prevalent samples, the tests would show almost always show 100% detection by most of the major AV vendors. Obviously, a widely used malware is one that needs immediate detection and mitigation. Additionally if lab test reports showed always 100% detection by all test participants, no one would pay attention to the tests since they already know the outcome. AV vendors would no longer pay to have their products tested and the labs would go out of business. So if is fair to assume that the labs will include a few malware samples that are not widely in use or are isolated geographically. The odds of one being infected by one of these malwares is statistically very low. Assumed is Eset is concentrating on malware with the greatest risk to its customers versus trying to "bag" a lab test with a 100% score. Finally do note that AV labs do not disclose such sample selection criteria as above which really needs to be done.
  13. Could you please elaborate on just what this means? For me, it means Eset didn't fully handle the threat and further user action is required. I asked this same question in another thread and really didn't receive what I consider a full explanation. In my case, it was a web based browser javascript detection; ref. here: https://forum.eset.com/topic/17986-detected-threat-shows-in-red/ . The alert Eset generated states "Threat removed" and "The file has been cleaned." Also there is no required user interaction for the threat. I interpret this to be the threat was fully mitigated by Eset. Is this a correct assumption? If so, why are the threat detections shown in the Detected Threats log as red versus yellow? -EDIT- I always forget that that I have "strict cleaning" enabled for all realtime ThreatSense selections other than for PUA. So it appears that "red" indicates Eset detected and removed the threat without performing any further activities such quarantining it, displaying user threat handling options, etc.. So in essence Eset didn't "handle the threat," it wiped it out instead.
  14. As far as the GrandCrab 5.0.4 ransomware, what was submitted to Hybrid-Analysis was a binary file, 05bfd83bb0d4e7d27bbfc2c057b2b692612de808cc4bca73d9e0ae1d9d479623.js.bin. This leads me to believe the original source of the ransomware was a MS Office Word .doc file employing this for example: https://cloudblogs.microsoft.com/microsoftsecure/2016/06/14/wheres-the-macro-malware-author-are-now-using-ole-embedding-to-deliver-malicious-files/ . So blocking all script child process startup including PowerShell from MS Office executables would have prevented the ransomware from running. Also do note the Microsoft recommended mitigation to block OLE automation in MS Office.
  15. Kudos to you for testing it. I suspected the same originally since not all of Eset's protection mechanisms are fully functional on VT. But again, one is not fully sure of detection without a test. -EDIT- Also appears that a variant detection for this was added 5 hours ago via signature update 18609: https://www.virusradar.com/update/info/18609 .
  16. Without getting into a long discussion on WD's deficiencies, its biggest flaw is that it can be easily disabled/modified by an attacker. Whereas Microsoft has finally tried to mitigate this by sandboxing portions of its kernel/engine process, it remains to be proven through penetration testing it can't be bypassed.
  17. Let me begin with it is almost impossible to stop malicious use of PowerShell by a determined attacker. One might think that creating a HIPS ask rule to monitor the startup of C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe and C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe will detect all PowerShell execution. It won't. Past examples of malicious use of PowerShell include to name few: 1. The attacker downloading the old version of PowerShell, ver. 2.0, used in Win 7 and running it. This version for example, will run fine on Win 10 as long as .Net 2.0 or 3.5 is installed. 2. Downloading the current ver. of PowerShell to any directory, possibly renamed but not necessary to do so, and running it from that location. 3. Executing .Net subassemblies associated with PowerShell via C#, C, etc. program means. The only way to completely stop PowerShell execution would be to employ a security product that can block execution by hash value and then create ask/block rules for hash values associated with every known version of PowerShell. Also, setting PowerShell to Constrained Language mode or using AppContainer which does the same. Eset has a few knowledgebase articles on PowerShell and other script use mitigations: 1. Firewall rules: https://support.eset.com/kb6132/ 2. HIPS rules: https://support.eset.com/kb6119/ These will prevent the most prevalent malicious use of PowerShell. They will not prevent all malicious use of PowerShell.
  18. This one is GrandCrab ransomware. Suspect the javascript payload is heavily obfuscated. Such has been the "Achilles heel" for AV's for some time. If you look at the Behavior section on the detection at VT, it is running PowerShell. One reason among many I have a HIPS rule to monitor all PowerShell execution.
  19. Notable are the AV solutions not detecting it: AVG/Avast, Kaspersky, and Symantec. Microsoft detects as a PUA. The only Next Gen solution detecting it is Cylance and its Unsafe classification is basically one notch above the Suspicious rating confidence-wise. Almost all the other detections are "generic" based indicating the software might have behavior code associated with Trojan activity. It is not unreasonable to assume a hard drive utility associated with monitoring activities would exhibit such behavior.
  20. No problem on my EIS 12.0.31 build and I am located in the U.S..
  21. It also should be noted that Eset's HIPS is not going to throw an alert on suspicious process behavior unless: 1. That behavior has been confirmed with high confidence to be associated with malware. 2. Other process traces exist to associate the behavior with malware such as code snippets and the like. If one wants a solution that absolutely blocks suspicious process behavior regardless of if it is malicious or not, they are better served using a solution such as NoVirus Thanks OSArmor. Whereas this solution works with minimal negative impact in Home based environments, it can reek havoc in corporate environments where many of the processes it blocks are routinely deployed. -EDIT- It should be noted that OSArmor is marketed, it is freeware BTW, as anti-exploit protection to be run in parallel with your existing AV solution. I don't use it because it can conflict with other AV software components. And there have been past conflicts with Eset; namely the HIPS component. It is however, a great source for creating user rules for Eset's HIPS which I have used in the past. Finally, it goes without saying that this type of software is only for advanced users with the OS internals knowledge to effectively respond to the blocked activity it can generate without borking their OS and apps installation/execution activities.
  22. Here's an example of an alert from the new ver. 12.1 HIPS behavior detection:
  23. Good catch. I didn't know that option existed. Also the only way I could enable this is to right click on a shown existing connection and set off the TCP only option there. Thereafter, it applied to all shown connections.
  24. If you want to monitor all UDP connections, use something like Nirsoft's LiveTcpUdp network monitor.
  25. Eset has significantly improved its YARA behavior signatures in ver. 12. As such, most of these types of alerts will be detected by the realtime protection versus the HIPS. Again, Eset originally developed the HIPS for protection of its own internal processes and in default mode, it is still primarily used for that purpose. If you don't think IDS protection adds substantial security benefits, then by all means continue to use the Win Firewall. BTW - you may not be aware the Windows stores its firewall rules in clear text in the registry. As such a hacker with proper access can easily disable or modify them. Ditto for the firewall service itself.
×
×
  • Create New...