Ransomware infection

[QuickSilverST250 0]

Hi, we logged a ticket with our region support team and no one has come back to us. We tested new samples in our VM environment, and we have ransomware infection.

We tested the same samples for our 24 hrs period and they keep getting infected, we submitted the samples but somehow ESET is still unable to stop this infection.

As I'm making this post, the infection just happened again, please see below our info to tech support:

Hi,

Hope you are doing well.

 

In our testing environment, on my VM I was testing some new samples, I noticed a text file drop on the desktop and immediately suspected ransomware.

once I navigated to Documents/Pictures etc I noticed the file ext have changed to .TE8ZZUVLN

 

 

 

I have made a recording on how the VM is currently looking and you can find the logs collected with the profile assigned to the endpoint:

 

 

I did mention we will not shutdown so we can collect the logs, but the VM did shutdown on its own after I stopped the recording. The logs collected are from after the VM started up again.

 

We then run the same test on our VM with XDR, here are the info for this VM:

 

Here is the screenshot of our VM that has XDR on it:

 

We collected logs from the VM also after a restart as it was nonresponsive, and we struggled over an hour to try and get the logs but no luck so we restarted it..

It looks like it’s this sample that’s caused the infection:

 

062683257386c9e41a1cd1493f029d817445c37f7c65386d54122fa466419ce1.exe

 

 

 

Shows ESET on VT as detected but seems it’s not.

 

 

We have the info in our XDR, we are investigating on our end but let us know what info you need from the XDR.

 

We also runt the same malware hours later our other VM running ESET Smart Security Premium and suffered to the same fate.

 

Please let us know what info is needed and how this infection was possible.

 

 

 

Edited April 26 by Marcos
Redacted: Link removed

[JamesR 52]

Hello,

I tested and verified that file with hash 062683257386c9e41a1cd1493f029d817445c37f7c65386d54122fa466419ce1 is already detected as "Win32/Filecoder.BlackMatter.O".

I do have a few questions:

• Can you verify what "detection engine" version is on your ESET Endpoints? Latest should be 29130
  • Open ESET on an endpoint, and go to "Update", then click "Show All Modules".
• Can you verify if you were hit with ransomware, or are you just testing samples?
  • If you were hit with ransomware, then it means your network was compromised days prior to the ransomware deploying.  Modern ransomware attacks begin as an adversary gaining access to your network, then living off the land to move around the network.  Some methods of compromising a network, do not need any malware (RDP/RDS, SMB are just a few examples of services which can commonly lead to a full network compromise).  You should be looking for signs of user accounts performing suspicious activity inside of Inspect (XDR).
  • If you are simply performing tests, then you need to focus on verifying ESET is activated and updating and that you have not created exclusion which would prevent ESET from detecting samples.

[Marcos 5,090]

It looks like that most files are detected. Many of them are not ransomware. At least some if not all undetected files are clean, we'll check them out.

I have doubts that they all come from an infected system since it's a mix of Windows PE files and Linux ELF files. There's also a GameHack detection among the file set which is surely not malicious.

0da3f18d4b0f96c36d59f5c619d2aeefa7cc83290b0a8077170a1415063a7862.elf	a variant of Linux/Mirai.CEA trojan
44b285e42398b11a5e3939f6092db161b0e0ab9cce1962d0f8e7e453ec52b04f.elf	a variant of Linux/Mirai.CEA trojan
4a7768dbfab5529f147bd69c389b1aadc067355c0f28f1c09531dc131ec9250f.elf	a variant of Linux/Mirai.CEA trojan
4c4ca68c0d1c13caadbd019d1e06d931083204adae3f56395f0f35e83a2eba34.elf	a variant of Linux/Mirai.CEA trojan
5e455f9f5b3098bc140eceafcb830cf027d45b7ae7021c0612fb3026788601b4.elf	a variant of Linux/Mirai.CEA trojan
b3ddea0c4d25df77c7248808b6bacf27c446e8cd0e3f77a11ef3b473fc752e43.elf	a variant of Linux/Mirai.CEA trojan
d5a4748e56180f5a6e2af83e692b41a9579107d5030155f0595ca00a580a64fd.elf	a variant of Linux/Mirai.CEA trojan
edca4bc9921a016e48b8b30b0caa9a185628a0509af50fed5c80d86dbe841007.elf	a variant of Linux/Mirai.CEA trojan
6a91ec0aee3b05c509dacafc3f0e3ec680b19db469db0737ceffdaa75d32a08e.elf	a variant of Linux/Mirai.CEH trojan
ce747d87f3805e50067214a9fc38452fcaaed89567b1998627cc526d0665e8a1.elf	a variant of Linux/Mirai.CGA trojan
7628ace4f2627bc65377a8123ce9e05849e4e4b3fd5b862e03ffcee42274ccfb.exe	a variant of MSIL/GenKryptik.GWYV trojan
5d6a67ab649ed8610da623191e8925e4804c9d0eb424b8f50be64b20c098a890.exe	a variant of MSIL/Injector.FCD trojan
a5b0d190fc09cd5c1ea07fa6b12a7dd4ab5f517c778fb60e4e14060e00ddecc8.exe	a variant of MSIL/Kryptik.AJTQ trojan
31b494be325fc9c97031135886454b1370e5e3608c757f74784c6b6fb2fb5c99.exe	a variant of MSIL/Kryptik.ALLQ trojan
e62d890d90cb121e7fb678dea021786d5558ba433bc1499580b3e327bc85e847.exe	a variant of MSIL/Spy.Agent.DTP trojan
62c2c1f7335ed8b0a2120b1cf42a4c55cae1869a0245bef10d51de037e0d7ddf.exe	a variant of MSIL/Spy.RedLine.A trojan
9545ddef182171d1fd3a8e74fb6ba72614b7ca243aa70c7425157f5d0ec9963e.ps1	MSIL/Spy.RedLine.B trojan
64a71b664d76641b35dac312161cb356b3b3b5f0b45c9d88c8afa547b4902580.exe,a variant of Win32/ClipBanker	AGen.J trojan
062683257386c9e41a1cd1493f029d817445c37f7c65386d54122fa466419ce1.exe	a variant of Win32/Filecoder.BlackMatter.O trojan
1ecea8b0bc92378bf2bdd1c14ae1628c573569419b91cc34504d2c3f8bb9f8b2.exe	a variant of Win32/Filecoder.BlackMatter.O trojan
f0cc3d397a4670c6dba01bb870d7ae1d07df27d2d3817d3f8c2d7140e3f5557f.dll,a variant of Win32/Packed.PrivateEXEProtector	AGen.A suspicious application
652e2c35d36d4b96fdda843b6339c185eab3263b0b8acdb6349df240d1b9f8e4.dll	a variant of Win32/Packed.VMProtect.AAH trojan
a3ebc58cb7aebd21137225e16f6686642708e665fceb1f77e54c2413f6c0e706.exe	Win32/PSW.Fareit.L trojan
495a744f783348c8a6ef1c048ea3e62d3903b00c66e9be21bb374d59d18b682e.exe	a variant of Win32/Spy.Agent.PRG trojan
e7a503f0a7bc1acf71034abc36329b1733f0b67aa6e07bd06688bfd9e333e871.exe	a variant of Win64/HackTool.GameHack.Q trojan

A detection for 67DD4AC7EB8C193B39149B34D3A0D5BC21C3F200 (@Trojan.Win32/Filecoder.BlackMatter) was added in July 2022.

[QuickSilverST250 0]

As mentioned, we use this vm to test malware so there are all kinds of samples being detonated, doubt as you might the machine is infected non the less.

[itman 1,668]

Are you running a VMware ESXi server?

[QuickSilverST250 0]

11 minutes ago, JamesR said:

Hello,

I tested and verified that file with hash 062683257386c9e41a1cd1493f029d817445c37f7c65386d54122fa466419ce1 is already detected as "Win32/Filecoder.BlackMatter.O".

I do have a few questions:

• Can you verify what "detection engine" version is on your ESET Endpoints? Latest should be 29130
  • Open ESET on an endpoint, and go to "Update", then click "Show All Modules".
• Can you verify if you were hit with ransomware, or are you just testing samples?
  • If you were hit with ransomware, then it means your network was compromised days prior to the ransomware deploying.  Modern ransomware attacks begin as an adversary gaining access to your network, then living off the land to move around the network.  Some methods of compromising a network, do not need any malware (RDP/RDS, SMB are just a few examples of services which can commonly lead to a full network compromise).  You should be looking for signs of user accounts performing suspicious activity inside of Inspect (XDR).
  • If you are simply performing tests, then you need to focus on verifying ESET is activated and updating and that you have not created exclusion which would prevent ESET from detecting samples.

Hi James, thank you for the reply. As mentioned, this is a VM for testing samples, we have everything up to date, detection engine was 29130 during the test we did a short while back. We are testing it now on a new VM with engine 29131 and seems fine now and looks like it's being detected, just a shame it took over 24hrs for this to be detected. I could be wrong in regarding the ransomware that might be responsible for the encryption as that's the only one we can see XDR flags as ransomware, once i upload the note and sample to id ransomware, says it's unable to determine the type. We did this on 2 x EES and 1 Eset home premium vm.

[QuickSilverST250 0]

3 minutes ago, itman said:

Are you running a VMware ESXi server?

NO, Hyper-V for our testing VM's against malware.

[Marcos 5,090]

I assume that it's not an environment that would simulate real use of the system. I assume that protection was paused when you copied malware to the machine? In a real-world scenario, users don't pause protection when they copy or download files.

[QuickSilverST250 0]

Just now, Marcos said:

I assume that it's not an environment that would simulate real use of the system. I assume that protection was paused when you copied malware to the machine? In a real-world scenario, users don't pause protection when they copy or download files.

The way we did this test was: From a server location, malware in protected zips, we extract the zips to a folder that has our script to execute the malware, we extract the malware to this folder with the protection ENABLED. We allow ESET to quarantine the malware as it's being extracted, once the extraction process is done, we then run our script to execute what's left and this will be windows, linux and android files. Once the test is done and the left over samples, we manually submit them just incase they weren't.

[itman 1,668]

7 minutes ago, QuickSilverST250 said:

We allow ESET to quarantine the malware as it's being extracted, once the extraction process is done, we then run our script to execute what's left and this will be windows, linux and android files.

Assumed what was left over was a reverse shell; etc.  that downloaded the ransomware again with subsequent execution.

[Marcos 5,090]

I've extracted the ransomware file from an archive and it was immediately detected and removed:

[QuickSilverST250 0]

3 minutes ago, itman said:

Assumed what was left over was a reverse shell; etc.  that downloaded the ransomware again with subsequent execution.

Could be as when the infection took place i could not really see in PE the payload or could be remote infection

[QuickSilverST250 0]

1 minute ago, Marcos said:

I've extracted the ransomware file from an archive and it was immediately detected and removed:

We had the same notifications, again i could be wrong in which sample caused the infection but was working in XDR and this one stood out, it could have been any one of them that started with 0 "zero" in file name as it goes in sequence and it was around 06 when we noticed the infection

 

[itman 1,668]

Notice reference to feswa.exe in Process Explorer screen shot.

Next refer to this very recent malware analysis of it by Joe's Cloud Sandbox: https://www.joesandbox.com/analysis/1431142/0/html#443628CBE77F47C6E613C90CF1B449051BF2 . What is running on your test device might be a new undetected variant.

[QuickSilverST250 0]

1 hour ago, itman said:

Notice reference to feswa.exe in Process Explorer screen shot.

Next refer to this very recent malware analysis of it by Joe's Cloud Sandbox: https://www.joesandbox.com/analysis/1431142/0/html#443628CBE77F47C6E613C90CF1B449051BF2 . What is running on your test device might be a new undetected variant.

I've scanned the VM with XDR now after it updated to the latest engine, this is the screenshot, it seems it was black matter that infected:

[itman 1,668]

Let's theorize a bit.

Your malware sample contained a 0-day version of Redline Stealer malware which ran when you executed "the other stuff" in your malware sample. Redline Stealer steals device credentials.

Attacker accesses your VM using the stolen credentials and executes a remote ransomware attack: https://www.scmagazine.com/resource/remote-ransomware-what-is-and-how-to-stop-it . Bottom line - your files are not being encrypted on the target device but on an un-managed/unprotected device on the local network. Target device files are copied to the un-managed device. The copied target device files are encrypted on the un-managed device and then copied back to the target device replacing the original files.

Edited April 27 by itman

[itman 1,668]

Let's complete the theorizing with one example of how this remote ransomware attack payload could be delivered. Also, let's assume the unprotected/un-managed target local network device is an infrequently used old Win 7 PC which has no Internet connectivity but local network connectivity. The naive belief being that without Internet connectivity, the device didn't require active antivirus protection.

Attacker accesses VM using stolen credentials. He downloads a password protected archive to the VM containing the ransomware. Eset can't scan password protected archives. He then copies the archive to the unprotected Win 7 PC; extracts the archive; and then installs the ransomware.

[Nightowl 205]

Thank you bro for explanations , was good for me @itman

[QuickSilverST250 0]

On 4/27/2024 at 1:18 AM, itman said:

Let's theorize a bit.

Your malware sample contained a 0-day version of Redline Stealer malware which ran when you executed "the other stuff" in your malware sample. Redline Stealer steals device credentials.

Attacker accesses your VM using the stolen credentials and executes a remote ransomware attack: https://www.scmagazine.com/resource/remote-ransomware-what-is-and-how-to-stop-it . Bottom line - your files are not being encrypted on the target device but on an un-managed/unprotected device on the local network. Target device files are copied to the un-managed device. The copied target device files are encrypted on the un-managed device and then copied back to the target device replacing the original files.

Yes, this makes sense if you have an environment where other devices comes into your network with free av or infected and might spread to your devices. If all all devices run ESET then this is something that ESET missed.

[QuickSilverST250 0]

22 hours ago, itman said:

Let's complete the theorizing with one example of how this remote ransomware attack payload could be delivered. Also, let's assume the unprotected/un-managed target local network device is an infrequently used old Win 7 PC which has no Internet connectivity but local network connectivity. The naive belief being that without Internet connectivity, the device didn't require active antivirus protection.

Attacker accesses VM using stolen credentials. He downloads a password protected archive to the VM containing the ransomware. Eset can't scan password protected archives. He then copies the archive to the unprotected Win 7 PC; extracts the archive; and then installs the ransomware.

Yes, this can happen and even i would say is possilble from a NAS device or similar.