OK...actually there are 3 next parts already...I haven't seen them https://www.vmray.com/blog/sandbox-evasion-techniques-part-2/ https://www.vmray.com/blog/sandbox-evasion-techniques-part-3/ https://www.vmray.com/blog/sandbox-evasion-techniques-part-4/
Noteable "Sandbox evasions - Part 3" in the Blinding The Monitor section. The hook bypasses noted are also applicable to security software that do the same.
Good articles. and we all know the famous red pill johanna wrote. "Detecting generic hypervisor artifacts: The most famous one is redpill (“IDTR could not be virtualized”)" or was it the blue pill? https://en.wikipedia.org/wiki/Joanna_Rutkowska
Interesting, will do some reading, but do they also describe methods how to bypass sandboxing tools like SBIE?
OK, I see. But in order to remove hooks you probably need to run outside the sandbox, that's why it's hard to bypass sandboxes and virtual machines without using a kernel exploit.
Also note sandbox evasion I posted here: https://www.wilderssecurity.com/thr...atombombing-update.392391/page-4#post-2659985
Well, if some app refuses to run correctly inside the sandbox, you must already know there might be something wrong. I wouldn't be surprised if some malware is already Sandboxie aware.
In the example noted, they run just fine in the sandbox. That is the problem. They are designed to "out last" conventional sandbox analysis and then execute their malicious code.
I have to say that the articles primarily mention "behavioral monitoring sandboxes" rather than the confinement ones we used to know (sandboxie, ReHIPS, etc...). And it mostly identify hooks as vector. if the sandbox doesn't uses hooks (like ReHIPS ) , the risks are greatly reduced. you are right is some way but i will add that is more a case per case situation. take chrome and sandboxie; when chrome has a huge code modification, it can't run properly on Sbie. Doesn't mean something is trying to infect the system. They are already, they look for "SbieDll.dll" since it is injected in every sandboxed processes.
There an example of malware sandbox-aware : https://extreme-security.blogspot.com/2016/07/win32furtim-malware-with-galore-of.html
And one really has to differentiate between sandbox aware, virtual environment aware, and normal environment aware. For example, a Cerber ransomware can be coded with the awareness of something like the amount of Documents opened. In other words, the malware would not run in a fresh VM or even on a new computer where no Documents exist yet to be opened.
No surprise, but there's where HIPS come into play. If malware acts legit inside the sandbox, but does generate alerts when run outside, then something is wrong. Also, my rule of thumb is that if it can't run correctly inside the sandbox, then it's probably not a good idea to install it on the real system. But like you said, it depends on certain criteria, if it's a well known tool like Dashlane then it's probably still safe.
Indeed. HIPS are useful for that but if i don't need one on my system, i can get similar result with some process logging tools. yes exact, some software needs access to some critical areas of the system (especially admin tools) so they can't run at their full potential inside a sandbox. All depend of the users knowledge of the said software. Personally when i discover i new tool, i run it on a VM , if nothing seems suspicious, i run it in test real system machine then maybe i will use it on my main machine.
