H

hjlbx

Hello,

NOTE: If anyone sees problem with this suggestion, please let me know. It has been working fine on my system without any problems.

Quick-Guide.

Problem:

Malware writers produce some clever, malicious scripts that can use Windows interpreters (cmd.exe, wscript.exe, cscript.exe, powershell.exe, java.exe, etc.) and other files for nefarious purposes.

Typically, this involves an internet connection to download malwares.

If you use a firewall, then you can reduce some risk by setting the firewall to "Prompt/Alert/Notifiy" for connection attempts made by the following:

cmd.exe
wscript.exe
cscript.exe
java.exe
rundll32.exe
powershell.exe
powershell_ISE.exe

NOTE: On 64-bit systems need to make firewall rules for above files located in both System32 and SysWOW64 folders.

For convenience I create remote IP address specific firewall rules for these files. For example, PowerShell Help connects to various Microsoft servers to install and update the help files. So I allow connect to those Microsoft servers by inputting their IP address into rule.

Using this method I've caught sneaky network connects... plus it at least gives you notification even when the remote IP address is not in the malicious URL database.

Notable example would be the JS.Encoder\Secured.BAT Vault sample posted on MalwareTips' Malware Hub by @Petrovic.
 
Last edited by a moderator:
H

hjlbx

Hello @hjbx, and thank you for this important guide the doctor would certainly have ordered ..if he only knew!:D
That's the problem with File-Rating systems used by AV vendors like, for example, Emsisoft, Kaspersky and ESET.

Those interpreters are "Allowed." Malware writer know this and use it to their advantage.

IMHO those files should be assigned custom rule sets by the AV vendors that use file-rating to automate rule creation in their software.

Alerting on network connect attempts enables attentive user to prevent one of scripts' primary means to get malwares onto the system.
 
Great guide Hjlbx, ya I've been doing this since few months ago, it is very true most av are automatically allowed these and make an advantages for malware writers, better safe than sorry. Can't imagine if malware writers do this on our machine..he can do everything since these files are whitelisted and allowed by most av/firewall :eek:. I always set my smart firewall to always prompt/alert these :confused:
I didn't know about the optional ones till now, so Thanks :)
 
Last edited:
H

hjlbx

Great guide Hjlbx, ya I've been doing this since few months ago, it is very true most av are automatically allowed these and make an advantages for malware writers, better safe than sorry. Can't imagine if malware writers do this on our machine..he can do everything since these files are whitelisted and allowed by most av/firewall :eek:. I always set my smart firewall to always prompt/alert these :confused:
I didn't know about the optional one till now, so Thanks :)
The optional ones are all command line interfaces.

I am not sure if tricky malware connects via one of those interfaces whether a firewall alert would be generated by cmd.exe or the interface itself. Honestly, not sure.

But I do know all the other ones need to be watched for sneaky connects.
 
H

hjlbx

Hi & thanks for guide,

I cannot find powershell.exe or powershell_ISE.exe in Windows 8.1 x64 in either the System32 or the SysWOW64 folders.
Just navigate to System32 and SysWOW64 folders.

Type "powershell" in the Windows Explorer search field (the one with the magnifying glass in the upper right-hand corner).

They will show up in the list.
 

marzametal

Level 7
Verified
Does svchost.exe from the SysWOW64 folder ever get used? So far I have only seen System32 referenced in firewall connections log...

EDIT: creating a firewall rule for the x64 version didn't kick up a warning, but did for the x86 version... curiouser and curiouser...
 
H

hjlbx

Does svchost.exe from the SysWOW64 folder ever get used? So far I have only seen System32 referenced in firewall connections log...

EDIT: creating a firewall rule for the x64 version didn't kick up a warning, but did for the x86 version... curiouser and curiouser...
I think in some cases it does... I've seen it on my system - where SysWOW64 interpreters are active.

I've been trying to get a more definitive answer.

I know NVT ERP protects all interpreters in both System32 and SysWOW64 directories. The developer would not go through the trouble if it was not necessary for complete security.
 

marzametal

Level 7
Verified
I think in some cases it does... I've seen it on my system - where SysWOW64 interpreters are active.

I've been trying to get a more definitive answer.

I know NVT ERP protects all interpreters in both System32 and SysWOW64 directories. The developer would not go through the trouble if it was not necessary for complete security.
As a precaution, I added a block rule in firewall... haven't tried NVT ERP again for a while... might revisit it.
 
Top