Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
Video Reviews - Security and Privacy
Grandmother sent me an Email
Message
<blockquote data-quote="FleischmannTV" data-source="post: 595001" data-attributes="member: 23687"><p>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.</p><p></p><p>When there is in fact no filebased component involved I sincerely doubt that CF, which sandboxes based on file-rating mechanisms, can protect you.</p><p></p><p>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.</p><p></p><p><a href="http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html" target="_blank">Malware don't need Coffee: Angler EK : now capable of "fileless" infection (memory malware)</a></p><p></p><p>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.</p><p></p><p>Yet the possible future of Microsoft Office based macro malware shows another interesting non-exploit-based attack vector. See this presentation for further details:</p><p></p><p><a href="https://github.com/glinares/OfficeMalware/blob/master/Laughing_Mantis-NextGen-Office-Malware-Hushcon-2016.pptx" target="_blank">OfficeMalware/Laughing_Mantis-NextGen-Office-Malware-Hushcon-2016.pptx at master · glinares/OfficeMalware · GitHub</a></p><p></p><p>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):</p><p></p><ul> <li data-xf-list-type="ul">Sandboxie, which already sandboxes the initially exploited application, hence all memory based dropper activities are contained as well.<br /> <br /> </li> <li data-xf-list-type="ul">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.<br /> <br /> </li> <li data-xf-list-type="ul">HitmanPro.Alert's excellent exploit and hollow process detection mechanisms.<br /> <br /> </li> <li data-xf-list-type="ul">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<br /> <br /> </li> <li data-xf-list-type="ul">HIPS rules can be created to restrict the initially exploited application from creating autoruns or injection code into other applications</li> </ul><p></p><p>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.</p><p></p><p>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.</p></blockquote><p></p>
[QUOTE="FleischmannTV, post: 595001, member: 23687"] 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. [URL='http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html']Malware don't need Coffee: Angler EK : now capable of "fileless" infection (memory malware)[/URL] 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: [URL='https://github.com/glinares/OfficeMalware/blob/master/Laughing_Mantis-NextGen-Office-Malware-Hushcon-2016.pptx']OfficeMalware/Laughing_Mantis-NextGen-Office-Malware-Hushcon-2016.pptx at master · glinares/OfficeMalware · GitHub[/URL] 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): [LIST] [*]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 [/LIST] 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Top