It’s been remarkably busy here for a Friday… I did get a chance to work up some rules to lock down svchost.exe a bit more. So, here goes.
In the Application Rules, click on the line for svchost.exe to highlight it, and then move it to the very top first rule. No chance for a rule override there.
It probably has only one rule in place, to allow outbound traffic. What follows will replace that rule. So things can be undone later, the existing rule(s) will be kept, but nothing will be executed. It’ll take advantage of the rule ordering.
The new rules to insert (and I’ll watch the spacing this time)
- allow IP Out from IP Any to IP In[12.183.0.0/255.255.0.0] where protocol is any
- allow IP Out from IP Any to IP In[224.0.0.0/240.0.0.0] where proto is any
- allow IP Out from IP Any to IP In[127.0.0.0/255.0.0.0] where proto is any
- allow IP Out from IP Any to IP In[65.52.0.0/255.240.0.0] where proto is any
- allow IP Out from IP Any to IP 255.255.255.255 where proto is any
- block&log IP Out from IP Any to IP Any where proto is any
7+ (these are the existing rules which will never be used - see rule 6)
What this will do, is to limit svchost.exe to talking only to your ISP address space (12.183.0.0), localhost (127.0.0.0), any routing and boot special addresses (224.0.0.0 and 255.255.255.255), and Microsoft auto updates (65.52.0.0).
Anything else will get blocked by that rule 6. That should make it very very hard for malware to get out.
Then, change the setting in Firewall → Advanced / Firewall Behavior Settings to be “Custom Policy Mode”
As the malware tries to get out, you’ll probably get a lot of alerts.
If need be, a default application rule can be put in to block anything that doesn’t have explicit rules. I haven’t worked that up yet, and it may not be needed. It depends on what kind of alerts you get, and what the alerts can tell you about where the malware is coming from in pathnames.
Edit: Added the rule needed for Windows auto update to work.