Okay now I see a factor causing some confusion from some of your posts. In-mem malware do not always need to inject dlls into its memory. surely, it will be convenient for attacker to inject dll into memory especially if he want to perform many malicious thing, but it's not necessary in every case, attacker can do nasty just from shell code which is written by machine language and I thought it was the case in FBI's Tor exploit. Well, that was very similar to the case which I argued here because it sent info via http request, one of common browser task. But I too am not sure about how major HIPS can prevent some sort of dll injection, from common remote dll injection to reflective dll injection, maybe someone using HIPS can test it by metasploit or such? EMET have Load Library protection which will prevent common remote dll injection, but does anyone know any HIPS implement such feature? And what about reflective dll injection, detecting it will requires "mess in the memory" with heuristic scan, including but not limited to permission check on heap and stack. I'm not sure aigle's test reached final payload execution as MBAE prevents it in earlier stage, but if it was IE will be active after closed. I personally think it wasn't and so still there would be a room that Comodo with paranoid mode might prevent it.
I regard anti-exploit as a memory version of HIPS. It just enforces its rule for activity in memory, maybe with whitelist, very similar to tasks done by classical HIPS toward process behavior, except that the stage is in memory. I don't understand why some folks call those in-mem malware as "advanced" or mitigation for them, in-mem is just in-mem, not necessarily advanced and what payload to use is just an option for attacker. Of course some in-mem malware used in APT are advanced but same goes for other APT malware. That seems to monitor some critical functions to execute payload and certain conditions met, e.g. the call is from uncommon place, prevents its execution.
They monitor all happens in the system, so if something, not care what kind of process, try to modify some system component, HIPS should block and eventually ask to ( if so configured ). So I believe, am I wrong ?
True if it try to modify system component. But malicious thing can be done w/out modifying system, it is this we're discussing now.
OK, I thought that launching IE would start new process. If old (lingering) process would be reactivated than that could cause a problem.
I honestly think that Chrome should also take care of downloaded executables and dlls as well, like Sandboxie does.
You would like to run downloaded executables inside Chrome's sandbox? How did you imagine that this would be achieved?
You specifically answered me this: So, MBAE protects more than Sbie does, and like you said Sbie cannot protect against them all, while MBAE can and does protect against them all, even though, they both protect against the same form of exploits, like you said, if I remembered correctly you said, that those exploits do not need payload to exploit browser and without payload, SBIE cannot protect against that (in-memory, fileless exploits without payloads) if I understood it right, while MBAE does protect against them. So, MBAE protect against everything and is on the first place, than followed by Google Chrome, which is on the second place and Sbie is on the third place, it only contains, and and it cannot protect and it cannot contain fileless memory exploits without payloads, but SBIE can and does contain the results the payloads of in-memory, fileless exploits-right?
What I'd like is to have option to block and disable those downloads and have the same option like you have in Sandboxie to be able to recover file if needed to and if you think it's malicious to keep it under Chrome's sandbox protection with all the restriction that Chrome sandbox offers (that includes both executables and .dlls).
Yes, but Chrome also has a built-in sandbox, that's why it is so secure, Google Chrome is by far the most secure of all web-browsers.
Yes, but Chrome is not a sandbox program. By using a sandbox program, you keep files that you download or introduce into your computer as untrusted. An untrusted file can not make changes to your system, files, registry, etc (unless you change their status to trusted or run them out of the sandbox which works out to be the same). Bo.
CWS, I just thought of something. Is funny how you want your browser (Chrome) to be like Sandboxie and I don't want my browser (Firefox) to be like Chrome (on the surface/under the hood). Bo
Use the 1806 (IE-zone) trick ------------------------------- Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3] "1806"=dword:00000003 ------------------------------- value 3 = block, value 1 = warn Just copy the text between lines to notepad and save as reg (registry) file. Iuse a IE_zone_block and IE_zone_warn shortcut in startmenu. When I want to download an executable, just click on E_zone_warn. Download the exectuble, remover the block (see picture), install and click on IE_zone_block again. Removing IE-zone block (see pic).
Well there is a trick, start Chrome under another (limited) user, apply parantial control for that user and delete the profile of that user. When you execute Chrome under this other user via psexec, you will get the following warning. When you want to recover a file, move (not copy) it in the shared folders (be sure to apply a deny execute ACL and LOW-IL with ICACLS to this folder) Can be done, just need some tweaking of the OS, but it is easier to use SBIE for it
Chrome's sandbox is built in browser and can only sandbox browser. It is not a system wide sandbox that could also sandbox other applications. For that, you will have to use SBIE or something similar.
Yes I mean something different. What I'm basically trying to figure out is if there is a difference between file-less malware running inside a process like a browser and malware that runs as a separate process that injects code into the browser. Let's say it's a banking trojan, HMPA, Trusteer and others can detect and/or stop the latter. Why wouldn't it be able to stop file-less malware? I suppose because according to you it does not need to alter browser behavior?
Yes, but normally HIPS monitor all activities if they are not already allowed. Moreover, I don't understand what malicious activity fileless malware can do: also if they are injected in memory or in " the process used for the exploitation " - see https://blog.malwarebytes.org/exploits-2/2014/09/fileless-infections-from-exploit-kit-an-overview/ - when the payload will work HIPS should anyway detect his activity. I only wish to understand this....
Sorry, WS, but on my Windows XP I only have this: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ I don't have "Zones" and that's about it.
But you still need to download the file from Chrome's browser, that's what I'm asking you can't really block and test the downloaded file, again you don't need Sandboxie since Sandboxie is for everything, while I'm asking here for the downloads of files through browser not through entire Windows file system. And since it downloads any/every file through browser, than Chrome should be able to have such restriction and be able to block file downloads, without using Sandboxie.
Why MBAE protect more than SBIE, does MBAE protect against downloaded malware? And IDK what "those" exploit you mean but exploit usually includes payload, and in this thread we're discussing when payload is in-mem malware. Also I repeatedly saying in this thread that well configured HIPS or sandbox actually can protect most of known in-mem malware. The thing is, still there's a hole which can't be filled by HIPS or sandbox approach. MBAE don't protect against eveything, there's no such thing in security. I can't get you at all, it is as if comparing web shield, behavior blocker, and NoScript and saying "web shield is the best because it blocked the most many threats!". Othres will dispute "Only BB can prevent 0day malware!" or "Oh, does it can block XSS? NS can!" then again "What about it, web shield can block phishing site", and so on and so on...
1806 trick is good complement. In my case, I use trusted zone to download executables. While I loosened restriction for this zone, still it is tighter than default "Medium-high". But I know your trick is not-to-use IE on normal operation, that is better in security!
