itman
-
Posts
12,280 -
Joined
-
Last visited
-
Days Won
322
Posts posted by itman
-
-
Off the top of my head, I would say it has to do with the fact the Eset firewall is stateful. It will only monitor inbound Internet activity for which a previous outbound connection was made. In the absence of explicit firewall rules to allow select inbound non-stateful Internet traffic, the inbound connections will be automatically dropped. The previous is evidenced by looking at the default Eset firewall rules. Of note is there is no default rule at the bottom of the rule set that explicitly blocks all inbound traffic.
In my case, I use a router that deploys a stateful firewall. So all unsolicited inbound traffic is dropped at the network perimeter.
-
Refer to the below screenshot. Check a device that was upgrade to ver. 12 and verify if the LiveGrid feedback setting is enabled. I can't recollect if the feedback system option existed in ver. 11. I believe it did not. If it didn't exist in ver. 11 whether it is enabled in ver. 12 might be dependent upon what feedback settings were enable in regards to the Submit options listed. Or the issue is at least one of the Submit options need to be enabled.
For a test, you could set the LiveGrid settings to default values; i.e. click on the circular arrow symbol across from "Cloud-Based Protection", on a device showing the popup screen you posted and see if that eliminates thereafter, the popup from appearing on the Eset GUI home screen.
-
2 hours ago, isam said:
the eset starts as it should start but the splash screen of eset made me realize that Firefox start is due to the eset start and not by it self or by any windows settings made to change how Firefox start ( I didn't modify Firefox)
So disable Eset's splash screen and see if that stops Firefox starting.
Again how the splash screen could be in anyway related to this really makes no sense at this point. The appearance of the splash screen has nothing to do with the base start up of Eset. That is done during the system boot phase. In other words by the time your desktop appears, Eset's kernel process is running already. I believe the slash screen is related to the starting of Eset's GUI processing as evidenced by the appearance of the Eset icon on the desktop lower toolbar.
I would suspect the "culprit" might be that graphical thing on your desktop containing the desktop icons? that is displayed right above the desktop lower toolbar whatever that is.
-
Based on what was originally posted, it appears there is an issue with the Eset splash screen and Firefox starting at the same time. Why really is beyond me. I suggest the following:
1. Disable the display of the Eset splash screen in the Eset GUI Interface settings.
or
2. Disable the startup of Firefox at boot time.
-
You need to clarify what this means "for computers I do not want to ever go online."
Assumed is you are using Win Updates to keep your OS patched and up to day. Also if you are running Win 10, it is connecting to the Internet for Store app updating and diagnostic data transmission.
Bottom line - Eset's web proxy filtering is monitoring all Internet connection activity; not just browser activity.
-
Eset has behavioral signatures that work very similar to YARA detection. You can read about YARA here: https://securityintelligence.com/signature-based-detection-with-yara/ . Basically select process behavior in the form of a rule is encoded in the signature.
Additionally, Eset's HIPS also has predefined rules to monitor process activity against sensitive system areas such as the Windows directory and registry.
Finally Eset has AMS, advanced memory scanning, that is monitoring a process's memory areas for malicious code that may be injected.
Eset did very well in this test beating out Kaspersky in overall malware detection.
-
I also have a Eset signature update issue. When I log off of Windows for an extended period of time and then log back in, Eset does indeed check for updates. However, I receive no update. Nor is one served up if I check manually. I has been 5 hours since my last sig. update. That doesn't seem right to me.
-
Well, a DSL connection, Ethernet or wireless is established as soon a Windows network connection is establish as part of the Windows boot process. Now there are a few routers that actual do have a type of DSL "dial up" network capability. A while back I had a Netopia commercial grade router that had that option along with some other neat stuff like honeypot capability.
-
On 11/12/2018 at 7:04 AM, Fiona said:
How can I put a wild card into the IP? I have tried blamnk, * and a range of 0.0.0.0 to 254.254.254.254 and nothing works.
You can't. The Eset firewall rules don't support wildcards.
The Eset default firewall rule only allows inbound traffic for RDP, port 3389, for IP address listed in the Trusted Zone. For the internal network device you wish to connect to, you can add the IP address for each external device to its Trusted Zone. I believe this is only feasible if those external devices have static IP addresses assigned.
Note: doing so will then activate all Eset default rules that allow inbound Trusted Zone traffic to be applicable to your external devices.
-
35 minutes ago, galaxy said:
@itman You do a great job that I just want to praise and ... thank you for all the help. Nice that you are so actively helping here. Thank you
You're welcome.
-
One final comment about this Search Service.exe sample that most might have not noticed.
Cloudstrike Falcon at VT detected it as 100% malicious. Assumed is the Falcon sandbox is not deployed at VT and only machine learning heuristics were deployed. However the analysis at Hybrid-Analysis does deploy the Falcon sandbox allowing for a more thorough process analysis. That analysis yielded a 89% malicious confidence rating.
Now lets factor the other known variables involved. This does not imply that there are other unknown ones involved:
1. An unknown and unsigned process created in a Windows directory.
2. A Windows autorun mechanism created to run the process at system startup time.
I really believe that at a minimum, Eset should have thrown a suspicious alert on this one.
-
1 hour ago, Marcos said:
1, Update at logon has always been disabled by default:
I still believe there is a bug in NOD32. Notice in the screen shot you posted, the like dial-up option is enabled instead. Virtually no one uses a dial-up connection these days.
-
There are at least 42 variants of Gen:Variant.Mikey.24795 going back to 2015: https://totalhash.cymru.com/search/?av:Gen*Variant.Mikey.24795 . Average VT AV vendor detection is around 50% for these.
Below are some of the variants that Eset detected in the past. I did not check all of the 42 variants for Eset detection:
https://totalhash.cymru.com/analysis/?5485d4ada205b0feddf559da044d41f048dbe177
https://totalhash.cymru.com/analysis/?6c63f84bb0363fa01a70d580b8c122e743eaa36d
https://totalhash.cymru.com/analysis/?3371cb7e337bf3da285e851026dbcd37f7382913
-
As far as this goes:
QuoteWhy "update at logon " is disabled by default???
It is enabled by default in Internet Security. It might not be for NOD32. So I would create a support request and report it as a bug to Eset.
Also for Internet Security when the update at logon occurs, the Eset GUI startup screen does show that the update occurred; i.e. Last Update xx minutes ago, if with the current hour.
-
7 hours ago, Johnny Wan said:
The issue happens because we block traffic to outlook.office35.com
I also don't understand the above statement. If you are blocking outlook.office365.com connections, why is Firefox showing that indeed a connection was made?
-
29 minutes ago, novice said:
1, Why "update at logon " is disabled by default???
It isn't. You must have somehow disabled it.
-
5 hours ago, Johnny Wan said:
outlook.office35.com
I analyzed outlook.office365.com at QUALS: https://www.ssllabs.com/ssltest/analyze.html?d=outlook.office365.com . The certificate and chaining path are fine. See below screen shot.
Suspect this alert is happening in Firefox due to either Eset SSL proxying activities; i.e, Eset root CA cert. being used or there is a certificate issue within Firefox since they use their own root CA certificate store.
-
26 minutes ago, sypticle said:
i have 1 more question: so if i use Wireshark, and put the filter as "dns" would i be able to get the persons IP and block it in the firewall?
Per the Hybrid-Analysis, this isn't necessary:
QuoteNetwork Analysis
This report was generated with enabled TOR analysis
DNS Requests
No relevant DNS requests were made.
Contacted Hosts
No relevant hosts were contacted.
HTTP Traffic
No relevant HTTP requests were made.
-
2 minutes ago, sypticle said:
Okay, so when i downloaded the RAT, the person disabled my "Administrator Permissions" I'm not really sure how
In all likehoodly, the perpetrator ran one of the Win utility processes that are increasingly being abused. A number of those can be run hidden and silently elevate to admin level.
Tip - if you run as a limited admin and don't have UAC set to maximum level, you need to do so. Most of these bypasses can be detected when UAC set to max.. Yes, you will receive additional UAC alerts but the increased security factor is worth the minor annoyance.
-
One other thing.
Malware should not be able to write to the C:\Windows directory w/o full admin privileges as shown in the below screen shot; at least for Win 10. So that is something you should check out.
-
Just now, sypticle said:
so I'm guessing It's okay to delete?
Yes.
But I would zip it up in a folder in your download directory, etc. in the very remote chance its removal borks something in the near future. After a while with no issue related to its removal surfacing, you can then delete the folder.
-
8 minutes ago, sypticle said:
here is the link for the analysis: https://www.hybrid-analysis.com/sample/c1ac18c9c98e3fffc50553950c154601032048b4e007ef502bc9362f1acec90f/5be9cbea7ca3e132553fd388
With a behavior analysis score of 89/100 which is one point below the high confidence level, I would say this bugger is malicious. Especially so using the MITRE indicators noted.
Did AdwCleaner get rid of the Search Service.exe in the C:\Windows directory?
-
2 hours ago, 0x55 said:
I did notice that Eset had changed the sites' favicons in Chrome, but that has reverted back in the past few days. I can manually open the secure browser, and that seems fine.
The sites are definitely set to use secure browser in Advanced Setup. I've also tried variants like adding www or the index.html landing page, with no success.
Also discussed in a recent like thread on this subject, Eset doesn't support HTTPS/2 yet. So any like web site will not cause the opening of BP&P secure browser regardless of the source browser used.
-
1 hour ago, pronto said:
The actual question is whether it is enough to set up the directories in the 'Dectection Engine - Exclusions' dialog to exclude them both in the Real Time Scan
As far as I am aware of, process and file exclusions entered for the detection engine apply to any Eset options subordinate to it. This would include any of the manual or scheduled malware scanning options.
NOD32 update
in ESET NOD32 Antivirus
Posted · Edited by itman
My best guess at this point is there is a bug in NOD32. This behavior does not manifest on Internet Security.
What we need is other NOD32 users to confirm it is happening to them. I suspect most users don't pay any attention to the update time displayed on the Eset GUI home screen. I didn't until you brought up the issue.