Popup 95.153.31.18 blocked

[khairulaizat92 9]

Hi and good day to all,

One of my client has been infected by certain unknown malware, might be zeroday malware as i already tried to scan the whole laptop with various choice of AV. 

The sign of infection is that theres something in the laptop keep requesting for this ip address and url:

95.153.31.18

95.153.31.22

bellsyscdn.com

And ESET block all of it, but when the whole scan are made, eset didnt find any malware.

And if possible, i hope this can be solved asap. If you need Teamviewer, let me know.

Thanks in advance for your assistance

[itman 1,808]

Using SysInternals TCPView or Eset's network connections tool, you need to ID the process attempting to connect to that IP address.

I assume this is an inbound connection being blocked? If it's an outbound connection, hopefully its a stand alone process. You can use Win Task manager or ideally Process Explorer to determine what is running. PE will show if network connections are taking place. 

Edited November 7, 2017 by itman

[khairulaizat92 9]

30 minutes ago, itman said:

Using SysInternals TCPView or Eset's network connections tool, you need to ID the process attempting to connect to that IP address.

I assume this is an inbound connection being blocked? If it's an outbound connection, hopefully its a stand alone process. You can use Win Task manager or ideally Process Explorer to determine what is running. PE will show if network connections are taking place. 

Theres might be problem with SysInternals Software, somehow it cannot be launch on the infected PC. Which is weird. There are some files which seems to make the request, but its a legitimate microsoft program (Maybe) 

"Microsoft Windows Based Script Host". But maybe in my opinion might be legitimate process that hijack by something.  

[khairulaizat92 9]

Attach is the log generated by Eset SysInspector

SysInspector-FAKHRIYAYA-171107-090313.zip

[khairulaizat92 9]

Anyone? 

[itman 1,808]

For the time being, create the following HIPS rule and give it the following name;

User rule: block wscript.exe startup

Then do the following:

1. Action - block; checkmark - Applications

2. Logging severity - Diagnosis. Do not checkmark "Notify user" or you will bombard with alerts.

3. Source applications - All applications

4. Application operations - Start new appliactions

5. Click add tab for Specific applications. Then select, C:\Windows\System32\wscript.exe and C:\Windows\SysWOW64\wscript.exe.

6. Click on the Finish button.

7. Click OK and any subsequent prompt to save the rule.

The above rule will block any execution of wscript.exe. Unless you use it to run any scripts you have created, it won't have any adverse impact. When examining your HIPS log file, it will show what process is trying to run wscript.exe.

Based on your screen shots, the malware is being run from the shown sub-directory in %AppData%\Roaming. Deleting that sub-directory will stop the malware from running. Before doing that you need to find what is starting processes in that directory. Most likely a registry Run key but could also be a task scheduled to run at startup. Or the malware could have created a service and set it to run automatically at boot time.

-Important- before deleting the sub-directory in %AppData%\Roaming it should be zipped up and e-mailed to Eset for malware analysis. It is obvious Eset is not removing what is running from that sub-directory.

 

Edited November 7, 2017 by itman

[JamesR 58]

Using your sysinspector, I found the following info:

1. Both mrwdaasmd64.exe and pdrws.exe are copies of wscript.exe (this will prevent the HIPS rule ITMAN mentioned from stopping this infection)

2. You have a shortcut in your User's startup folder which is pointing to the pdrws.exe

 

To remove this infection from your computer, please do the following:

1. Run the command
taskkill /im emfnsqkj\mrwdaasmd64.exe /f & taskkill /im pdrws.exe

2. Rename the folder "c:\users\fakhriatulyaya\appdata\roaming\emfnsqkj" to "emfnsqkj_vir"

3. Move the shortcut file located in "c:\users\fakhriatulyaya\appdata\roaming\microsoft\windows\start menu\programs\startup\" into the "emfnsqkj_vir" folder (you might need to turn on viewing of "Hidden" and "System" files to see the shortcuts).  Check the "Properties" of any shortcuts to find the wone that is loading the "pdrws.exe"

4. Reboot your computer and verify detection stops occurring.

5. If all is well, generate an ESET Log Collector ( https://download.eset.com/com/eset/tools/diagnosis/log_collector/latest/esetlogcollector_enu.exe ) and place the generated .zip in the "emfnsqkj_vir" folder, then zip up and password protect the "c:\users\fakhriatulyaya\appdata\roaming\emfnsqkj_vir" folder.  Use the password "infected" without quotes, and submit the sample to samples@eset.com

 

Let me know if this helps.

[khairulaizat92 9]

Found it, thanks @itman it seems eset just release the update. And you HIPS rule what brought me directly to the source and trigger ESET to remove it from the client system.

hxxp://www.virusradar.com/en/update/info/16369

Its called JS/Bondat.BD

Still new though, not that many AV detects it;
https://www.virustotal.com/#/file/c08da81082d734723e89248f5b87e55f00ef1545cdde5e2d656ada88e487998c/detection

Thanks once again including @JamesR, with this, the case is closed

 

Edited November 7, 2017 by khairulaizat92

[itman 1,808]

4 hours ago, JamesR said:

1. Both mrwdaasmd64.exe and pdrws.exe are copies of wscript.exe (this will prevent the HIPS rule ITMAN mentioned from stopping this infection)

Interesting indeed. Never thought of that one. Malware getting cleverer with each passing day!

My question is why did Eset detected it as Windows script host and not by the malware .exe names? Is Eset looking at the PE header for ID? But it appears, HIPS only checks directory file name.

In any case, I have a HIPS ask rule to alert on any process startup in %AppData% directories. However in this instance, malware could have dropped the directory anywhere and ran it from there. Also one reason HIPS wildcard support for the retail vers. are desperately needed so a rule like C:\*\wscript.exe can be created. Also the HIPS needs to be checking the internal process name and not the directory name.

 

Edited November 7, 2017 by itman

[illumination 5]

18 hours ago, itman said:

Also one reason HIPS wildcard support for the retail vers. are desperately needed so a rule like C:\*\wscript.exe can be created. Also the HIPS needs to be checking the internal process name and not the directory name.

 

As of now, I run Appguard combined with EIS just for this very reason. The vulnerable services are disabled by AG on my system via wildcards. It would be nice to not have to use multiple products to do this. 

 

Edited November 8, 2017 by illumination

[itman 1,808]

FYI - I found a way to prevent a recurrence of a like malware attack using a renamed wscript.exe occurrence. Note this assumes you are not using SRP or AppContainer. If you are, refer to the linked SANS article for further details.
 

Quote

Before that you might but consider to use;
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings]
 "TrustPolicy"="2"

instead. This allows scripts signed by a trusted publisher to run while blocking all other scripts.

Quote

Regarding the registry settings for TrustPolicy and UseWinSAFER, I found another post on the web that states that if UseWinSAFER is set to 1, Windows will ignore the TrustPolicy setting. Thus, if you have UseWinSAFFER set to 1 but have not set Software Restriction Policies (which the article says is often the case) scripts will run regardless of the TrustPolicy setting.

The article was written in the Vista/Win7 era, so it's possible Microsoft has changed this behavior - but I wasn't able to find anything saying it has. Otherwise, the article says to set UseWinSAFER to 0 if Software Restriction Policies haven't been set.

Ref.: https://isc.sans.edu/forums/diary/Controlling+JavaScript+Malware+Before+it+Runs/21171

Note that you have to add the TrustPolicy reg setting as a Dword value.

This indeed does work per the below screen. I consider the possibility of malware using a signed script to be low:

Edited November 8, 2017 by itman