but right now CF will cover any fileless threats currently extent without it.
I think you are talking about pseudo-fileless threats which are actually not fileless at all. A true fileless infection is fileless from beginning to end, whereas pseudo-fileless threats always rely on at least one filebased component, a dropper for example, which then establishes the actual fileless persistent infection. The filebased dropper can be stopped by all kinds of tools, like signatures, anti-executables, behavior blockers and of course Comodo's auto-sandbox.
When there is in fact no filebased component involved I sincerely doubt that CF, which sandboxes based on file-rating mechanisms, can protect you.
For example imagine you become the victim of an exploit attack. In this scenario the dropper can exist purely in memory, as shellcode or injected code originating from the initially exploited application. The fileless dropper then creates a fileless persistent infection. In this whole infection chain there is not a single filebased component involved and naturally there will be nothing for a filerating-based auto-sandbox to sandbox.
Malware don't need Coffee: Angler EK : now capable of "fileless" infection (memory malware)
Luckily this mechanism is mainly vulnerability dependent and thus exploit based. The chance of running into a true 0-day exploit which can smash through Edge's or Chrome's excellent own sandboxing mechanisms is almost nonexistent for home-users. The non-0-days can easily be averted by patching. This is why we don't see this more often.
Yet the possible future of Microsoft Office based macro malware shows another interesting non-exploit-based attack vector. See this presentation for further details:
OfficeMalware/Laughing_Mantis-NextGen-Office-Malware-Hushcon-2016.pptx at master · glinares/OfficeMalware · GitHub
The pseudo-fileless stuff that comes in form of an e-mail attachment, which makes up probably almost 100% of all fileless threats we encounter, is taken care of easily by the aforementioned protection mechanisms. The true fileless threats should be covered by (list not complete):
- Sandboxie, which already sandboxes the initially exploited application, hence all memory based dropper activities are contained as well.
- AppGuard's guarded app and inheritance principle. AppGuard may not stop the shellcode from running or parent-to-child code injection attacks, but if the initially exploited application is running guarded, the application itself and all it's child process will run guarded and thus cannot establish a fileless persistent infection.
- HitmanPro.Alert's excellent exploit and hollow process detection mechanisms.
- Possibly Excubits MemProtect, but that depends on the configuration and attack mechanism. If the initially exploited application has to be allowed access to itself in order to function, it can spawn another instance of itself, inject the dropper into that and then the dropper can establish the fileless persistent infection
- HIPS rules can be created to restrict the initially exploited application from creating autoruns or injection code into other applications
Of course you could argue that you could run the initially exploited application also inside Comodo's auto-sandbox, but with all the restrictions in place, that would probably lead to a malfunction of that app more sooner than later.
All that being said, the chances of becoming the victim of a true fileless infection is very slim at the moment, but I assume this will change in the future, though primarily for corporations. For home-users, there is currently no immediate need to protect against this.