SeriousHoax

Since keyboard protection became default, I think ESET should have a support/help page where all the software that is known to be incompatible with default ESET settings should be listed.

FYI, I have tested some other top products on the site and none of them detected anything. ESET's detection is correct for sure as confirmed by Marcos. This once again proves (to me at least) that ESET is the best at detecting malicious scripts on websites. Many times, ESET is the only one/the first one to detect such things.

Yeah, all AV products with SSL scanning function bust ECH.

It doesn't have to be Cloudflare DNS. Any DNS that supports one of the encrypted DNS protocols like DoH, DoT, DoQ works. For example, I use my custom NextDNS. BTW, for Firefox one may have to manually set "network.dns.echconfig.enabled" to True. There are methods to enable in Chromium browsers also.

The thing is ESET's HTTPS scanning feature breaks Encrypted Client Hello. According to tests, SNI's aren't encrypted with default ESET. This is not just ESET of course, any product with HTTPS traffic scanning breaks it. Only Adguard For Windows can apply ECH( even though it decrypts TLS connection like ESET) if you allow its DNS protection feature (enabled by default) and enable ECH from Advanced settings. It makes Adguard handle the DNS and apply ECH. So maybe this is not possible unless AV products with HTTPS scanning feature like ESET handles DNS encryption by supporting ECH. ECH is still not finalized and currently mainly supported by cloudflare services I think. But looks like eventually it will become a standard. So I'm curious how ESET is going to handle this case. Sites to test if ECH is working or not: https://tls-ech.dev/ https://defo.ie/ech-check.php https://crypto.cloudflare.com/cdn-cgi/trace/ For the last test site, you'll have to check if, sni=plaintext/encrypted.

In that case, I'm not sure what's causing this.

As Marcos said it could depend on the number of files you have. Also, if it's a HDD then some higher disk usage is expected. It has almost no impact on SSDs.

My assumption is somewhat wrong then probably. Maybe a troll or a random geek using new persona on security forums. Admins/Mods can delete my comments if required since it's a feedback thread.

I'm 100% certain that this @adulwahabis a fake account aka bot that was created just to post a positive comment on this thread. It has to be either from ESET or Intel. The ChatGPT like writing style, the picture and the fact that it was the first and only post from that account so far is a clear giveaway. If you do an image search, you'll find this image on a random Indian website. It's also not hard (for me at least) to guess this person's religion just by looking at the photo which doesn't match with the name. Really poor and unnecessary marketing attempt. Regarding my Intel TDT experience, "I'm an AMD user".

Hi @Marcos! Wondering what this particular malicious script does? Does it redirect to malvertisements or something else?

This is a very good find 👍

Watch the G-Data analyst video again where he showed an example. Besides, BD can detect it by their behavior blocker, so it doesn't matter anyway. Everyone makes hash detection for samples now and then. It's necessary sometimes. ESET also did for a few of the samples mentioned in this thread. Anyway, it's not important what other products are doing. The issue is that ESET is not detecting the samples by real-time protection which should be addressed by them.

The file can be extracted with 7zip with ASAR plugin installed. So it's nothing special.

Yes I'm sure. In this case, changing the hash of this original exe doesn't alter the unpacked content. It works just fine. The data collected from Chrome can be seen on temp. I also tested the changed hash sample with Bitdefender GravityZone EDR product and with the help of EDR sensor, the cloud console shows the whole process chain including files that was accessed by the malware like cookie and logindata inside Chrome's profile folder. So the sample works just as usual. Just ESET is not detecting it even after having signatures probably due to real-time protection ignoring ASAR files.

I only changed the hash of the main 63 MB sample, didn't change the javascript. The file would've been detected via a scan/if it was uploaded to LiveGuard. I used an app to change the hash, zipped it, dragged and dropped into the ESET VM, extracted it and ran it. So it wasn't downloaded and maybe that's why it wasn't sent to LiveGuard. But then again, we also have to remember about Nod32 and EIS users, since they don't have LiveGuard. Most of ESET's home users probably use EIS. BTW, it's a bit confusing for which file ESET has added detection. I mean, I extracted the contents of the ASAR file and nothing from that was detected by ESET even on scan. But if I scan the ASAR file itself, then it's detected by ESET. So if detection was added for the ASAR file itself then it seems ESET's real time protection doesn't scan ASAR file which is not surprising since it's a zip like archive format. So I think this is the main reason why ESET is not detecting it on execution. Bitdefender added detection for the ASAR files themselves also after my submission of a few samples, but they can detect the ASAR file by its real-time protection when the malware unpack itself in the temp folder, which indicates that they scan ASAR files on creation or on access. Bitdefender can also detect by its behavior blocker, but not all variants. I also did more experiments. For another variant, I sent BD one encrypted js file inside the ASAR file only, not the full sample. They added detection and later when tested, their real-time protection could even detect the js file, inside the ASAR file after running the sample. I was really surprised by this. So they not only detect the ASAR file, but also unpack it and scan its contents in real-time. It seems they scan a lot by their real-time protection. They could already detect this hash changed sample by behavior blocker but detecting the js file resulted in an early detection. I still think overall ESET's real-time protection scans more file formats than any other AVs I've used and tested, it's just that it doesn't scan ASAR files since it's an archive format. Maybe ESET should also start scanning ASAR files on creation? Or maybe Deep Behavioral Inspection should be made more useful? I'm not so sure about that. I'm just highlighting an issue that ESET should work on to come up with a workable solution.

I checked this malware again. It's auto blocked by LiveGuard due to being analyzed before. So I changed the hash of the exe and ran it and there was no reaction from ESET. So, nothing has been done yet to tackle the issue of detecting this/similar malware. If you say, LiveGuard would detect it if it was uploaded I would argue that LiveGuard is not available in products like Nod32 and EIS. Also, if the malware authors increases the size of these samples above 64 MB, they won't be sent to LiveGuard anyway. Original sample: https://www.virustotal.com/gui/file/d4524f9c529ffd945c789b8379116b8bb6227de2ffa045729f47a4131f3d5cfb/detection

Not even post-execution detection for this malware. I mean if you directly run that script then it will detect it but that's not what's happening here. The method of using this javascript by the malware, whether by process injection or some other ways, is bypassing all ESET's protection layers. These malwares are very successful at bypassing AV products. So I think they'll just keep coming.

Yeah, this one is very similar. Electron based malware hiding malicious scripts in ASAR files has been around since 2021 at least. For ESET, the issue is that it's not detecting them after running, even after creating signatures for the main file. It has to be addressed.

Interesting find. But this one is probably not loading in GPU/VRAM. The malware comes bundled up with Electron framework and loads a fake game Window to deceive the user into thinking they have run a game. Probably the gpu process, renderer related activities are related to the fake game screen which is being loaded using Electron.

This one is different from the ones I shared. My shared ones can steal data, cookies from any installed Chromium browsers like Edge, Chrome, Opera, Brave, Vivaldi and also from apps like Discord, Steam and some more apps if installed. There are a variety of stealers. Each one learns from and steal malicious techniques from the other one, improve them and then sell it. So some techniques might be similar but not the whole thing. There are multiple groups on Telegram. Some even have publicly accessible website for selling their malware. I checked those a few weeks ago. The sites were blacklisted by Bitdefender only.

Thanks. But according to the G-Data analyst Karsten Hahn also, these javascripts are where the main malicious code remains. The code is encrypted and when decrypted, it can be easily seen what it does. Check the video if you haven't checked yet. So ESET's signature is correct in that case. Now how these malwares use the code in context is a thing I don't know about. The javascript file itself never touches the disk I think. It's in the ASAR file and remains there it seems. Something happens in memory or whatever method the malware use is something I don't have the expertise to understand. The ESET team must do something about it. Current signature based method to detect these is incomplete.

Yeah, they are now detected indeed. Thanks for helping in sending to the malware analysts. But just now I tested again and turns out, if I run the samples then they can still "Steal" the data anyway. There was no reaction from ESET. It's only detected if I scan the file instead of running it. So, the flaw of ESET not detecting these via real-time protection remains. Sooner or later after execution real-time protection needs to catch it. Can you test on your end? If you can reproduce, then report the issue to the responsible team.

Redline stealers are well known and already covered by most vendors. But the stealers I shared are very different. Those are Electron based and the main malicious component hides in a place where many junior analysts may not look as shown in the analysis video. That would be ideal, but the victims of these attacks are not security aware people, so it's fair to say that they won't do this. It's a legit gaming site for indie games. Some malicious actors are using it to spread malware. ESET or any AV won't blacklist the site, I think. The people maintaining the site should be more responsible. Their security procedure is clearly very weak.

ESET added detections for the samples in my main post, but these two in my quoted comment are not detected. Maybe the added detections are very basic file based detection which is simply not enough. No deeper analysis was done by an ESET malware analyst. I posted it during the weekends, so I hope in the next couple of days during weekdays, these samples will be properly analyzed and ESET will be able to find a way to stop all similar stealer samples like Kaspersky. Along with the two above, here's one more. No detection from ESET after running, and not detected by LiveGuard either. It's basically the same as some others but just with a different hash. BTW, I can actually see the data it's stealing (Browser cookies, passwords, autofill, credit card info). So these are working perfectly fine in a VM. No VM evasion techniques were used by them. ESET also need to blacklist the malware C2C connections. https://www.virustotal.com/gui/file/67f86d940e8e8eb73c09c9b37bef9248ed7e0ee0ec317fc118678ad44f69a63e/detection

It's not just UDS. They have multiple signatures for this, including PDM detections, which are post execution behavior based. I tried changing hash which eliminates the UDS detections, but they are still detected after running. Their Big Data Analysis system which can co-relate similar file hashes and behavior automatically is doing a good job against this malware at the moment. https://opentip.kaspersky.com/d4524f9c529ffd945c789b8379116b8bb6227de2ffa045729f47a4131f3d5cfb/results?tab=lookup