I don't think so. It's beyond the Chrome's task, Chrome is not security software. However still they adopt download protection which blocks known bad files and low reputation files, not many browser adopt such thing. Also that's technically quite hard. Since Chrome is user-mode sandbox, it don't use kernel driver so if you want to run arbitrary software on that sandbox, you'll face serious usability issue and almost can't do anything unless that sandbox is specifically made and configured for your program. Kernel driver serves not only security but also usability and compatibility. Please give up a dream of all-in-one-and-mighty solution Please read my past posts in this thread.
Well, in the former case part of legitimate browser process (thread) suddenly become malicious when it loaded malicious content. We're on assumption that this exploit code was not detected by AV (signature or web shield). So AV don't know browser is affected. OTOH the latter case, a executalbe on the system try to inject thread into browser, this behavior itself will be prevented by HIPS as it will call some critical function such as CreatRemoteThread and AV with BB will also remember this and if browser begin to behave anomaly after that, it can be flagged. But yes, if AV don't detect the malware on disk even as suspicious (let's assume it has high reputation and AV vendor is not aware that update server was hacked),then it inserted thread into the browser and just tried to do seemingly normal action, i.e. send info via http request, then most probably AV won't detect it. This technique, embed malicious communication into http request, was used in MRG effitas test malware BABO and IIRC also real APT malware Turla, and you know BABO was not detected by even advanced MPS products. Well, still HIPS have a chance to prevent thread injection, in exploit case not. Maybe not only initial exploit, if this exploit then try to inject dll via some kinds of technique such as reflective dll injection, I doubt many consumer HIPS can detect and prevent it. In this case loaded dlls are nearly invisible, they come from memory and go into memory, so HIPS product have to dig in memory space.
I already said most known in-mem malware can be prevented by well configured HIPS or sandbox, and I'm mainly talking about exception that HIPS or sandbox can't fill in this thread. I hope my too long, abrupt past posts are readable for you, but in short, HIPS can't prevent exploited process to send info stored in browser memory to remote server via usual http request which itself is no different from usual legitimate browser behavior.
You mean data theft? That's the one thing Aigle kept posting about that even properly configured Sandboxie cannot protect against data theft.
Yes, I already read , but then I misunderstood the focus of the only thread; so, with a well configured HIPS - or sandbox - the only threat of this kind of malwares is the transmission of info and data by the browser temporary memory ?
So you think that Chrome should block downloaded file? From what? Saving file to disk? Running file? I have no clue what you would like Chrome to do. "Block and test downloaded file"? It will block it if it's in their blacklist or if you block downloads using 1806 trick as described before. It will not "test" it. You should do the testing. You can run it in Virtual machine or using Sandboxie. You can't test it by running it inside Chrome (or Chrome's "sandbox").
Yes, from saving to the disk. But also don't know how good is Google Chrome's security is against drive-by downloads, since it did let down on my friend's computer, however, after he put Google Chrome under Sandboxie's supervision, there has been no infection from drive-by downloads or anything else..
I don't know what kind of drive-by infection it was but I guess that your friend run something that they shouldn't. For cases when user is prone to infections I would add Sandboxie to browser, even Chrome. Not to "fix" browser's security but to protect user from their own mistakes and bad decisions.
Yes, to stop dll/thread injection by file-less malware you need anti-exploit. But let's say that anti-exploit fails: if the browser (or other exploited process) is running restricted (with low privileges and sandboxed) it would have a hard time doing any damage. But that's why it would be interesting to know if someone could write a file-less banking trojan (triggered by exploit), only then we would know if they would be able to steal passwords/data/money. I wonder why nobody has done this yet, I believe because it's probably too difficult, which takes me back to my first assumption that this threat is perhaps over-hyped.
Assuring "the only" is beyond my expertise, there might be sth I can't even think of. I'm not a security expert nor even tech savvy. But at least I can think of another more theoretical scenario. That is, attacker firstly exploit browser or plugin as a step, and next try to attack HIPS/sandbox itself or even OS kernel. Of course this can only be happen in targeted attack and still theoretical scenario. What real attack can be is all depends on what vulnerability in security software or OS is available, but usually many of them are only locally exploitable so attacker have to first exploit user application (of course installing malware by social engineering is viable option, but it's no relevant to file-less infection). Also usually such attack are done after drive-by download, but I think it can be done directly from compromised browser too as long as it has interaction with HIPS or OS kernel. Probably injecting dll into its memory make it easier than do it from shellcode. But there can be sth I missed or misunderstood, so any comment from experts is welcome.
No, anti-exploit won't stop dll injection or thread injection from in-mem malware. anti-exploit just stop such malware entering into system, and this is not related to injection, except the case shellcode try to inject dll into its memory. In that case, AE might stop that if it has EMET's Load Library like feature. Definitely no, from what I heard and understood such attack is much easier than bypassing sandbox or other really advanced attack. Only obstacle is disabling same origin policy, but it can be done if attacker already have arbitrary code execution. Don't forget most criminals attack for profit. In this regard, from the beginning in-mem malware (I say in-memory malware. I don't include in-registry malware in this discussion.) itself is not so attractive, as they can be easily removed and can't persist. The best benefit for in-mem malware is not avoiding detection, but that it don't leave traces. And even after attacker managed to infect the victim, what? just steal credentials from browser?? Are there any guarantee that such credentials are kept when attack is performed, or at least before he reboot computer? If banking site followed best practice, such credentials have to be deleted after banking session. Okay, infect banking site itself. But most banking site have relatively strong security, though it is not always applied to small provincial banking. So attacker infected provincial banking site. Then what he want to do, use in-mem malware? No, no, why don't infect the visitor by common banking trojan which can not only stole credentials but can do much more (and there're already many good cheap trojan in market)? To delay detection? Such banking site modification will be sooner or later found regardless of what malware he use, so don't make much sense. So we can see why FBI chose this way (they infected Tor user not for profit, and they want not to leave trace), but is this viable for other criminal?
I was too ignorant. In modern browser, not only all credentials in memory but also all cookies on disk are encrypted so what I said was impossible. Sorry for wrong claim. However, it seems still they (in-mem malware in this case) can steal credentials w/out hooking, by HTML injection. That is, inject a field which is originally not exist on the page into it, or even override original page so victim will be fooled and typed credentials will be stolen, this seems to be another major technique as well as API hooking.
Yes that's what I meant, when they disrupt the exploit in an early stage, they can stop injecting of code into the exploited process. But what you're saying is that we ain't seeing a lot of "file-less" malware attacks because they can easily be stopped or removed by browser restart or system reboot? I wonder if that's really true, I would love to see a "proof of concept" banking trojan or ransomware running completely inside browser memory. That would worry me a bit I have to admit.
Actually I guess the malware code injected here comes as dll. Even if it was not fileless, it might bypass classical HIPS as classical HIPS don't intecept some forms of dll loading( they do intercept many dll injections though). I think a sandbox is the good solution for these.
Yup, but ca be stopped but removed. Not suited for attack against general audience. I wonder how many consumer HIPS can block reflective dll injection since it has been long time from when it was demonstrated.
Some corporate AV/HIPS can detect and block it, so I won't be surprised if some consumer HIPS blocked. It is well possible if a product mess in the memory.
Good 3 page read on how Duqo 2.0, in memory only, pawned Kasperskys own corporate network for at least months before it was detected. http://arstechnica.com/security/2015/06/stepson-of-stuxnet-stalked-kaspersky-for-months-tapped-iran-nuke-talks/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+arstechnica%2Findex+(Ars+Technica+-+All+content)
I haven't read all the details yet, but aren't they using KIS on their network? HIPS + anti-exploit should have been able to stop this stuff.
One of the ways of infecting a host was by using CVE-2014-4148, This is was a TTF 0day which allowed an attacker to gain instant SYSTEM access. I have no idea whether anti-exploits are able to prevent this type of exploits (MBAE claims to offer some protection, but I cannot verify this). The easiest way to prevent these type of attacks would be to disable the embedding of custom fonts. From FireEye: https://www.fireeye.com/blog/threat-research/2014/10/two-targeted-attacks-two-new-zero-days.html the dropped malware is specifically customized for the targeted environment the dropped remote access capability is full-featured and customized: it does not rely on generally available implementations (like Poison Ivy) the dropped remote access capability is a loader that decrypts the actual DLL remote access capability into memory and never writes the decrypted remote access capability to disk I do not know whether FireEye was describing the Duqu 2 malware before it was discovered or whether their CVE-2014-4148 sample dropped another type malware.
They even could have developed and deployed a custom exploit for the AV itself, which is pure speculation on my part, but I doubt anyone would like to admit that.
I agree with you on that part, but I think that writing exploits purely based on AV's is just an immense waste of money.
