Jump to content

itman

Most Valued Members
  • Posts

    12,197
  • Joined

  • Last visited

  • Days Won

    321

Posts posted by itman

  1. You might want to review this article on how Emotet is spread: https://www.us-cert.gov/ncas/alerts/TA18-201A 

    Quote

    Emotet is disseminated through malspam (emails containing malicious attachments or links) that uses branding familiar to the recipient; it has even been spread using the MS-ISAC name.

    Use an e-mail client and configure it to disable active content and not automatically open e-mail attachments. Also Eset will scan all the incoming e-mail prior to arrival on your hard disk. Or, go to the extreme and configure the e-mail client to only receive e-mail in text format such as I do.

  2. On ‎12‎/‎16‎/‎2018 at 9:06 PM, xkajxkajx said:

    Tried to remove them in the registry, but they keep coming back everytime I reboot or log off ?!.

    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shellex\ContextMenuHandlers

    According to this article: https://www.techspot.com/guides/1670-windows-right-click-menu/ , you're not deleting the entries from the correct registry keys:

    Quote

    Navigate to Computer\HKEY_CLASSES_ROOT\*\shell and Computer\HKEY_CLASSES_ROOT\*\shellex to find many application context menu entries and delete the ones you no longer want.

     

  3. Do a Google search using this: "access to xmlhttprequest at from origin has been blocked by cors policy". Appears it's a security issue with the web site you mentioned.

    Why Eset protocol filtering would trigger it, I really don't have a clue. You can always exclude that web site from protocol filtering at your own risk.

  4. 59 minutes ago, Marcos said:

    was able to find only one report of this issue, however, it's not clear what actually fixed it for the user: https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/measured-boot-library-encountered-a-failure-and/b3b41312-abb3-4ea0-9a7b-17c1a2ed5506.

    Yeah, saw that previously. Ran the bcdboot command and it didn't make any difference.

    Further research yields:

    Quote

    Secure Boot and Measured Boot are only possible on PCs with UEFI 2.3.1 and a TPM chip. Fortunately, all Windows 10 PCs that meet Windows Hardware Compatibility Program requirements have these components, and many PCs designed for earlier versions of Windows have them as well.

    https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process

    My PC motherboard has a BIOS and it doesn't have a TPM chip. So chalk this one up to the "never ending" 1809 snafus. At least it doesn't appear to bork the boot processing.

  5. Just upgraded to Win 10 x(64) 1809 Home yesterday.

    Seeing this in my Win Event Kernel-Boot log:

    Measured Boot library encountered a failure and entered insecure state. InitState: 1, StatusCode: 0xC0000001, Failure Address: 0x945657, Reference Address: 0xA4E840, Reason: 1.

    As far as I am aware of, measured boot relates to loading of Windows Defender or third party AV ELAM driver.
     

  6. First, make sure you have "Enable detection of potentially unwanted applications, unsafe applications, and suspicious applications" enabled  in the Eset GUI Detection Engine section. If so, did you manually override one of those detections and install some software you wanted?

    Run a full system scan as administrator. If Eset detects nothing or even if it does so, then run a scan using AdwCleaner. You can download it here: https://www.malwarebytes.com/adwcleaner/ . This should clean up any remnants. Finally, it is recommended to reset your browser settings back to default value.

  7. 4 hours ago, Rami said:

    Why is the Windows Firewall running?

    It starts at boot time and its front-end processing is disabled when Windows Security Center initializes. Note that the Eset GUI processing which includes its firewall rules doesn't fully initialize until WCS initializes. Also the Eset firewall does interface with the Win firewall for its inbound rule processing which is enabled by default. Bottom line - the Win firewall is not fully disabled and non-operational when the Eset firewall is enabled. Eset's firewall processing does however take precedence over the Win firewall processing. Hence when you view the Win firewall settings in Control Panel, it is noted the Eset firewall is "managing" the Win firewall operation.

    Anyway, my original posting is no longer an issue, at least presently, since I just upgraded to Win 10 1809.

  8. https://www.us-cert.gov/ncas/alerts/AA18-337A

    I have copied the recommended mitigations with sections underlined for emphasis:

    Quote

    Mitigations

    DHS and FBI recommend that users and administrators consider using the following best practices to strengthen the security posture of their organization's systems. System owners and administrators should review any configuration changes before implementation to avoid unwanted impacts.

    • Audit your network for systems that use RDP for remote communication. Disable the service if unneeded or install available patches. Users may need to work with their technology venders to confirm that patches will not affect system processes.
    • Verify that all cloud-based virtual machine instances with public IPs have no open RDP ports, especially port 3389, unless there is a valid business reason to keep open RDP ports. Place any system with an open RDP port behind a firewall and require users to use a virtual private network (VPN) to access that system.
    • Enable strong passwords and account lockout policies to defend against brute force attacks.
    • Where possible, apply two-factor authentication.
    • Regularly apply system and software updates.
    • Maintain a good back-up strategy.
    • Enable logging and ensure that logging mechanisms capture RDP logins. Keep logs for a minimum of 90 days and review them regularly to detect intrusion attempts.
    • When creating cloud-based virtual machines, adhere to the cloud provider’s best practices for remote access.
    • Ensure that third parties that require RDP access follow internal policies on remote access.
    • Minimize network exposure for all control system devices. Where possible, disable RDP on critical devices.
    • Regulate and limit external-to-internal RDP connections. When external access to internal resources is required, use secure methods such as VPNs. Of course, VPNs are only as secure as the connected devices.
    • Restrict users' ability (permissions) to install and run unwanted software applications.
    • Scan for and remove suspicious email attachments; ensure the scanned attachment is its "true file type" (i.e., the extension matches the file header).
    • Disable file and printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
     
  9. 1 hour ago, Marcos said:

    Do you have the option shown in my screen shot enabled or disabled?

    Disabled.

    I thought it wouldn't matter what that setting was since my prior use of Application Modification showed it was only applicable with the firewall in Interactive mode. Again the only alert I have ever received was for equi.exe. What is strange is the alert doesn't manifest until a few hours after an Eset upgrade. And the alert only occurs once after I respond with keep existing firewall rules. For example, Eset upgraded to 12.0.31 at 9:00 AM today and the alert appeared late in the afternoon. Also there has been no change to equi.exe last modification date after the above noted upgrade time.

    Eset_Egui_Time.png.0d8077909abc3cc9df82f84b69a74684.png 

  10. I have had the below screen shot alert occur the last few times an Eset in-product upgrade occurred. I have the firewall set to Automatic. I thought Application Modification detection only occurred when the firewall was set to Interactive mode. Also this is the only app update alert I every receive. The Eset GUI default firewall is enabled allowing all equi.exe outbound traffic.

    Is this some type of internal security check to detect any unauthorized equi.exe modification? 

    Eset_GUI_Update.png.21f7e247683cc960fb77e3c710045441.png  

  11. 20 minutes ago, ISHOULI said:

    ESET devrait se concentrer sur le pare - feu pour assurer une protection contre les fortes inondations et attaque DDoS

     

    Et quand quelqu'un vous donne l' inondation l' internet sera détecté et arrêté automatiquement sans que vous fassiez rien

    This is an English language forum. Please post in English if you expect to get any replies.

  12. There is one "glitch" I found in regards to in-product Eset upgrades.

    If you perform an Eset repair installation via Control Panel -> Uninstall Programs option, Eset reverts back to the last version that was off-line installed. For example if you manually installed Eset ver. 11 and in-product upgraded to ver. 12, after the repair installation, you're back to ver. 11. You then have to perform an in-product upgrade to get to the latest Eset version. I find this very odd behavior.

×
×
  • Create New...