Win64/CoinMiner.PO

[Siloxo 0]

So it started like 2 days ago when a file called "wtf" started in the background. and now it shows as Win64/CoinMiner.PO  also as "explore.exe" Even when I clean it pops right back up after 1-2 hours.

[Marcos 5,074]

Please provide logs collected with ESET Log Collector for a start.

[itman 1,659]

What Windows OS version are you using?

The legit version of explorer.exe is loaded and started by winlogon processing at system startup time.

Appears something has created a scheduled task and it is attempting to load a hacked version of explorer.exe. Suspect other malware activity is occurring along the lines of process hollowing or like activity to explorer.exe. That is the malware is loading explorer.exe in a suspended state and injecting apparently coin miner code in to it. It then un-suspends explorer.exe allowing this hacked version to execute.

[SeriousHoax 83]

ESET really need to work on its removal engine. I heard that ESET don't use any correlation engine. So for malware removal it only delete the file itself and associated processes but can't delete registry items and important things like startup entries, scheduled task related to the malware, etc. Which explains how ESET deletes a malware in less than a second on average and how malwares often comes back through startup entries and scheduled tasks.  Some of the competitors are much better and even Windows Defender is 100% better than ESET at malware removal.

[Marcos 5,074]

2 hours ago, SeriousHoax said:

I heard that ESET don't use any correlation engine. So for malware removal it only delete the file itself and associated processes but can't delete registry items and important things like startup entries, scheduled task related to the malware, etc.

This is a wrong assumption. We clean malware from the system completely, including unregistering possibly malicious tasks from the system, WMI or autostart locations.

[SeriousHoax 83]

5 hours ago, Marcos said:

This is a wrong assumption. We clean malware from the system completely, including unregistering possibly malicious tasks from the system, WMI or autostart locations.

In my personal experience it didn't quite a few times. Eg: I executed a new sample for which ESET didn't have signatures and the malware created autorun and scheduled task. Few hours later ESET made a signature and detected the threat but the autorun and scheduled task remained. So looks like if ESET has the ability to delete registry entry, scheduled tasks then it doesn't work very well. 

[itman 1,659]

9 hours ago, SeriousHoax said:

In my personal experience it didn't quite a few times. Eg: I executed a new sample for which ESET didn't have signatures and the malware created autorun and scheduled task. Few hours later ESET made a signature and detected the threat but the autorun and scheduled task remained. So looks like if ESET has the ability to delete registry entry, scheduled tasks then it doesn't work very well. 

I believe what @Marcos stated in regards to cleaning activities applies if Eset detects the malware at execution time.

If Eset never detected the malware at first execution time, it would have no way of knowing what system modifications were made. Re-executing the malware again after first execution will in all likelihood result in different behavior by the malware. Assumed is it will not perform some or all of the previous system modification activities since they are no longer needed.

Did you recreate your VM test environment for each test from a totally pre-infected system state? Additionally, malware is becoming increasingly WM aware and will alter its behavior to reflect this state.

Then there is the question of if the same level of cleaning is performed for potentially unwanted as for a full malware detection.

Edited November 27, 2020 by itman

[SeriousHoax 83]

On 11/28/2020 at 4:03 AM, itman said:

I believe what @Marcos stated in regards to cleaning activities applies if Eset detects the malware at execution time.

If Eset never detected the malware at first execution time, it would have no way of knowing what system modifications were made. Re-executing the malware again after first execution will in all likelihood result in different behavior by the malware. Assumed is it will not perform some or all of the previous system modification activities since they are no longer needed.

Did you recreate your VM test environment for each test from a totally pre-infected system state? Additionally, malware is becoming increasingly WM aware and will alter its behavior to reflect this state.

Then there is the question of if the same level of cleaning is performed for potentially unwanted as for a full malware detection.

ESET can't but Windows Defender can.

Few hours ago I did a test again after you asked. This is the sample I used for the test.

https://www.virustotal.com/gui/file/57ffe59f3e0605df528abdabb18a0b191abf4bbd06808f61308796aa337bbd10/detection

First tested Windows Defender.
Disabled WD completely, extracted and executed the sample. Let it do its job. My main goal was to test startup entry and scheduled task removal. I saw that the malware had copied itself to Roaming and Roaming/Host folder including some other files, created a scheduled task to run at starup. I checked it in Task Scheduler and via that popular Autorun app.

Then I manually stopped all the malicious processes, enabled Real Time Protection of WD and let it sit idle for 2 minutes. Then I right clicked the original sample file and WD immediately detected and removed it after few seconds. Nothing was associated with this original file so scheduled task wasn't deleted.
I ran the "Autorun" app again to check scheduled tasks and immediately WD detected threats and removed everything after around 8-9 seconds.
The sample of Roaming and Roaming/Host folder was removed, scheduled task was removed, including related registry entries as you can see in this screenshot.

Now did everything in exact way for ESET by turning off all sorts of ESET's protection then enabled again. ESET removed the initial sample similarly. Then ran the Autorun app and unlike WD, ESET'S Real Time Protection didn't do anything. I manually browsed the Roaming folder, ESET deleted it, manually browsed Roaming/Host and ESET deleted it. In both cases ESET deleted the .exe file only. The scheduled tasks, registry entries etc remained.

So I like I said, ESET is not good at malware removal and something like Windows Defender can do proper cleanup removing additional entries even after post infection, even when the malware isn't actively running on the system.

So my assumption remained true. ESET basically remove the sample and active process associated with it. It doesn't look for anything else which is the reason how ESET delete every malware in a split second. Maybe it would do better if the threat was active but that wasn't my point anyway. ESET's removal engine don't do enough.

Products like Windows Defender, Bitdefender, Kaspersky and some others do further scanning to check for additional related entries like startup and scheduled tasks and remove those if required. They tend to take longer to remove malwares because of this.

Anyway, hopefully no one says that the Real Time Protection was disabled so this test is not valid, etc.
My intention was to check ESET'S removal ability not protection where Windows Defender succeeded but ESET failed.

[itman 1,659]

5 hours ago, SeriousHoax said:

Products like Windows Defender, Bitdefender, Kaspersky and some others do further scanning to check for additional related entries like startup and scheduled tasks and remove those if required. They tend to take longer to remove malwares because of this.

As I recollect, older versions of WD were also quite effective at removing residual malware traces. Reason? WD's signatures used to suck big time until they finally farmed that out to a third party a while back. As such, once a sig. was created, appears Microsoft created in essence "metadata" associated with the malware to find system modifications once the malware was discovered on a device.

Kaspersky deploys system snapshot capability that will rollback system modifications. However, there is a performance degradation associated with that processing.

As a rule, most current AVs suck at after the fact malware detection clean up. They emphasis front-end initial malware detection instead.

One thing Eset could do is provide a "cleaning" tool such as Comodo has which is designed to detect residual malware traces and entrenched malware.

Eset does have its  System Cleaner tool. However this just compares current to default Windows installation settings. Great unless you have made numerous system setting changes. Also my gripe about this tool is it doesn't display detail in regards to what changes were made.

Last but not least is Eset's SysInspector tool. It probably is the least understood Eset feature of all. I did find an article on its use stating this tool should be run right after an initial Windows install and the results saved. Then later if needed, the tool can be run again and that result compared to the initial clean system scan.

[Marcos 5,074]

We'll look into it. To me it looks like the malware somehow bypasses the system API to register tasks since it's not visible in the Windows Task Scheduler but in Autoruns it is.

[SeriousHoax 83]

3 hours ago, itman said:

As I recollect, older versions of WD were also quite effective at removing residual malware traces. Reason? WD's signatures used to suck big time until they finally farmed that out to a third party a while back. As such, once a sig. was created, appears Microsoft created in essence "metadata" associated with the malware to find system modifications once the malware was discovered on a device.

You are right about it I think. Few days ago someone was also telling me that WD has always been good at malware cleanup since the early MSE days.

 

3 hours ago, itman said:

Kaspersky deploys system snapshot capability that will rollback system modifications. However, there is a performance degradation associated with that processing.

Nowadays according to AV-Comparatives and AV-Test Kaspersky is actually showing better performance than ESET and even in practice it is very light. But because of the rollback feature it probably use some CPU in background because a user on Malwaretips was saying that his laptops battery die out faster with Kaspersky compared to ESET & Bitdefender.

 

3 hours ago, itman said:

As a rule, most current AVs suck at after the fact malware detection clean up. They emphasis front-end initial malware detection instead.

It's true. Stopping a threat in the first place is more important so removal is less important nowadays. An already infected system should use separate tools provided by some vendors specially made for malware cleanup. But still ESET should do better. I'm sure you have often seen complaints here on the forum about ESET continuously blocking malware at system startup/browser startup and failing to remove completely. With a better removal engine many of those problems can be reduced I think. But that may slow down removal speed so don't think ESET will make any change here.

 

3 hours ago, itman said:

One thing Eset could do is provide a "cleaning" tool such as Comodo has which is designed to detect residual malware traces and entrenched malware.

Yes this should be great since system cleaner tool and system inspector is kind of pointless. 

[SeriousHoax 83]

3 hours ago, Marcos said:

We'll look into it. To me it looks like the malware somehow bypasses the system API to register tasks since it's not visible in the Windows Task Scheduler but in Autoruns it is.

It was visible in my system I can assure you that. I didn't capture the screenshot but it was there. I checked it first before checking Autoruns in both WD & ESET cases.

[itman 1,659]

Here's my take on what is going on with this malware based on the posted WD screen shot of what was cleaned.

The malware is actually starting from a HKCU run key. This in effect is a UAC bypass since the bugger will run even under a standard user account. It appears the next step is it sets up the scheduled tasks and then dynamically invokes task manager to run those tasks.

I believe the only reason a scheduled task related to this bugger shows in the posted Autoruns screen shot is Eset detected and deleted the app that eventually would have removed the scheduled task shown.

 

Edited November 29, 2020 by itman

[SeriousHoax 83]

6 hours ago, itman said:

Here's my take on what is going on with this malware based on the posted WD screen shot of what was cleaned.

The malware is actually starting from a HKCU run key. This in effect is a UAC bypass since the bugger will run even under a standard user account. It appears the next step is it sets up the scheduled tasks and then dynamically invokes task manager to run those tasks.

I believe the only reason a scheduled task related to this bugger shows in the posted Autoruns screen shot is Eset detected and deleted the app that eventually would have removed the scheduled task shown.

 

ESET deleted the file when I right clicked on it and scan with ESET. Unlike WD where it automatically removed everything as soon as I opened Autoruns. The screenshot shows file not found because the file isn't there. The scheduled task itself is still there. ESET didn't do anything to remove that. The files in the Roaming/Host folder was also not touched by ESET until I manually scanned but WD automatically deleted that too even though I manually didn't browse/scan that folder. ESET just deleting file itself, that's it.

[itman 1,659]

14 hours ago, SeriousHoax said:

ESET deleted the file when I right clicked on it and scan with ESET. Unlike WD where it automatically removed everything as soon as I opened Autoruns.

Let's again review your test procedure:

On 11/29/2020 at 5:14 AM, SeriousHoax said:

Then I manually stopped all the malicious processes, enabled Real Time Protection of WD and let it sit idle for 2 minutes. Then I right clicked the original sample file and WD immediately detected and removed it after few seconds. Nothing was associated with this original file so scheduled task wasn't deleted.
I ran the "Autorun" app again to check scheduled tasks and immediately WD detected threats and removed everything after around 8-9 seconds.

It appears that WD is "monitoring' Autoruns results. This makes sense since both are Microsoft base products.

You then repeated the same procedure and expected Eset to trigger on Autoruns findings. Namely, the found Autoruns entries flagged and associated with this malware. 

The main point to emphasis here is WD's real-time behavior was identical to Eset's in regards to the original detection and removal of the malware sample. It was only after Autoruns was executed did WD become aware of the malware related registry and scheduled task entries and removed them.

The average user would not be knowledgeable to Autoruns and its use. Therefore if he was using WD, those malware traces would remain on his device.

Edited November 30, 2020 by itman

[itman 1,659]

It also appears that there is a fundamental misunderstanding among the amateur malware testers over at malwaretips.com.

All AV's perform hueristic; i.e. sandbox, analysis on a process. If during this analysis which is relatively short in duration the malware makes system modifications, those changes can be reversed. If for whatever reason the system modifications cannot be directly associated with malware payload execution detection, it is not possible to reverse those changes when the payload executes.

Now there is a unique feature of WD which is its cloud scanning of unknown executable's. This scan time can be extended up to one minute in duration; a relatively long sandbox analysis time. This capability gives WD an edge in recording actions associated with the malware including system setting modifications.

Edited November 30, 2020 by itman

[SeriousHoax 83]

14 hours ago, itman said:

Let's again review your test procedure:

It appears that WD is "monitoring' Autoruns results. This makes sense since both are Microsoft base products.

You then repeated the same procedure and expected Eset to trigger on Autoruns findings. Namely, the found Autoruns entries flagged and associated with this malware. 

The main point to emphasis here is WD's real-time behavior was identical to Eset's in regards to the original detection and removal of the malware sample. It was only after Autoruns was executed did WD become aware of the malware related registry and scheduled task entries and removed them.

The average user would not be knowledgeable to Autoruns and its use. Therefore if he was using WD, those malware traces would remain on his device.

You totally misunderstood. By original sample I meant the sample that I had on desktop. That original source had no direct connection to malwares in the Roaming and Roaming/Host folder so both WD and ESET deleted this file alone. 

But when the file in Roaming folder was accessed by WD it found out that this malware has correlation to scheduled task so it deleted that and related registry entries.  The point is that WD's engine can look for that while ESET didn't even bother and deleted the file alone. Like I said, ESET deletes everything in a split seconds, it didn't look for any correlation while WD took its time to check for those. 

There's no logic to defend ESET here. It's plain and simple what happened here. I'll try checking the same with Kaspersky which is also known to be very good at malware removal. 

[SeriousHoax 83]

Tested Kaspersky and the result is same as Windows Defender. After infection I simply browsed the folder where malware is located and Kaspersky deleted everything. WD even deleted the folder in Task Scheduler while Kaspersky kept the folder which is blank but the task itself has been deleted so the system is clean.

Before:

After:

 

So, my point about ESET still stands. It can't remove malwares properly. There should be no excuse here. It needs to get better at this. Otherwise the type of infection the OP posted will keep coming back.

[itman 1,659]

9 hours ago, SeriousHoax said:

But when the file in Roaming folder was accessed by WD it found out that this malware has correlation to scheduled task so it deleted that and related registry entries.  The point is that WD's engine can look for that while ESET didn't even bother and deleted the file alone.

I assume this is the .exe that was responsible for creating the scheduled task and registry entries. I don't know if you are running WD with default settings which is a 30 sec. cloud scan time or, have manually modified it to the max. 60 secs..  In any case, the scan time was sufficient to reveal the noted system modification activities.

I have made past postings in this forum that it would be "wonderful" if Eset could somehow interface with WD's block-at-first-sight processing. It sits as a front-end to WD's main real-time engine just like the AMSI interface does. Doubt Microsoft would allow this. As it stands right now, one's only Eset like solution is to purchase Endpoint Security or Anti-virus which have a mininum seat (5) requirement. Then purchase an ESET Dynamic Threat Defense subscription. Obviously, this is not an acceptable home user solution. 

Edited December 1, 2020 by itman

[itman 1,659]

5 minutes ago, SeriousHoax said:

It needs to get better at this. Otherwise the type of infection the OP posted will keep coming back.

Actually, this is not true.

As your posted Autoruns screen shot shows although the scheduled task still exists, execution of it will error out since the file its trying to execute has been deleted by Eset.

[SeriousHoax 83]

1 hour ago, itman said:

I don't know if you are running WD with default settings which is a 30 sec. cloud scan time or, have manually modified it to the max. 60 secs..  In any case, the scan time was sufficient to reveal the noted system modification activities.

The default value is 10 sec. But that has nothing to do with this detection or removal. The sample is already detected by WD by local signature so no additional cloud analysis is required and also WD shows a notification when it does that extra cloud checkup which happens for new files only that are not known to WD. I have seen that quite a few times after downloading new safe/infected files.

Like I said, WD was disabled before the execution of malware. I not only disabled Real Time Protection, but also disabled it by the Defender Control tool.

I also tested Kaspersky to show that both have the ability to remove malware properly post infection. They looked for anything directly associated with the malware, they found its connection to scheduled task, registry entries so deleted those. ESET didn't/can't. All it did was remove the exe file.

I can also test the same for Bitdefender but that's not necessary as I have prove my point already.

1 hour ago, itman said:

Actually, this is not true.

As your posted Autoruns screen shot shows although the scheduled task still exists, execution of it will error out since the file its trying to execute has been deleted by Eset.

It's not good enough because for some samples, it happens that the user will see an error every time that scheduled task is run. Also you said about OP that there's probably a scheduled task that's causing this. So if ESET could delete the scheduled task and other related items then this probably wouldn't have happened.

[itman 1,659]

5 hours ago, SeriousHoax said:

Also you said about OP that there's probably a scheduled task that's causing this. So if ESET could delete the scheduled task and other related items then this probably wouldn't have happened.

You missed my point. Since the .exe was detected and removed by Eset, leaving the schedule task residual that ran that .exe in place would cause not later harm.

I also again want to reiterate my totally disagreement with the "infected" status leveled at malwaretips.com because malware residuals exist. Rather it should be examined after the test what residuals still exist and if those are still of a malicious nature. In this category would be for example, residuals that would still allow access to the attackers C&C server and the like.

Edited December 1, 2020 by itman

[SeriousHoax 83]

6 hours ago, itman said:

You missed my point. Since the .exe was detected and removed by Eset, leaving the schedule task residual that ran that .exe in place would cause not later harm.

I also again want to reiterate my totally disagreement with the "infected" status leveled at malwaretips.com because malware residuals exist. Rather it should be examined after the test what residuals still exist and if those are still of a malicious nature. In this category would be for example, residuals that would still allow access to the attackers C&C server and the like.

Non malicious residuals usually gets "Not clean" status instead of "Infected". But some testers often don't mark that properly. Those rules are mostly made by earlier members and I'm not testing malwares there anymore either. Anyway, that's a totally different topic.

ESET needs to improve malware removal but pretty sure that's not going to happen.