-
Posts
12,275 -
Joined
-
Last visited
-
Days Won
322
Posts posted by itman
-
-
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:
QuoteNavigate 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.
-
It's a browser hijacker. Malwarebytes has an article on it here: https://blog.malwarebytes.com/puppum/2017/02/spigot-browser-hijackers/ . Look in Control Panel -> Programs and Features for anything installed that matches any of the names listed in the Cleaning section of the article.
-
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.
-
One other thing to check.
Verify that Windows Defender - realtime - is disabled. Who know what it will do to third party AV submission if it is active. Likewise, verify no other third party AV or like software is installed and running in realtime mode.
-
LiveGrid feedback is enabled on my Win 10 Home x(64) 17763 build and has been so since upgrade to EIS 12.0.31.
Since you reference a Win 10 Pro ver., the only thing I can think of is he set on some Group Policy setting that is possibly interfering with Eset outbound uploading of LiveGrid data.
-
Also a better way to approach this issue is to determine why this PoweShell script is running in the first place. Its execution indicates system issues. Some background information here: https://www.exefiles.com/en/ps1/ts-volumeerrors-ps1/ .
-
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:
QuoteSecure 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.
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.
-
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.
-
Run through the tests on this web site: https://www.amtso.org/feature-settings-check-for-desktop-solutions/
-
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.
-
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.
-
Win 10 Home x(64) 1803, Internet Security 12.0.31
For the first time ever, saw the below Event Log entry today after cold boot. Everything system and Eset wise appears to be OK and functioning normally. Boot was extremely slow however. Might be just a startup glitch due to Windows Security Center not fully initialized?
-
Do you have Eset installed?
-
Question to anyone with this issue. Is the CD/DVD a USB one?
-
1 hour ago, Marcos said:
I opened https://ibanking.stgeorge.com.au/ibank/loginPage.action in Firefox and was asked if I want to open it in a secure browser.
Such is not the case in IE11.
-
This Eset knowledgebase article also has a few additional recommendations in regards to best practices against ransomware: https://support.eset.com/kb3433/?locale=en_US&viewlocale=en_US
-
https://www.us-cert.gov/ncas/alerts/AA18-337A
I have copied the recommended mitigations with sections underlined for emphasis:
QuoteMitigations
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.
-
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.
-
5 minutes ago, Marcos said:
This would happen if you had a permissive firewall rule created for egui.exe
The only firewall rule for equi.exe is the default rule. See the below screen shot. Should that rule be disabled?
-
I assume you are trying to remove SEP?
Did you try this: https://support.symantec.com/en_US/article.HOWTO74877.html
-
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?
-
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.
-
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.
-
10 hours ago, kingsyno said:
My client server with ESET installation on it just had similar issues. Please what do we do?
If it's GrandCrab ver. 1,4, or 5, you can try this to see if will decrypt the files: https://www.nomoreransom.org/en/decryption-tools.html#GandCrabV1V4andV5versions
Additional reference is here: https://www.europol.europa.eu/newsroom/news/pay-no-more-universal-gandcrab-decryption-tool-released-for-free-no-more-ransom
Web Protection behaviour on different browsers
in ESET Endpoint Products
Posted · Edited by itman
You might want to review this article on how Emotet is spread: https://www.us-cert.gov/ncas/alerts/TA18-201A
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.