Jump to content

itman

Most Valued Members
  • Posts

    12,102
  • Joined

  • Last visited

  • Days Won

    319

Everything posted by itman

  1. This indicates to me that epfwlwf.sys is installed and not loading at boot time; but thereafter. I suspect that the associated reg. key "Start" value might be improperly set. Eset on Win 10 doesn't use this driver. So I have shown a screen shot of a like Eset driver associated service reg. key location and Start value setting. If epfwlwf service reg. key Start value is not set to "1", you can do so and see if that resolves the Event 7026 creation. Warning: Only do the above if the Type setting for the reg. key shows a value of "1".
  2. As far as the first three reasons given, it's a fair assumption. In prior endpoint attacks where logs or specific details were provided, RDP was always the attackers entry point into the network. Once in the network, he could easily access any device where Eset was installed. Even if password protected, it could be bypassed via keystroke capture using a keylogger or other credential capture means. Further, there has been at least one forum poster who was been repeatedly attacked via RDP despite being initially warned and advised on how to properly secure it. To set the record straight, the vast majority of ransomware incidents posted in the forum involved business networks. The individual user postings I have seen are from those seeking help or a decrypter and don't even have Eset installed. Or, they naively installed Eset after the ransomware incident in belief it could both remove the ransomware and decrypt their files.
  3. In the Eset GUI if an option selection is blank; i.e. uncheck-marked, it means that option is disabled.
  4. https://www.howtogeek.com/180477/htg-explains-how-do-spammers-get-your-email-address/
  5. Unless the OP replies back with specific details on the staging events of the attack, we will never know what they were. Unfortunately, most will never do so because disclosure of these events could very well cost them their employment.
  6. I assume any one who has posted to this effect is using the pre-released version.
  7. Actually it wasn't mentioned what account/s are used by the password specified in the e-mail. In regards to financial web sites as a rule, web sites of this nature don't use your e-mail address as logon id. They also usually require additional verification after logging on. For web sites where the logon id is your e-mail address and the password indicated in the e-mail is your password, I would change the password on those web sites. Also, I do hope the same password is not used on all the web sites you frequent.
  8. Also to clarify, I expect to see Eset alert displayed, entry created in Detection log showing AMSI detection, and script quarantined. Obviously since the script was never executed, PowerShell output display would not show what if given for the WD detection. Also rather going the AMTSO committee route, Eset could just create like test AMSI PowerShell malware .php script? Since it would only be detected by Eset, the "obsessive" FP concern would be eliminated.
  9. I just asked for a sig. to be added to verify Eset's AMSI detection functionality. No different in concept to existing AMTSO tests. Forget I asked.
  10. Wrong. Refer to the Microsoft article for output displayed from Powershell when detected.
  11. @Marcos, Eset AMSI doesn't detect this Powershell malware script; i.e. Win32/Mptest!amsi, that Microsoft developed to test AMSI functionality as noted below: Ref.: https://docs.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps I assume and hope this is because Eset doesn't have a like sig. detection for this. Please add a sig. for this. Let me know when this is done so I can retest. Note: LiveGrid uploaded something when I was testing so the servers might already have code.
  12. Appears this Symantec utility will remove all traces of Norton on a Mac: https://support.norton.com/sp/en/us/home/current/solutions/kb20080427024142EN Likewise for whatever other AV traces you found, there should be a stand-alone uninstall/cleaner vendor utility for it. Here's an Eset knowledge base article on how to uninstall and reinstall Eset on a Mac: https://support.eset.com/kb3239/?locale=en_US&viewlocale=en_US
  13. You made a wise choice. Glad to have you on board.
  14. I checked the code signing specification on both the Microsoft ELAM and AMSI certificates used in both Eset corresponding entities and they are identical; i.e. 1.3.6.1.5.5.7.3.3. So at this point, I am at a loss as to why Win 10 1903 is blocking loading of the Eset AMSI .dll into PPL processes. What I do know is these code integrity errors for PPL processes were not occurring on Win 10 1809. I "religiously" check that event log for errors. I suggest Eset developers get together with Microsoft as to cause and resolution. -EDIT- One possibility is the Microsoft driver certificate Eset is using to sign its AMSI .dll must be EV status as the corresponding ELAM certificate is.
  15. Actually I misstated in use of Eset's ELAM cert. per se. Eset's needs to add the special PPL keys provided within the ELAM cert. to its existing driver authenticode cert..
  16. My take on this is this cert. can be used to sign .dlls. As you noted previously, Windows is attempting to load the AV amsi.dll into a PPL process. It wouldn't attempt it unless it assumed the .dll was properly signed. https://googleprojectzero.blogspot.com/2018/10/injecting-code-into-windows-protected.html Or alternatively, just use one of the PPL bypasses noted in the article.🙄
  17. OK. Let's assume eamsi.dll has been added to the list of knowndlls, etc.. In any case, it will not be loaded into any PPL process because it is not properly signed to do so. Since Microsoft is increasingly using PPL to protect its processes, Eset's monitoring capability is increasingly being diminished. As any pen-tester "worth his salt" will attest, PPL is somewhat of a joke and multiple bypass POCs exist showing this.
  18. Figured out why Eset attempts to inject its AMSI .dl into svchost.exe PPL instances is failing. Had to dive into my reference materials. To inject code into a PPL process, the code must be signed at WindowsTCB authentication level. This is the highest signing level available. Eset signed the eamsi.dll with its regular driver certificate which is authorized for PP - Authenticode level only. Microsoft only issues one type of WindowsTCB level certificate. That is the certificate Eset used to sign its ELAM driver. Therefore it appears to me, Eset needs to sign the eamsi.dll with this certificate:
  19. Also, beware of the type of attacker you are dealing with if you decide to pay the ransom: https://www.bleepingcomputer.com/forums/t/688649/phobos-ransomware-help-topic-phobos-phoboshta/?p=4823841
  20. Also should not this registry key now be set to 0x2 since Eset's .dll is Microsoft Authenticode signed? It is still set to 0x1 on my ver. 12.2. 23 device: https://docs.microsoft.com/en-us/windows/win32/api/amsi/nn-amsi-iantimalwareprovider
  21. This appears to be Phobos ransomware. Check out this thread: https://www.bleepingcomputer.com/forums/t/699816/ive-attacked-by-ransomware-file-extension-adage/ . There appear to be a few versions that may be decryptable. Otherwise, you're out of luck.
  22. Just upgraded to ver. 12.2.23. Appears all is fixed except injection into Windows Security Center service; i.e. wscsvc. Possibly because it is running as PPL process.
  23. It should be noted that it is not advisable to permanently disable Windows Defender. If there should be an issue with Eset's real-time scanning due to malfunction or other reason, Win 10 will automatically engage Windows Defender real-time protection mode.
  24. To start with, you shouldn't be running both Avast and Eset with their realtime scanners enabled if that is the case. Only one AV scanner should be running with realtime enabled. Refer to this posting: https://forum.avast.com/index.php?topic=181969.0 . Uninstall Avast using its uninstall utility . If you must, reinstall it via "custom" installation and ensure nothing related to Google is check marked during the installation process. Then disable Avast's realtime scanning option and use it as a second opinion scanner. Also Avast's free version is very aggressive in regards to installing undesirable software. So in the free version, I am not sure the above will 100% work. Personally, I would just leave it uninstalled.
×
×
  • Create New...