Jump to content

Stealers not detected


Recommended Posts

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. 

Edited by SeriousHoax
Link to comment
Share on other sites

1 minute ago, SeriousHoax said:

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

These infostealers perform process injection.

Let's assume this malicious javascript code is what is being injected. Process code injection can occur multiple ways; direct .dll injection, reflective .dll injection, or my favorite, asynchronous reflective .dll injection. In asynchronous reflective .dll injection, you hook a thread in the target process which allows you to run a stand-alone malicious .dll.

Finally, assume these infostealers have anti-heuristic detection methods which is what real-time scanners use.

Link to comment
Share on other sites

A security research a while back developed a user mode version of the infamous Double Pulsar NSA-sourced kernel mode exploit. Works great. Run examples shown below. Four digit numbers shown are process id numbers;

Quote

DOUBLEPULSAR-usermode-injector.exe 1140 dopu-64bit-usermode-shellcode.bin MessageBox64.dll 1

DOUBLEPULSAR-usermode-injector.exe 3496 dopu-64bit-usermode-shellcode.bin reflective_dll.x64.dll 1 use_CreateRemoteProcess

DOUBLEPULSAR-usermode-injector.exe 7668 dopu-64bit-usermode-shellcode.bin reflective_dll.x64.dll 1

DOUBLEPULSAR-usermode-injector.exe 2964 dopu-64bit-usermode-shellcode.bin nightmare.dll 1

 

Edited by itman
Link to comment
Share on other sites

Let's take a different tack.

Kaspersky originally identified RabbitCheecks.exe installer as a Discord infostealer. A recent Discord infostealer floating around is Skuld: https://thehackernews.com/2023/06/new-golang-based-skuld-malware-stealing.html .

Skuld does inject malicious JavaScript code;

Quote

Artifacts analyzed by Trellix show that it's engineered to corrupt legitimate files associated with Better Discord and Discord Token Protector and inject JavaScript code into the Discord app to siphon backup codes, mirroring a technique similar to that of another Rust-based infostealer recently documented by Trend Micro.

The point to note is Kaspersky and other AV's based on Kaspersky such as Checkpoint were the only ones to ID this infostealer as Discord.

Now ponder this. What if this game installer actually contains multiple infostealer variants and serves up the infostealer appropriate to the Windows installation it is running on?

Edited by itman
Link to comment
Share on other sites

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;

Quote

The info stealer achieves persistent credential access by patching the installed Discord application.

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.

Edited by itman
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

4 hours ago, SeriousHoax said:

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

Refer to this article: https://www.trendmicro.com/en_us/research/23/e/rust-based-info-stealers-abuse-github-codespaces.html .

Checking the referenced IOC's, all the major AVs detect them. My conclusion is it by embedding infostealers in an installer appears to significantly reduce AV detection of them. This really is not a surprise. The same applies to other malware embedded in an installer.

I also still contend the issue with these downloaded installers is they are using a hacked version of NSIS.

Edited by itman
Link to comment
Share on other sites

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;

Eset_Rabbit.thumb.png.ac2d5c33f50db3ed0cb52c87f0432bcb.png

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

Edited by itman
Link to comment
Share on other sites

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;

Eset_Rabbit.thumb.png.ac2d5c33f50db3ed0cb52c87f0432bcb.png

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. 

Link to comment
Share on other sites

3 hours ago, SeriousHoax said:

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.

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;

Quote

Electron Bot gets its name because it uses the Electron library system for JavaScript programming. This library uses the Chromium (which runs web browsers like Google Chrome and Microsoft Edge) rendering engine and NodeJS to provide a programming interface for runtime execution. When running the infected software, it grabs a compressed payload from a remote server utilizing a faux extension, such as an image file extension, so anti-virus software will not see the file as dangerous. Once downloaded, the payload gets extracted and then run as another hidden Electron-based application in the background.

Mitigation;

Quote

So what can you do to prevent infection? Being wary of whatever you download wherever you download it from is always the first step. Though some applications may look legitimate, make sure you read carefully. For example, Temple Run is the proper name of the endless runner, while the addition of extra words to the title to hit the same search results is a common tactic for those wishing to deploy these attacks.

 
Edited by itman
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

33 minutes ago, SeriousHoax said:

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. 

I believe all Eset did was create a sig. for the JavaScript code. And, it would be a post-execution detection.

Edited by itman
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

1 hour ago, SeriousHoax said:

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.

Ponder this scenario.

As you posted;

3 hours ago, SeriousHoax said:

Electron based malware hiding malicious scripts in ASAR files has been around since 2021 at least.

Since the attack method is well known, let's use it as a diversion. Post a malicious script there, but its not the infostealer I am actually deploying. Looks like it worked since G-Data, Eset, and assumed other AV's have fallen for the ruse.

As I posted previously, infostealer payloads run extremely fast; no longer than a minute and most, in seconds.

Embedding malware in a installer gives the attacker the opportunity to do all kinds of stuff. Installer's run at elevated privledges and perform system modifications.

"I again say to thee," CloudStrike is right on this one and the culprit is a hacked NullSoft archiver/extactor.

Edited by itman
Link to comment
Share on other sites

As far as malicious use of NullSoft, this is an informative read;

Quote

The NSIS (Nullsoft Scriptable Install System) installer is more and more used by malicious actors
as a first unpacking stage. As it is open source (https://nsis.sourceforge.io/Download), it is a
convenient base for malware author to use and eventually modify.

https://www.gatewatcher.com/wp-content/uploads/2022/07/Malware_Analysis_NSIS_Packer_EN.pdf

Additional ref. here: https://thehackernews.com/2023/02/guloader-malware-using-malicious-nsis.html

Finally, a very recent game example;

Researchers have discovered a Trojanized Super Mario Bros game installer that delivers multiple forms of malware, including an XMR miner, SupremeBot mining client and Umbral Stealer. 

Quote

Attackers bundled the malicious code with a legitimate installer file named "super-mario-forever-v702e." Gamers are often targeted due to their powerful hardware, which is suitable for mining cryptocurrencies. The tampered NSIS installer file, "Super-Mario-Bros.exe," contains three executables: the legitimate Super Mario application, as well as the malicious executables "java.exe" and "atom.exe." When executed, the installer drops and launches the legitimate executable, while the XMR miner and SupremeBot run in the background. The malware connects to a mining server, gathers system information, establishes a connection to a command-and-control server, and retrieves an info-stealing executable that loads Umbral Stealer into memory.

https://www.acronis.com/en-sg/cyber-protection-center/posts/trojanized-super-mario-bros-installer-spreads-malware/

Of note is the last activity performed is to load the infostealer.

"You can lead the AV horse to water, but you can't make it drink."

Edited by itman
Link to comment
Share on other sites

Kaspersky also has an article on this Super Mario game hack with protection recommendations I am repeating here. I have highlighted and underlined the most important ones;

Quote

Finally, a few tips for gamers on how not to fall victim to cybercriminals:

  • Download games only from official sources. This is the only guaranteed way not to pick up something unpleasant.
  • If you’re looking to save money on games, there are safer methods than downloading pirated copies from shady sites and torrents.
  • Don’t fall for pie-in-the-sky promises. A long-awaited game will not be downloadable before its official release (not legally at least), while a non-existent version for your particular platform won’t materialize through wishful thinking.
  • Be careful when downloading and installing mods, and especially cheats — the latter are best avoided entirely, of course.
  • To guard against stealers, try not to save passwords in your browser. Better to use a reliable password manager.
  • And be sure to have installed on your gaming machine a robust solution with a special gaming mode that keeps you safe during play with no irritating slowdown.

 

https://usa.kaspersky.com/blog/mario-forever-malware-too/28556/

Also, Kaspersky has a separate article on the dangers of game mods.

Edited by itman
Link to comment
Share on other sites

To Eset, I recommend it "take a hard look" at SIGL: https://arxiv.org/pdf/2008.11533v2.pdf since;

Quote

Using a test corpus of 625 malicious installers containing real-world malware, we demonstrate that SIGL
has a detection accuracy of 96%, outperforming similar systems from industry and academia by up to 87% in precision and recall and 45% in accuracy.

More so, since one of its case studies was;

Quote

Malware Bundled with ESET AV Remover Installer. In § 2, we described a real-world attack scenario where the
user is phished to install a legitimate ESET AV Remover installer [55] bundled with malware.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

1 hour ago, SeriousHoax said:

So I changed the hash of the exe and ran it and there was no reaction from ESET.

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.

Edited by itman
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

50 minutes ago, SeriousHoax said:

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.

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.

Edited by itman
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 only way Eset is going to be able to read what is in a packed ASAR file is post-execution via its advanced memory scanner. I also still contend that whatever JavaScript Eset is detecting is not the infostealer. It is not uncommon for an attacker to embed multiple malware in these hacked installers as I posted previously.

Edited by itman
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...