Stealers not detected

[SeriousHoax 87]

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:

https://www.virustotal.com/gui/file/fb888cb52b9acd732b3a8cd1e0928cdd86dbc4a8de01f1d48e41fce153e3b0c4/detection 

https://www.virustotal.com/gui/file/962c6df0b8ca065bd5df52e06c744c7795867aaacf856798e78cf27fecf3ea9d/detection

https://www.virustotal.com/gui/file/812c1bc73253ea51ba829be98d7c1af22c52fe8308014eca7d0dd6940dd3608c/detection

https://www.virustotal.com/gui/file/e5d1b8d1d38678d6333804c98802a2d7bc4917ab1a07aa85868e6e2e9284ddd6/detection

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: 

https://www.virustotal.com/gui/file/99198643f2b0564539abec2e6e7ca8c7c455e203077b8751a9a8400807ad1ddc/detection 

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. 

https://www.virustotal.com/gui/file/53314136803bee54998b66527ced96f94ab72873b2f1f6d9ed1d4756953e5200/detection

[itman 1,746]

1 hour ago, SeriousHoax said:

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: 

https://www.virustotal.com/gui/file/99198643f2b0564539abec2e6e7ca8c7c455e203077b8751a9a8400807ad1ddc/detection 

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.

Edited July 15, 2023 by itman

[itman 1,746]

1 hour ago, SeriousHoax said:

LiveGuard considered these safe.

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.

Edited July 15, 2023 by itman

[SeriousHoax 87]

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: 

https://youtu.be/kGwa9poV8OU

At the moment only Kaspersky is doing a decent job at detecting these stealers by their behavior blocker.

 

Edited July 15, 2023 by SeriousHoax

[itman 1,746]

37 minutes ago, SeriousHoax said:

G-Data analysts Karten Hahn even made video about it after the forum discussion and his analysis.

Quote

We investigate a "game" named crazydown.exe. The application was written in JavaScript and built with Electron Framework resulting in a huge Portable Executable. Where do we find the malware code in a 150 MB application?

Node.js is another method that would result in a large sized .exe like this.

First, Eset's primary method for detecting packed, obfuscated, etc. JavaScript code is AMSI which is N/A in this instance since its only applicable to scripts. That leaves Eset's advanced memory scanning at post execution time. Post execution by definition opens the possibility of malware infection by other unknown code prior to actual detection of malicious code. Kaspersky for example via its "System Snapshot" capability can prevent this type of infection by rolling back system modifications prior to malicious .exe execution.

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.

Edited July 15, 2023 by itman

[SeriousHoax 87]

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. 

[itman 1,746]

I took a look at the infostealers and they are all running from a shell.

For example;

The shell process creates the payload process.

Quote

Shell commands

"%SAMPLEPATH%"

"%SAMPLEPATH%\962c6df0b8ca065bd5df52e06c744c7795867aaacf856798e78cf27fecf3ea9d.exe"

"%USERPROFILE%\AppData\Local\Temp\2SR5aVa4PcM6ddgMYNDTBMFonT1\TBMSetup.exe" --type=gpu-process --user-data-dir="%USERPROFILE%\AppData\Roaming\TBMSetup" --gpu-

 

It then injects the malicious code into the payload;

Quote

Processes injected

%USERPROFILE%\AppData\Local\Temp\2SR5aVa4PcM6ddgMYNDTBMFonT1\TBMSetup.exe

Shell malware appear to be Eset's detection "Achilles heel."

Edited July 15, 2023 by itman

[itman 1,746]

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.

[SeriousHoax 87]

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:

https://www.virustotal.com/gui/file/d4524f9c529ffd945c789b8379116b8bb6227de2ffa045729f47a4131f3d5cfb/detection

https://www.virustotal.com/gui/file/55a53bc3effd29452d1582cee94f4541123b3c34a3d69cfc0a7db93570b884d8/detection

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.

[Nightowl 206]

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.

[SeriousHoax 87]

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.

https://opentip.kaspersky.com/d4524f9c529ffd945c789b8379116b8bb6227de2ffa045729f47a4131f3d5cfb/results?tab=lookup

[itman 1,746]

Today's discussion is why is initial detection of infostealers; recent malware loaders I have analyzed; etc. so difficult to detect? For starters, they employ both sandbox and behavior evasion tactics.

My analysis of the above yields the following activities;

1. Spawning one or more identical child processes of itself.

2. Malicious code injection into one of the child processes usually done remotely but not always, and execution of that code.

Sandbox evasion occurs if the initially run .exe; usually a shell, detects it is being monitored, it simply creates a process that does not perform any of the above activities. Of note is there is nothing malicious about this payload  (parent) process.

Behavior evasion occurs by performing above 1). and 2). activities. How?

It deals with how most AV's do behavior monitoring. If the AV detects anything suspicious with the payload (parent) process, it will set a hook, usually a .dll, into that process to monitor activities. If the parent process spawns a child process/processes copy of itself, no monitoring hook is set in those processes.

Since the child process is now running in an un-monitored AV state, malicious code injection into it can occur unimpeded.

Next is many legit processes processes spawn copies of themselves; most notably browsers.

There is a Sigma rule that detects parent child process cloning. Once triggered, process reputation evaluation needs to be performed.

If the process reputation status is unknown or low, the parent process needs to flagged as suspicious and blocked from executing. Alternatively, the AV needs to set its behavior monitoring hook into any spawned child process. The issue here is it appears these child process's are being created from the dropper shell and not the parent process. Therefore, shell processes need to be monitored for like behavior.

[SeriousHoax 87]

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:

https://www.virustotal.com/gui/file/d4524f9c529ffd945c789b8379116b8bb6227de2ffa045729f47a4131f3d5cfb/detection

https://www.virustotal.com/gui/file/55a53bc3effd29452d1582cee94f4541123b3c34a3d69cfc0a7db93570b884d8/detection

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.

https://www.virustotal.com/gui/file/67f86d940e8e8eb73c09c9b37bef9248ed7e0ee0ec317fc118678ad44f69a63e/detection

Edited July 16, 2023 by SeriousHoax

[itman 1,746]

Further analysis yields that it's not that the AV's can't detect infostealers, but that they are not very proficient at detecting new variants of them. 

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.

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.

-EDIT- As far as this goes;

Quote

A user from the malwaretips forum are finding these on the game platform https://itch.io/

Eset should be blocking access to the web site since its serving up downloads containing malware.

Edited July 16, 2023 by itman

[SeriousHoax 87]

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.

[itman 1,746]

Good article on InfoStealers here: https://www.secureworks.com/research/the-growing-threat-from-infostealers

Quote

Infostealers can be installed on a computer or device via phishing attacks, infected websites, and malicious software downloads. Once installed, they can execute and exit very quickly; many infostealers finish collecting and transmitting stolen data within several seconds to a minute of total runtime. The data is then packaged and sold as logs. Threat actors could use stolen credentials in these logs to gain unauthorized access to enterprise networks via remote access services such as virtual private networks (VPNs) and Microsoft Office Web Access (OWA).

Their rapid execution coupled with the use of legit software such as ProcDump, etc. is what makes behavior detection difficult.

Of note:

Quote

Rhadamanthys is written in C++. It evades detection by operating in system memory and by creating a mutex to ensure that only one instance is running. It uses the Al-Khaser anti-analysis tool to detect and avoid running in researcher sandboxes and virtual machines (VMs). Rhadamanthys is custom-packed with several stages that include dropping a custom loader DLL that decodes and executes an encoded payload via a command-line argument. The custom loader executes shellcode in a novel way by abusing the callback mechanism of the Windows CryptEnumOIDInfo() function and masquerades as a Nullsoft Scriptable Install System (NSIS) installer running the PrintUIEntry export

Edited July 17, 2023 by itman

[itman 1,746]

Let's again talk about the web site where these infected games are being downloaded from.

Refer to what I highlighted in the below screen shot;

You can "bet your booties" that these game uploads are not being screened for malware.

Again, common security sense must be exercised in regards to the source where a file is being downloaded from.

[itman 1,746]

Following up on my previous posting, I downloaded this previously posted: https://www.virustotal.com/gui/file/d4524f9c529ffd945c789b8379116b8bb6227de2ffa045729f47a4131f3d5cfb/detection from the game web site.

It was submitted to LiveGuard w/o any detection. The part to note in the submission log entry is where the game was actually downloaded from. These games are not actually being uploaded and hosted by itch.io. Rather, only the link to the "supposed" author's web site/cloud/storage/etc. download is being hosted:

Quote

Time;Hash;File;Size;Category;Reason;Sent to;User
7/17/2023 11:56:54 AM;10BFEAD0543C1DBB180C3D8008D937730E2B93A0;https://w3g3a5v6.ssl.hwcdn.net/upload2/game/2172247/8321817?GoogleAccessId=uploader@moonscript2.iam.gserviceaccount.com&Expires=1689609467&Signature=co4TeAYTMgvwR6xpLvYwYVrWPnYb/RKrjYz6uqyrQCt9EMQRRddyXpstRw5qKhl+KboIuCTIgXHFWNBEePZQiLC0xdDS380r59P/w5TXSCf3+MsNYaU9STwSpRBT7qEyWgZ16JleABrpMyS30bjfxQcDnT1ZZJWSK2zMGv1i6PzBZNArKebyNGGo7VK1RWfld4EpB03ln2wotKIhyXDy/vnzu0eEbkafqzaeAFEX9F+bl4WF5TzgDxGb73MoTI9zoUpBNSpL7O8Cwedkfa48zMge0ppvzkpPsrnDLv1EO2s7TDW7QSMtaNUpm5erFRzjueS70rcsOYDfn2G14oZ6tQ==&hwexp=1689609727&hwsig=e108469d2644237079f60139b6c7965;64891498;Executable;Automatic;ESET LiveGuard;xxxxxxx

Next, I locally scanned the download with zip Eset detections;

I can see how attackers are "having a field day" with gamer's who can't resist the opportunity to "get something for nothing."

-EDIT- There also appears to be other malware activities associated with this Google Cloud storage account: https://any.run/report/6857acac418d2ef0d1f70e1a84400c88516451dd356409bfed59935544d0f767/da825112-8a53-4fd9-846e-e59a023298aa#top

Edited July 17, 2023 by itman

[itman 1,746]

Later yesterday, I did a full analysis of this RabbitCheecks.exe installer from the sample submitted to Hybrid-Analysis: https://www.hybrid-analysis.com/sample/d4524f9c529ffd945c789b8379116b8bb6227de2ffa045729f47a4131f3d5cfb which originally detected the infostealer malware. It also explains how this bugger was able to evade detection by most AV's.

When the installer initially executed in the CloudStrike Falcon sandbox, it didn't fully detonate and instead forced a system shutdown. Aggressive bugger CloudStrike Falcon is, this was enough to mark the .exe malicious. It was also enough for a CloudStrike analyst to do a further analysis on what is going on here. Three hours later, a second CloudStrike Falcon sandbox analysis was performed which fully revealed the embedded infostealer behavior.

The only malicious file discovered was nsis7z.dll which is a 7-Zip .dll. What is interesting is CloudStrike only classifies the .dll malicious in a Win 7 sandbox analysis, but not in a Win 10 one: https://www.hybrid-analysis.com/sample/b393f05e8ff919ef071181050e1873c9a776e1a0ae8329aefff7007d0cadf592 . This leads me to believe that the 7-Zip version used in these infostealer game installers is an older vulnerable version of 7-Zip. It is being exploited to inject the infostealer code at embedded archive extraction time.

This is a classic example of it the most important part of a malware attack is its delivery method.

Edited July 18, 2023 by itman

[itman 1,746]

Well, miracles can happen. In this case, many must die before one occurs.

Eset now detects RabbitCheecks.exe installer as malware.

[itman 1,746]

Since the infostealer used in some of these downloads was Epsilon, let's see how AV's fare in detecting it: https://www.hybrid-analysis.com/sample/9ba3cc639e9a93f13adb21207c103b684e753e4eaf191bb95be2468eadac433f . And sure enough, it uses nsis7z.dll.

 

Edited July 18, 2023 by itman

[Marcos 5,259]

nsis7z.dll is a legitimate very popular dll. It's clean and not subject to detection. In this case it was two js files inside an embedded archive which are malicious and are now detected.

[itman 1,746]

12 hours ago, Marcos said:

nsis7z.dll is a legitimate very popular dll. It's clean and not subject to detection.

That's true but that is not what's happening in these attacks.

First, note that nsis7z.dll version being flagged by CloudStrike is 19.0. It's source code can be downloaded from here: https://nsis.sourceforge.io/Nsis7z_plug-in . Modify it to include your malicious code. Since its an unsigned .dll, no problem.

As far as 7-Zip's use of nsis7z.dll, it creates it on the fly in a %Temp% sub-directory. Now hijack the .dll with your malicious version.

Or, the nsis7z code at SourceForge contains malware itself; something SourceForge warns about in regards to their code repositories.

Edited July 19, 2023 by itman

[SeriousHoax 87]

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. 

[itman 1,746]

1 hour ago, SeriousHoax said:

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. I

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 that could be deployed later. 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.

Edited July 19, 2023 by itman