itman
-
Posts
12,466 -
Joined
-
Last visited
-
Days Won
329
Posts posted by itman
-
-
1 hour ago, Marcos said:
If the javascript scanner works, then the update didn't affect ESET.
Then why is the alert shown in red color? I have never seen that before as I recollect.
Also my other questions; no action given and nothing quarantined? Because it's HTML code, Eset JavaScript scanner just blocks the code execution and that's it?
-EDIT- Below is a screen shot of the actual Eset alert. Appears my above assumption of in-memory execution blocking is correct. Also, I guess the red color is now used to show an actual threat and orange/brown used for simulated malware detection? Details on alert color coding scheme in log files would be helpful in the Eset online help.
-
2 hours ago, tommy456 said:
SSDP Disabled which also disabled UPnP, (win 7) but that has stopped these inbound attacks or whatever they were
Are you stating that this stopped the inbound port 445 blocked connections you originally posted?
-
13 hours ago, xkajxkajx said:
I think ESET is restricting MY USER ACCOUNT to delete or modify some registry entries . PROVE ME WRONG .
If this was the case, you should have been receiving HIPS alerts about modification of registry keys. Did you check your Eset HIPS log for entries related to your registry modification activities? If none of the prior apply, Eset is not preventing any of the registry key modifications you are performing.
-
@Marcos, suspect that the recent patch Microsoft issued for a JavaScript vulnerability which resulted in jscript.dll being modified might have busted Eset's javascript scanner in IE11.
-
Win 10 Home x(64) 1809, Internet Security 12.0.31
Never saw this one before. IE11 detected threat is shown in red color in the Eset associated log. Although no action appears to have occurred per log entry, I assume nothing malicious happened since the Eset alert stated threat was deleted. Note that nothing for this exists in Quarantine.
-
40 minutes ago, novice said:
So, what the point in running ESET firewall in default mode if something which is no-no in your security book is allowed out????
If a worm is able to install itself, the first thing it will try to do is connect outbound TCP port 445.
Eset by default doesn't block outbound TCP port 445 since if your on a internal network and share files or printers, it is valid communication. I am not on a network and as such, don't share files or printers.
-
Try AdwCleaner. You can download it here: https://www.malwarebytes.com/adwcleaner/
-
You already posted a thread on this topic here: https://forum.eset.com/topic/17959-hank/
-
17 minutes ago, tommy456 said:
Well since my last, there has been at least 1 attempt to connect via Port 1900
SSDP Eset firewall blocks are the norm. I just disabled the service in Windows since I was tired of my associated Win Event log filling up with blocked entries.
-
As far as the inbound port 445 traffic, your router should be blocking any unsolicited inbound traffic on that port. That means something on your PC is most likely sending outbound TCP traffic on port 445. This is a no-no in my security book but the Eset firewall by default rule will allow it. The culprit my best guess is the above noted process.
-
First up is the Microsoft Publication Service Device Host that is connecting to a Russian IP address per Robtex lookup:
Quote5.145.203.195
whois Smoltelecom PPPoE (dynamik IPs pool2) route 5.145.192.0/18 bgp AS44265 asname SMOLTELECOM-NET descr Dummy description for 5.145.192.0/18AS44265 location Smolensk, Russia Per Microsoft:
QuotePublication Services enables a WSD device to advertise (publish) its functionality and then offer its functions as Web services over IP-based networks. It also enables devices to find (discover) and access Web services of other devices and computers on the same network. From a user's perspective, NCD technologies will largely eliminate the experiential difference between using devices directly connected to a computer and those virtually connected over a network (including the Internet). As explained above, typically a developer will uniformly access NCDs using higher-level publication services and function discovery.
https://msdn.microsoft.com/en-us/library/bb756908.aspx/
Why that process is running let alone installed on an end user PC is beyond me.
-
3 minutes ago, da_yoshman said:
just a link to .doc file
Out of curiosity, post what the expanded link shows.
-
You might want to review this article on how Emotet is spread: https://www.us-cert.gov/ncas/alerts/TA18-201A
QuoteEmotet 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.
-
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.
Media Creation Tool 1809 Problems with Eset.
in ESET Internet Security & ESET Smart Security Premium
Posted
No clue what the Windows alert is showing since it is not in English language. This is an English language forum.