.vbs script zero day

[Nightowl 198]

Hello , please check this sample , I sent also from my email

https://www.virustotal.com/gui/file/ce0e2c758444ae6e3be95b83e0f53990e722472e75113d57b18a19cb8e397ca9?nocache=1

 

[TRACK#64EAFA9300F7].

 

EDIT : Support answered.

Edited August 27 by Nightowl

[Nightowl 198]

Solved

Edited August 28 by Nightowl

[Nightowl 198]

Is there anyway to prevent *.VBS and *.PIF from being downloaded , received from Skype/Whatsapp etc ?

[itman 1,602]

I don't know about download prevention via Eset. But based on this posting: https://superuser.com/questions/1582309/received-a-possible-malware-vbs-on-skype-and-ran-it , these .vbs scripts are being run via Powershell.

If you are employing Eset recommended anti-ransomware HIPS rules, one of those is to block any script startup from PowerShell. Also, these rules include blocking any child process startup from wscript.exe.

Finally, this SuperUser posting examle might be invoking wscript via PowerShell .Net subassembly capability. That is prevented by setting PowerShell to Constrained Language mode.

As far as restricting what file types can be downloaded by Skype, it would be great if Eset had this feature: https://knowledge.broadcom.com/external/article/158783/prevent-exe-downloads-from-skype-using-a.html .

Edited August 28 by itman

[Nightowl 198]

18 hours ago, itman said:

I don't know about download prevention via Eset. But based on this posting: https://superuser.com/questions/1582309/received-a-possible-malware-vbs-on-skype-and-ran-it , these .vbs scripts are being run via Powershell.

If you are employing Eset recommended anti-ransomware HIPS rules, one of those is to block any script startup from PowerShell. Also, these rules include blocking any child process startup from wscript.exe.

Finally, this SuperUser posting examle might be invoking wscript via PowerShell .Net subassembly capability. That is prevented by setting PowerShell to Constrained Language mode.

As far as restricting what file types can be downloaded by Skype, it would be great if Eset had this feature: https://knowledge.broadcom.com/external/article/158783/prevent-exe-downloads-from-skype-using-a.html .

I will try to do it through Fortinet filters.(hardware firewall)

Thank you bro.

  

  

18 hours ago, itman said:

If you are employing Eset recommended anti-ransomware HIPS rules, one of those is to block any script startup from PowerShell. Also, these rules include blocking any child process startup from wscript.exe.

 

I will try to google for best practices/hardening and take a look

Thanks for suggestions

Should also block Python,Firefox,Chrome,VLC,7zip,rar from running from AppData/TEMP or creating new applications from there like that remcos variant that brought it's vulnerable exes with it

I think in first place , since powershell , cmd is prevented , the next step of the vulnerable exes shouldn't come , but who knows

Anyone have suggestion?

Edited August 29 by Nightowl

[itman 1,602]

Here's something else you can explore; Software Restriction Policies (SRP).

SRP is already preconfigured to block most Windows executable format and additional file extensions can be added as needed. Also PIF extension is already including in the list.

Next is these restrictions apply to designated Windows directories. The below screen shot shows I am applying these restrictions to %Temp% directory via disallowing them;

As to applying the above in regards to your Skype ,vbs issue and for that matter, all other executable code downloads, perform the following.

1. It appears the default download location for Skype is the Downloads directory. Create a new directory/folder to be used for Skype downloads.

2 Change the default Skype download directory to the new directory you created as shown here: https://www.technobezz.com/how-to-change-a-default-download-folder-on-skype/ .

3. Create a new SRP path rule specifying the full path specification for the new directory you created. Set its Security Level to Disallowed.

I assume the same capability to change default download location also exists WhatsApp, etc..

Also, SRP saved my butt when some .cmd script attempted to run at Win logon time; apparently from the registry;

Of note is I have an Eset HIPS rule to monitor all cmd.exe startuo and it didn't catch this.

Edited August 29 by itman

[Nightowl 198]

11 hours ago, itman said:

Here's something else you can explore; Software Restriction Policies (SRP).

SRP is already preconfigured to block most Windows executable format and additional file extensions can be added as needed. Also PIF extension is already including in the list.

Next is these restrictions apply to designated Windows directories. The below screen shot shows I am applying these restrictions to %Temp% directory via disallowing them;

As to applying the above in regards to your Skype ,vbs issue and for that matter, all other executable code downloads, perform the following.

1. It appears the default download location for Skype is the Downloads directory. Create a new directory/folder to be used for Skype downloads.

2 Change the default Skype download directory to the new directory you created as shown here: https://www.technobezz.com/how-to-change-a-default-download-folder-on-skype/ .

3. Create a new SRP path rule specifying the full path specification for the new directory you created. Set its Security Level to Disallowed.

I assume the same capability to change default download location also exists WhatsApp, etc..

Also, SRP saved my butt when some .cmd script attempted to run at Win logon time; apparently from the registry;

Of note is I have an Eset HIPS rule to monitor all cmd.exe startuo and it didn't catch this.

I was looking at it yesterday (SRP) , but your explanation is better than what I was reading , I will give this one a try , and apply it to specific folders like Downloads , TEMP etc. and will see what happens

About Downloads location , I bet I can keep it there , I just put the wanted extentions to be blocked

Thank you bro.

Edited August 30 by Nightowl

[itman 1,602]

If you decide to use SRP, I strongly advise you read this article: https://4sysops.com/archives/mitigating-powershell-risks-with-constrained-language-mode/ . In a nutshell, you add PS1 and PSM1 to the list file extensions SRP monitors for.

Many are currently deploying the registry environment variable hack to set PowerShell to Constrained Language. As the article notes, its trivial for a hacker to bypass this hack method.

[Nightowl 198]

11 hours ago, itman said:

If you decide to use SRP, I strongly advise you read this article: https://4sysops.com/archives/mitigating-powershell-risks-with-constrained-language-mode/ . In a nutshell, you add PS1 and PSM1 to the list file extensions SRP monitors for.

Many are currently deploying the registry environment variable hack to set PowerShell to Constrained Language. As the article notes, its trivial for a hacker to bypass this hack method.

Thanks for your assistance ITMAN

I will check it out.

I wish I had an easier route rather than messing with Microsoft's GPO