First off: any reason to believe that your system has been compromised? If not, then the premise would be your system is clean. If you then configure CIS to Proactive, enable D+ for paranoid mode, treat unrecognized files as ‘untrusted’, enable all options in execution control, sandboxing enabled (all options checked except ‘automatically trust files from trusted installers’), and all options in monitoring settings checked will make one’s system a rather hard target indeed. This’ll most likely generate a lot of alerts at first, but the premise is: system clean, therefore conclusion: allow and remember WHATEVER anything wants to do.
This will essentially establish the security baseline for your system. Within a week virtually ALL alerts should dissappear. After the initial security baseline establishment, ANY alert is potential warning of an attack. The user is on their own recognizance to establish the veracity and integrity of any arbitrary process and its resource access request. if you don’t know what the process is, look it up on the Interwebs. When in doubt: block. Never remember a response, ie., allow or block (or treat as), unless you’;re absolutely CERTAIN to engrave that rule in stone. This is very very very important w/respect to SVCHost; block a critical system process and you can cripple Windows.
That being said, the foregoing notwithstanding, neverthelss and whatnot, SVCHost is a ■■■■■■ to get your brain around. AFAIC it is massively large potential security risk.
Succinctly: SVCHost is a services service. It should be hardened as soon as one is comfortable using CIS in paranoid mode and fairly intimate with normal processes occuring on ones system. Hardening SVCHost entails removing it from default CIS file-group Windows System Applications - which has carte blanche resource access permissions - and define SVCHost D+ rule with custom policy.
The first thing that one has to get their brain around for SVCHost is what is normal? This is easily enough ascertained by creating a script that one can access from the desktop:
Tasklist /FI "IMAGENAME eq SVCHOST.exe" /SVC
Save that line in notepad with CMD extension and create a shortcut on the desktop to wherever that files lives. Anytime SVCHost alert comes up - if it has a custom D+ policy (otherwise you’ll get NO alerts for it since CIS considers it by default to be God - run the SVCHost Process Tool and verify that it is sane. If it is sane then the assumption can be made that whatever it wants to do is legit.
How to determine SVCHost sanity: you don’t have to understand everything that’s displayed by the Process Tool, but you do have to instantly recognize something unusual. So what’s unuual?
- A service normally there that suddenly is missing
- A PID with no service listed
- A PID w/a previously not listed service appearing in the list
- a service listed w/no PID
The custom policy for SVCHost on my system entails:
17 run executable
114 protected registry keys
86 protected files / folders
And that with judicious use of wildcards in order to limit creation of rules.
Once the essential rules for SVCHost have been established, I hardly get D+ alerts for SVCHost. Only infrequently used OS process will generate an alert. It then becomes a judgement call whether to remember the allowed alert.
I prefer to keep certain resource accessing very close to the vest, i.e., I’m doing a very sensitive system maintenance operation and SVCHost needs permission: I allow it, but I want to be notified when that occurs otherwise. This is also VERY true of Explorer.
The worst part of keeping tabs on SVCHost is internet access. It phones home all over the place. The thing is all one can really do is keep your finger on its pulse via the SVCHost process tool and allow and remember the IP access.
Periodically what I do is maintain the firewall rules for SVCHost and put the IP addresses that were allowed into specific zones named for the IP address owner. This just reassures me that everything is indeed cool and I’ve not inadvertantly created some backdoor.
My SVCHost firewall rules contain 28 individual zones where outbound internet access is permitted. Each one of these zones has multiple IP address, ranges and/or subnets associated. Moreover, there are an additional 70 individual IP addresses needing to be incorporated in either an existing zone and into a new zone. It would not suprise me if there are ~500 individual IP address that are legitimate SVCHost outbound access.
But what I’ve established is that EVERY one of these IP addresses belong to an IP domain owner that exists on the internet backbone itself.
Hardening SVCHost is NOT entry level, but it can NOT be more heartily recommended.