Win64.Vools.L Can not be cleaned

[kamiran.asia 5]

Hi dears,

Many Of our customers are infected by Win64.Vools.L today !!!

We know that Patch MS1701 is not installed and it will spread via this security hole. But in this situation that Servers and Clients are infected what is the best solution ?

We find these problems in Endpoint Antivirus and File Security versions.

[itman 1,743]

Are you referring to MS17-010: https://support.microsoft.com/en-us/help/4012598/title which was patch for SMBv1 on Win Server 2008 OS?

[itman 1,743]

If none of the network devices have been patched against the SMBv1 vulnerability, the first mitigation step must be to apply the appropriate patch to all devices.

It appears the source of the attack is unknown at this point. Without the source being identified, the attacker will in all likelihood perform a subsequent attack against the network nullifying all previous virus infection removal efforts.

[kamiran.asia 5]

4 hours ago, itman said:

Are you referring to MS17-010: https://support.microsoft.com/en-us/help/4012598/title which was patch for SMBv1 on Win Server 2008 OS?

Yes we patched the servers and clients but problem is still persist,

Even we block all incoming 445 and 139 ports to prevent trojan spreading .

after startup eset detect vools trojan in svchost.exe in operating memory and ask for restart for cleaning, after restart again this loop will happen over and over. 

[JamesR 58]

Which version of ESET is installed?  If not on v7.x, you will want to upgrade to v7.x ASAP as it has Network Attack Protection which can block EternalBlue (MS17-010) and help prevent reinfection and assist in identifying IP addresses that are attacking computers on your network.  This will also help you verify if this infection is spreading via a network exploit or not.  From everything you have posted so far, I see no hard evidence of exploitation via MS17-010.

Also, if you can provide logs using ELC (https://support.eset.com/kb3466/?locale=en_US&viewlocale=en_US) this can help identify what is occurring.  When running ELC, please set the top drop down list to "Threat Detection".

[itman 1,743]

Since the malware is being detected in svchost.exe, my best guess the malware has created a service in the registry and set it to start at boot time. If you can find the service, it most likely have an .exe associated with it. When you find the malicious service besides deleting it, the .exe should also be removed.

Another possibility is the malware is injecting one of the running svchost.exe processes since Eset is detecting the malware via AMS. The older OS versions are vulnerable to svchost.exe injection methods. This type of attack would require another .exe or script running at boot time to perform the activity. So registry autorun keys and Win program startup directories will need to be reviewed for any suspicious entries.

Edited March 19, 2019 by itman

[kamiran.asia 5]

We are working on these infection cases.

in This Case EFS V7.0 is installed and no network attach is detected after upgrading to V7. MS17-010  Patched are installed.

@itman is right we also think that an autorun or script is infecting svchost.exe .

 

 

 

Edited March 20, 2019 by kamiran.asia

[kamiran.asia 5]

It seems that our company support team detect the source injector of this infection and by Fast detection of ESET Lab the problem is solved now.

Detection rate at This time is 2/69

https://www.virustotal.com/gui/file/7bb2038642bb918081c55b19287731b4c30d62e1d1e67eff6d11ccd46ab7b331/detection

[itman 1,743]

Appears to me, the clients got nailed by a true 0-day malware. Also, it appears Eset created a new signature for this bugger, Win64/Vools.P.

It is encouraging that Eset was still able to detect it via AMS using a prior variant DNA signature.

BTW - what was the source of the svchost.exe injection?

[kamiran.asia 5]

2 minutes ago, itman said:

Appears to me, the clients got nailed by a true 0-day malware. Also, it appears Eset created a new signature for this bugger, Win64/Vools.P.

It is encouraging that Eset was still able to detect it via AMS using a prior variant DNA signature.

BTW - what was the source of the svchost.exe injection?

Yes a 0-Day malware !

A Service with a Dll injector "FunctionRPCHelper.dll" that inject svchost.exe

😎

[itman 1,743]

4 hours ago, kamiran.asia said:

Also the ESET Log Collector for "Threat Detection" is uploaded here :

https://we.tl/t-6uj838LHR5

FYI - advise you delete that log from web sharing site you uploaded it to. Or, alternatively password protect it or secure it by some other means.

For future reference, post all future log requests to the forum; only Eset mods have access to these. Or, PM them to the requestor as an attachment.

Edited March 20, 2019 by itman

[itman 1,743]

3 minutes ago, kamiran.asia said:

A Service with a Dll injector "FunctionRPCHelper.dll" that inject svchost.exe

Looks like I was right in my assumption.

I would still perform forensics in hope of discovering what was able to create the Win service. Look for traces of script execution; most likely PowerShell, using sc.exe. Ref.: https://support.microsoft.com/en-us/help/251192/how-to-create-a-windows-service-by-using-sc-exe .

[itman 1,743]

Another way the attacker could have created the service is using reg.exe which will allow for direct modification of the registry. It can also be run remotely if the remote registry service is running on the target device. Ref.: https://attack.mitre.org/techniques/T1112/ .

[itman 1,743]

A good example of sc.exe malicious use is the "Honeybee" malware that has attacked S.E. Asia humanitarian aid organizations in the past. Honeybee is delivered via malicious macro in a Word document.

Note: if you open the McAfee article reference, Eset HTTPS filter will throw an alert. Appears it is detecting some example code on the web page as malware -EDIT- the below .bat scripts is what Eset is detecting. I had to repost them as a .png attachment: 

Quote

The batch files involved in the attack modify the system service COMSysApp to load the malicious ipnet.dll. The contents of the batch files vary depending on the OS (x64 vs x86):

The batch files perform these tasks:

•Stop the service COMSysApp
•Configure the service to autostart (to set up persistence on the system)
•Modify registry keys to launch the DLL using svchost.exe
•Specify the malicious DLL path to be loaded into the svchost process.
•Immediately restart the service
•Remove the batch files to reduce the fingerprint on the system

IPNet.dll runs as a service under svchost.exe.

The malicious DLL is also responsible for terminating the cliconfg.exe process and deleting the malicious NTWDBLIB.dll using:
cmd /c taskkill /im cliconfg.exe /f /t && del /f /q NTWDBLIB.DLL

All the following capabilities described are implemented by the malicious service DLL implant unless specified. 

https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-uncovers-operation-honeybee-malicious-document-campaign-targeting-humanitarian-aid-groups/

Edited March 20, 2019 by itman

[kamiran.asia 5]

thank you @itman

I forward your useful post to our support team.