Ransomware infection again

[QuickSilverST250 0]

6 hours ago, TISec-Roland said:

Sorry for piggybacking on this thread. Will the HIPS only work if the rules are applied? Are there no default rules that HIPS uses after its enabled?

Wondering the same thing but it seems in auto mode HIPS is active as i did see some hips alerts with testing etc, also if you look on the endpoint an din HIPS logs you can see entries en there but would be nice to know if there are eset approve settings for additional protection

[itman 1,717]

Here's any.run.com's analysis of 005bffc8c94940c91159902d9b52971bcb26fa30602b05aa86e8721be49f405e.exe: https://app.any.run/tasks/ed05f8f9-a37a-4bb6-b502-376ecdceeb2a/ . You will observe that it spawns sub-processes with those in turn, spawning additional sub-processes.

I stick with my contention that this was the "driver" mechanism in this attack and was able to execute 00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47.exe, Phobos ransomware, in a manner that was undetectable by Eset. Also, this Phobos sample was first seen in-the-wild per VT on 6/1. Again, the question if Eset had a detection for it on 6/4 when the OP did his initial testing.

Edited June 18 by itman

[Marcos 5,157]

45 minutes ago, itman said:

I stick with my contention that this was the "driver" mechanism in this attack and was able to execute 00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47.exe,

The file has been detected since 2019 so should an injection occur, something else undetected would have to inject it at which point it would be very likely detected by the Advanced Memory Scanner.

[itman 1,717]

14 hours ago, QuickSilverST250 said:

I did also suspect maybe 005 but when i did the test on the vm on the left this confirmed it was the sample suspected, but it only encrypted the eek folder

Refer to the sample analysis at Malware Bazaar. At the bottom of the web page it showed a behavior analysis. The .exe does have encryption capability. I suspect its purpose was to encrypt existing security solution files rendering them unusable thereafter.

[Marcos 5,157]

4 minutes ago, itman said:

Refer to the sample analysis at Malware Bazaar. At the bottom of the web page it showed a behavior analysis. The .exe does have encryption capability. I suspect its purpose was to encrypt existing security solution files rendering them unusable thereafter.

The thing is if a file is detected and blocked in the first place, it's not executed and cannot do anything on the system. There would have to be something else that would inject it into other processes for instance.

[itman 1,717]

@QuickSilverST250 a strong recommendation here.

If your going to test Eset in a VM, make damn sure it is the only security solution installed there. Otherwise, you open the door for plausible deniability by conflict with Eset from the other security solution. 

[itman 1,717]

Just now, Marcos said:

The thing is if a file is detected and blocked in the first place

It wasn't at the time of the OP's original testing since his screen shot shows it running.

[Marcos 5,157]

5 minutes ago, itman said:

It wasn't at the time of the OP's original testing since his screen shot shows it running.

That's actually the weird thing about it:

ESET Command-line scanner, version 11.0.2032.0, (C) 1992-2023 ESET, spol. s r.o.
Module loader, version 1040 (20240125), build 1111
Module perseus, version 1589 (20220428), build 2293
Module scanner, version 20050 (20190920), build 42832
Module archiver, version 1349 (20240424), build 1463
Module advheur, version 1228 (20240105), build 1248
Module cleaner, version 1249 (20240325), build 1399

Scan started at:   Tue Jun 18 16:26:45 2024
name="test\00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47", result="a variant of Win32/Filecoder.Phobos.C trojan"

[itman 1,717]

1 minute ago, Marcos said:

That's actually the weird thing about it:

I'm not questioning Eset sig. detection of the Phobos sample. I will accept that it appears to be a Crysis/Dharma variant and Eset had a smart sig. detection for that variant.

What I am stating is at the time of the OP's original testing, 005bffc8c94940c91159902d9b52971bcb26fa30602b05aa86e8721be49f405e.exe was not detected by Eset.

I suggest Eset test with 005bffc8c94940c91159902d9b52971bcb26fa30602b05aa86e8721be49f405e.exe  sig. detection removed and log every thing it does. Also, this testing must be done from OP's original malware collection since 005bffc8c94940c91159902d9b52971bcb26fa30602b05aa86e8721be49f405e.exe from that collection has been conditioned in some way to bypass Eset sig, detection of 00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47.exe, Phobos ransomware.

[Marcos 5,157]

We still don't know if the OP was able to reproduce the encryption with Malwarebytes completely removed.

[itman 1,717]

11 minutes ago, Marcos said:

We still don't know if the OP was able to reproduce the encryption with Malwarebytes completely removed.

The only way this can be retested is the OP has to reload Eset detection module back to Jun 4. Or, create a detection exclusion for 005bffc8c94940c91159902d9b52971bcb26fa30602b05aa86e8721be49f405e.exe;

Quote

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
6/17/2024 11:19:00 AM;Real-time file system protection;file;C:\Users\xxxxxxx\Downloads\005bffc8c94940c91159902d9b52971bcb26fa30602b05aa86e8721be49f405e.exe;a variant of Win64/TrojanDownloader.Agent.AUO trojan;cleaned by deleting;xxxxxxxx;Event occurred on a new file created by the application: C:\Program Files\7-Zip\7zG.exe (69DEB494A366940463D41383EB019F54F593B680).;8DB94ABC30A3F6DDC3CE330DADCE5DA27DDEED5F;6/17/2024 11:18:37 AM

 

[TISec-Roland 0]

7 hours ago, QuickSilverST250 said:

Wondering the same thing but it seems in auto mode HIPS is active as i did see some hips alerts with testing etc, also if you look on the endpoint an din HIPS logs you can see entries en there but would be nice to know if there are eset approve settings for additional protection

Thanks for the response. I am actually exploring the Endpoint Security product and playing around with the settings and rules. Seems like I actually have to do some testing with real malware samples to figure this out. But thanks for sharing your experience, if there were already some alerts without manually adding rules, then maybe there are already hidden HIPS rules. It would be nice if someone from ESET actually confirms this.

Thanks again and best of luck in fixing your issue!

 

[QuickSilverST250 0]

1 hour ago, itman said:

@QuickSilverST250 a strong recommendation here.

If your going to test Eset in a VM, make damn sure it is the only security solution installed there. Otherwise, you open the door for plausible deniability by conflict with Eset from the other security solution. 

Yes, sure noted. The Malwarebytes on the machine is the free version so no real time protection was on, but i understand that maybe the drivers running could cause issues. I will remove it with the test going forward.

[itman 1,717]

1 hour ago, QuickSilverST250 said:

The Malwarebytes on the machine is the free version so no real time protection was on

Reviewing MalwareBytes, it's ransomware protection is part of it's real-time processing. With that disabled, I don't see a conflict but who knows ..............

[itman 1,717]

Another factor not discussed is if your Win version in the VM is fully patched?

Malware including ransomware will always prefer to deploy via exploit if it can find a vulnerability on the target device.

Picus has a good write up on Phobos ransomware: https://www.picussecurity.com/resource/blog/phobos-ransomware-analysis-simulation-and-mitigation-cisa-alert-aa24-060a . A few excerpts from it;

Quote

Privilege Escalation

T1055 Process Injection

Phobos threat actors use an open-source tool named Smokeloader for process injection. Smokeloader injects malicious code into legitimate processes like explorer.exe and allows adversaries to bypass defensive security controls.

Quote

T1562 Impair Defenses 

Phobos threat actors disable the system firewall using the commands below. Additionally, they use tools like PowerTool, Process Hacker, and Universal Virus Sniffer to impair and evade defenses.

Quote

T1001 Data Obfuscation & T1105 Ingress Tool Transfer

Phobos threat actors use Smokeloader to obfuscate C2 communication by producing requests to legitimate websites and downloading additional malware to the compromised system.

Edited June 18 by itman

[QuickSilverST250 0]

Yes, i always make sure, it's Win 11 23H2 that i use on all tests. Think i did not do the optional updates but the rest are done.

[itman 1,717]

@QuickSilverST250 I finally reviewed the video.

You need to determine what privileges 00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47.exe, Phobos ransomware, was assigned. If it was running with System privileges and assigned Protected Process Light status, Eset wouldn't be able to touch it. 

Assigning System privileges is trivial. I have a utility on my device that can assign those privileges to any .exe.

Edited June 18 by itman

[itman 1,717]

I noticed something interesting in the video. There are two instances of the Phobos ransomware loaded with one being a child process at the start of the encryption activity;

Shortly thereafter, the child process instance is terminated.

Clearly, some process modification activities were going on. Determining what those were is key to understanding how Eset sig. detection was bypassed.

Maybe this will point in the right direction;

https://insertidhere.medium.com/phobos-ransomware-analysis-54119367b1d1

Edited June 18 by itman

[QuickSilverST250 0]

Interesting, thank you for that. Yes, it does seem to spawn another child process. The account used is a local admin account with UAC enabled, i don't run the script with additional admin privileges but the account does have main permissions.

 

Maybe this is a new version with different hash and maybe that the sig was useless and evaded the other layers of protection. As it was eventually blocked via signatures although it took long for this to be stopped.

 

Do you think i should restore to older sig database and disconnected the machine, so it has no access to livegrid and test again?

[Marcos 5,157]

The LiveGrid reputation system should be enabled all the time. Also not enabling the LiveGrid Feedback system would keep certain protections in the Ransomware shield inactive due to security reasons.

[itman 1,717]

2 hours ago, QuickSilverST250 said:

Do you think i should restore to older sig database and disconnected the machine, so it has no access to livegrid and test again?

I already posted what needs to be done: https://forum.eset.com/topic/41364-ransomware-infection-again/?do=findComment&comment=185805 . Also, Eset probably has a full sig. detection for 00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47.exe now. So you will have to exclude that also. Best if you test with Eset Protection module dated 6/4; the date of your original test.

I also stronger suggest that Process Monitor be started just prior to running the Phobos ransomware sample collection which will record system activities of what is being executed. You can stop Process Monitor once 00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47.exe starts encrypting files. You can then forward the Process Monitor log file to Eset.

Edited June 19 by itman

[itman 1,717]

5 hours ago, itman said:

00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47.exe

As far as the Phobos ransomware itself, below are two full sandbox analysis of it run on June 4. Eset should be able to figure out from those how its ransomware shield was bypassed;

https://www.hybrid-analysis.com/sample/00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47/665f2b317419a9e54d00deaf

https://app.any.run/tasks/f405b8bd-0d63-4aad-881f-ff2349713376/

As I see it, the issue here is not the failed Eset sig, detection, but the ransomware shield detection failure.

[Marcos 5,157]

59 minutes ago, itman said:

As I see it, the issue here is not the failed Eset sig, detection, but the ransomware shield detection failure.

Should the file had been scanned at all, it would be first detected by the smart signature. Only undetected files are further analyzed by HIPS Deep Behavior Inspection / Ransomware shield. Both the LiveGrid reputation system and LiveGrid feedback system affect detection and cleaning capabilities of both HIPS-based protection modules. We still don't know how removing the Malwarebyte's drivers affected the Phobos detection.

[itman 1,717]

@QuickSilverST250 is it possible you still had the folder where the malware samples were stored still excluded from Eset real-time detection at the time you did your initial Phobos ransomware sample/s testing?

[itman 1,717]

38 minutes ago, Marcos said:

Only undetected files are further analyzed by HIPS Deep Behavior Inspection / Ransomware shield.

It's a given that 00723db8c6513a9b8a79b8b8cc7d9da9f23a8a5454149ed12768937ca15d1a47.exe wasn't detected by sig.. If it was detected, OP's execution script would have never been able to access the file let alone load it.