SeriousHoax
-
Posts
361 -
Joined
-
Last visited
-
Days Won
10
Posts posted by SeriousHoax
-
-
4 minutes ago, C0kkie said:
Its a ssd and there are not many files
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.
-
31 minutes ago, itman said:
Two recent postings on the Kaspersky forum; also from yesterday;
Here's one from 2016 where the photo was probably hijacked from: https://wajraoforce.in/wajra/50-kb-photo/
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.
-
On 9/21/2023 at 11:25 AM, adulwahab said:
My experience with Intel Threat Detection Technology (Intel TDT) has been great. It saved my computer from a ransomware attack by quickly detecting and quarantining the malicious file. I highly recommend Intel TDT for computer protection.
On 9/21/2023 at 5:09 PM, AnthonyQ said:Tbh, I haven't seen and tested this feature in action because Intel TDT was rarely triggered by the ransomware samples I tested.
@adulwahab , would you be so kind as to share the hash of the sample that was detected by Intel TDT?
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?
-
13 hours ago, itman said:
As far as ASAR files go, here's an interesting read;
This is a very good find 👍
-
4 minutes ago, itman said:
Just how were they able to decrypt the JavaScript w/o the applicable key to do so? They can't do so.
Appears all BD did was create a hash detection for the encrypted script.
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.
-
8 hours ago, itman said:
ASAR files are Electron archive files and they can be packed which I assume was done for this sample;
asar pack app app.asar
The file can be extracted with 7zip with ASAR plugin installed. So it's nothing special.
-
1 hour ago, itman said:
The sample is a packed archive embedded within a .exe installer. If the original sample .exe you downloaded was auto submitted to LiveGuard, so should have your modified sample .exe when created in the VM.
It's academic at this point since LiveGuard didn't detect the original sample when submitted due to the anti-VM processing employed by the sample. Since you are running the modified sample in a VM, are you sure it actually fully executed? If it did not, this would explain Eset's real-time non-detection of it.
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.
-
56 minutes ago, itman said:
Good example of how easy it is to defeat a script sig. detection if what you modified was the JavaScipt code.
It also means LiveGuard didn't detect it. When you changed the .exe, it should have been submitted to Liveguard upon file creation since the file hash changed. As noted in other forum threads, LiveGuard is not dependent upon MotW status. However if you just updated the existing .exe, Eset's prior scan indicator might still be in place resulting in it not being submitted again to LiveGuard.
As I have instructed previously when you modify a .exe, upload to a file share site and download it again.
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:
-
1 hour ago, itman said:
I believe all Eset did was create a sig. for the JavaScript code. And, it would be a post-execution 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.
-
1 hour ago, itman said:
Well this attack method is not new as evidenced by hacked games being downloaded from Microsoft Store: https://hothardware.com/news/beware-electron-bot-malware-hiding-gaming-microsoft-store;
Mitigation;
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.
-
On 7/21/2023 at 1:36 AM, itman said:
Following up on my last posting, the issue here is not that AV's including Eset can't detect known infostealer install payloads. I have seen enough evidence they can excluding these game installer instances.
I will again refer to the RabbitCheeks.exe installer sample; specifically its execution activities per VT's posted screen shot.Notice what I highlighted;
Now ponder this. What if the installer was loading the infostealer payload into the graphics card VRAM and running it from there?
Don't think that is possible?
First, read this: https://www.bleepingcomputer.com/news/security/cybercriminal-sells-tool-to-hide-malware-in-amd-nvidia-gpus/ .
Next, read this: https://techunwrapped.com/your-gpu-and-its-memory-can-infect-your-pc-this-is-the-undetectable-virus/ and most important, this:https://eversinc33.com/posts/gpu-malware/ .
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.
-
10 hours ago, itman said:
Given that @SeriousHoax mentioned ASAR use by the infostealer, start reading in the Malware Analysis section of this TrendMicro article: https://www.trendmicro.com/en_us/research/23/e/info-stealer-abusing-codespaces-puts-discord-users--data-at-risk.html .
The quick summary is;
This implies to me that the infostealer malware being deployed in these infected game installers only applies if Discord is installed? @SeriousHoax do you have Discord installed? Are the people getting infected by these infostealers in the game installers have Discord installed? Otherwise, G-Data is full of you know what.
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.
-
9 minutes ago, itman said:
Kudos on the retesting!
I didn't think that JavaScript's had anything to do with these posted infostealer activities. Hybrid-Analysis analyses of these infostealers didn't detect any running. Many of these infostealers employ a ransomware component that can be optionally deployed. Perhaps Eset detected those in memory.
Or, Eset just picked up on other malware in the installer unrelated to the infostealer. This would explain why the JavaScript's were detected via manual scan. My prior posted scan screenshot shows Eset will expand files within the installer in a manual scan.
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.
-
14 hours ago, Marcos said:
In this case it was two js files inside an embedded archive which are malicious and are now detected.
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.
-
15 hours ago, itman said:
I captured a just posted Redline infostealer sample. Redline is the most proficient infostealer currently circulating around.
It was detected by Eset LiveGrid submission; not LiveGuard submission. The sample had been previously submitted to VT 50 mins.earlier and already was detected by 32 vendors.
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.
15 hours ago, itman said:This gets us to infostealers embedded in game installers. My opinion on those is they should be submitted to one of the cloud sandbox services for a full sandbox analysis prior to running the installer.
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.
15 hours ago, itman said:Eset should be blocking access to the web site since its serving up downloads containing malware.
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.
-
11 hours ago, SeriousHoax said:
Yeah, everyone has issues with these stealers. Only Kaspersky's automation and behavior analysis seems to have found a way to detect these well enough.
Here's two more similar ones:
A user from the malwaretips forum are finding these on the game platform https://itch.io/
A friend of mine also found a few stealer campaigns on telegram. They are constantly updating their samples to bypass detections. ESET researchers probably should check out the campaign of uploading samples pretending to be games on the itch.io platform.
I'm tagging Mr. @Aryeh Goretsky just in case since he's part of ESET's R&D team.
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.
-
1 hour ago, Nightowl said:
As far as my brain helps me , Kaspersky is with the others but they are just quicker to re-act to adding signatures , hence the detection name UDS
Malware Hashes (UDS) – a set of file hashes detected by Kaspersky Lab cloud technologies (UDS stands for
Urgent Detection System) based on a file’s metadata and statistics (without having the object itself). This enables
the identification of new and emerging (zero-day) malicious objects that are not detected by other methods.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.
-
11 hours ago, itman said:
I did some ad hoc testing with infostealer samples and for the majority of them, initial AV detection at VT was quite low. So its not just Eset that has detection issues with them.
Yeah, everyone has issues with these stealers. Only Kaspersky's automation and behavior analysis seems to have found a way to detect these well enough.
Here's two more similar ones:
A user from the malwaretips forum are finding these on the game platform https://itch.io/
A friend of mine also found a few stealer campaigns on telegram. They are constantly updating their samples to bypass detections. ESET researchers probably should check out the campaign of uploading samples pretending to be games on the itch.io platform.
I'm tagging Mr. @Aryeh Goretsky just in case since he's part of ESET's R&D team.
-
1 minute ago, itman said:
As far as LiveGuard non-detection, was this .exe actually submitted to it given its 150MB size? If so, anti-sandbox evasion could have been employed; remember this includes actually executing in the sandbox but not deploying the malicious code.
The main exe sample file just under 64 MB. LiveGuard can upload it. It's 150 MB only after unpacking which he needed to do for his analysis.
-
1 hour ago, itman said:
This one is a Quasar RAT variant: https://embee-research.ghost.io/hunting-quasar-rat-shodan/ using PyInstaller. One reason for possible lack of large AV detection of it is Quasar appears to be legit software: https://github.com/quasar/Quasar . Quasar should be detected as a PUA and quarantined.
I suspect Eset didn't detect the RAT at all, but triggered on PyInstaller use.
Yeah it's Quasar. ESET detected a PowerShell code via its AMSI and Command Line Scanner at one point. I have saved screenshots for that. But I don't understand how come LiveGuard couldn't detect it? It should be detected by their Sandbox.
1 hour ago, itman said:Most malware these days deploy sandbox evasion tactics rendering LiveGuard at best, minimally effective.
I didn't analyze your other posted samples. If these deployed a malware loader, this is another possible non-detection reason. My ad hoc testing of samples using a malware loader has to date yielded zero LiveGuard detection's.
Couple of the stealers didn't employ any sandbox evasion tactics. It's a bit different type of stealers. New variants by different groups keep coming regularly. It was discussed in the Malwaretips forum. G-Data analysts Karten Hahn even made video about it after the forum discussion and his analysis. You can check that out here:
At the moment only Kaspersky is doing a decent job at detecting these stealers by their behavior blocker.
-
Here are some stealer samples not detected by ESET yet. The size of these samples are too big to be sent to ESET mail as attachments. LiveGuard considered these safe. I sent VT links of two of these samples to ESET more than once but my submissions were ignored as usual, so I'm sharing here:
This one is a Backdoor. ESET detect after execution at a later stage via AMSI and Command Line Scanner. But for some reason, LiveGuard marks it safe. A signature would be better:
This file is used by a couple of these samples. Kaspersky and Bitdefender detect these as PUP. Maybe ESET should consider creating a PUP/PUA detection for it as well.
Web Access Protection and Encrypted Client Hello (ECH)
in ESET Endpoint Products
Posted · Edited by SeriousHoax
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.