@Rasheed187 - this one is for you. https://www.infosecurity-magazine.com/opinions/api-hooking-evading-detection/
Thanks, remember that we discussed this extensively? HIPS should all of the ability to detect suspicious API hooking. So the best they can do, is to make a list of API's that are often being hooked by malware, and see if it makes sense to monitor it. Tools like Zemana, SpyShelter, Webroot and HMPA have the ability to block/alert about banking trojans that perform API hooking. The problem is that some API's are also being hooked by security tools, so how to avoid false positives, that's the biggest problem. But it's very cool if you can detect this stuff, because it means that you can interfere with malware that have already successfully performed code injection/memory modification.
With 10,000+ APIs in existence and malware authors each day finding something new to abuse in them, somewhat of a never ending "after the fact" effort.
Yes, but like I said before, malware will normally only hook the most important API's, because they are trying to achieve a goal, like process hiding and browser hijacking. For example MRG is great in developing smart code injection methods (online banking test), but they will always hook the same API's inside browser memory. So if you fail to block code injection, you still have a chance to save the day. That's why I'm disappointed that the developers from SpyShelter don't want to be tested by MRG, as if they are afraid they will fail.
@ itman You should read this excellent article about API hooking and other code injection methods from a company named Countercept. A direct link is not allowed I believe, so do a search for: "Memory Analysis (Whitepaper) Advanced malware detection in the enterprise"
Contercept's product is based on Volatility. Per the InfoSecurity article: In other words, it is a tool to either detect post malware breaches or analyzing malware in a lab environment. As far as Contercept's whitepaper, you have to give them you contact info to download it. I don't need their spam e-mail. Up load it to a file share and PM me the link and I will take a look at it. Ok, I found the whitepaper on the web. Again their EDR solution is - analyzing post malware breaches or analyzing malware in a lab environment. Also many AV solutions like Eset employ advanced memory scanning(AMS) to detect crap like this. The "rub" with sig. based solutions is they scan the inject code for the like. So if the code is 0-day, you're "up the malware river w/o a detection paddle." Conventional behavior solutions like Emsisoft need to first ID the malware as unknown or suspect upon download. At that point, they flag it for monitoring. So when the process memory injects another, they through an alert and let the user decide to block or allow. The Next Gen/AI do similar monitoring but use statistical analysis on prior process behavior to determine statistically if such code injection is safe or not. In reality, the code injection could be indeed benign. Bottom line - the real issue is not code injection per se but the fact that Windows allows it in the first place. If all processes were encapsulated assembler code, this problem wouldn't exist.
I did send you a PM with a direct link, you might have missed it. But yes, it's an advanced tool for memory analysis after the system has already been infected. But certain HIPS can block API hooking to avoid infection, but it might be a difficult job, because security tools are also using API hooks. So I guess these HIPS must find a way to identify legit hooking. Like I said before, I don't believe that tools like Eset and Emisoft can detect API hooking.
Forget to comment on this part, but I agree that Windows must give an option to block code injection. I believe they tried to do this with "Protected Processes" but this won't protect every process. I also wonder if they could design AppContainer in a way that it will block code injection. But some legit apps need to inject code in order to function, so "Module Code Integrity" also looks like a promising solution. I hope that HIPS will be able to utilize these options to protect against code injection, without the need to monitor ALL code injection methods which is impossible. https://www.crowdstrike.com/blog/ev...ilbreak-mitigations-unkillable-processes-and/ http://blog.nektra.com/main/2013/02/25/injecting-a-dll-in-modernui-metro-app-win8/ http://www.sekoia.fr/blog/microsoft-edge-binary-injection-mitigation-overview/
For now, they at least do give the user the ability to Block Office apps from injecting into process via the new Attack Surface Reduction feature. https://blogs.technet.microsoft.com...tack-surface-against-next-generation-malware/
Correct, but keep in mind that not only exploitable apps should be blocked from the ability to inject code, but every app/process should be blocked. So let's say you run some new video player, it shouldn't be able to inject code into the browser like Chrome/Firefox.
A good example of this is malware injects explorer.exe. Explorer.exe starts browser and also does process modification to it as part of normal processing and is allowed to do so. Game over since the malware is injecting its code into the browser at that time.
With MemProtect (thread) i'm protecting my vulnerable apps from reading or writing to the memory of other processes (this ofc includes explorer.exe) and they can't spawn any child-processes. Another approach is to "blacklist" anything from injecting into - for example explorer.exe (or any other important process) - and only "whitelisted dll's" are able to inject into it For example: LSASS.EXE memory protection testing with MemProtect: #230
I really need a tool like this and don't understand why other HIPS have never offered such a feature. Too bad about the missing GUI with MemProtect. Would also be cool if someone could test if it really blocks all memory reading and writing. Exactly, but the problem is that some legit software also injects code into explorer.exe, so that's why M$ has probably never bothered to protect it. Perhaps only "normal" code injection should be allowed, that is done via known methods.
One of the more innovated explorer.exe hijacks is: https://www.endgame.com/blog/techni...-technical-survey-common-and-trending-process
The following access operations are blocked: If an injection-method in #14 is using one of the above mentioned access operations on a protected process, it will be blocked.
It isn't. That why I posted it. The shared memory section of explorer.exe is accessible by all processes that communicate with it; i.e. anything that explorer.exe started. As such, it is highly doubtful that MemProtect would be monitoring it. As far as API's go, the malware uses SetWindowLong and SendNotifyMessage. Again, API's that MemProtect does not monitor.
Thanks for the info. So MemProtect basically is using the "protected process" feature. But I wonder if there are other methods. I don't believe AppGuard and Sandboxie use this feature to block memory reading/writing. That's indeed the question, but normally speaking the "protected process" method should block access to memory. But I'm not sure if you will break the system if you make explorer.exe a protected process.
