10 Process Injection Techniques: Technical Survey Of Common & Trending Process Injection Techniques

Ten Process Injection Techniques: A Technical Survey Of Common And Trending Process Injection Techniques
By Ashkan Hosseini

Link: https://www.endgame.com/blog/techni...-technical-survey-common-and-trending-process

 

Nice overview of Process Injection Techniques

 

@Rasheed187 should love this article.

 

Endgame missed one DLL injection method which in my opinion is one of the worst. It is high jacking of dlls that are loaded and stored in the knowndlls and knowndlls32 kernel space global root table. These areas store the base OS dlls that loaded into every process at startup time.

http://resources.infosecinstitute.com/dll-hijacking-attacks-revisited/

 

Yep, great article. Seems like Endgame has one of the best blogs, everything is explained clearly. All HIPS should be able to tackle these type of code injection methods, but not all of them do. Probably the best way is to simply block important processes from being modified. Think of all processes that are allowed to connect to the network and all system processes. Methods 1 to 6 should be easily stoppable, method 7 to 9 are more difficult to detect. And method 10 isn't actually a code injection method, you can only perform API hooking after successfully injecting code, so it's the end-goal.

Yes good point. But I really need a home user version of the Endgame HIPS, it looks awesome LOL.

 

Endgame isn't a HIPS. It's a behavior blocker using the Next/Gen AI algorithms. In that regard, there are better solutions; namely Cloudstrike/Falcon.

 

AV-Comparatives did a stand-alone test of Endgame last month using its Real-World Protection test methodology: https://www.av-comparatives.org/endgame-2-3-11/

Result was 99.5% detection w/5 false positives. These results put it in the top tier of signature based solutions.

 

From @WildByDesign's link where things are spelled out clearly and in plain layman's terms in those selected demonstrations, it's not so unlike and quite the same techniques (although some might be different to meet compatibility with systems after Windows 98 used before on 32 bit Win 98.

Is it any surprise that if you look at matters with some objectivity and a bit closer, that even today, M$ code and it's internal branch layouts are no different than regrooving an old tire. They are using the same basics they regard as source with some modifications here and there but leave plenty of room for malware writers to make the most of that craft via the simplest of means if you ask me.

So glad that this forum and it's members seriously use their uncanny initiative to drill these points home on EXACTLY the why and where things happen as they do.

 

Well, I don't really make a difference between HIPS and BB. But too bad that companies like Endgame, Invincea and CrowdStrike don't make consumer versions, that would be the ultimate dream LOL. From what I read Endgame is really on point, I would probably pick them over other companies.

I really wonder how HIPS like SpyShelter and Comodo would fare against malware using these code injection methods, I'm afraid they will fail against many of them. It would also be interesting to see how AppGuard and MemProtect would perform. I'm guessing they would do better, because they simply block access to memory of certain processes.

 

Also check out these articles, in the 4th article you will see the API's that should be monitored to protect against browser hijacking:

https://www.endgame.com/blog/technical-blog/hunting-memory
https://www.endgame.com/blog/technical-blog/dropping-atombombs-detecting-dridexv4-wild

https://stackoverflow.com/questions/20656370/api-hook-detection
http://blog.elevenpaths.com/2013/11/hookme-tool-for-intercepting.html

 

The advanced OS technical knowledge required to use these effectively w/o borking the application makes their use impractical. For practical purposes, best to rely on a HIPS that employ such hook API detection implicitly with like contained in rule options such as "event interception, process modification, etc.."

 

I'm not sure what you mean with this? HIPS/BB are already capable of automatically blocking API modification, without any user interaction.

But to get back at code injection (which is needed to perform API hooking), I believe AppGuard and MemProtect have got the right approach. They can for example protect the browser against code injection by blocking memory access, so it doesn't matter which code injection method is being used. And they can also block the browser itself from modifying other processes, so if it gets exploited, it can't infect the rest of the system.

Sandboxie will do the same because it blocks inter-process communication. And that's the problem with HIPS like SS and Comodo, they will alert about certain code injection methods, but they can't monitor them all. And even if they could, they would generate lots of alerts.

 

You have your coffee this morning? You posted a link to a utility process for manually selecting which API's should be monitored. It was this type of activity I was referring to.

 

Yes, but it seems you don't understand what this tool is about. It's basically a banking trojan simulator. But instead of confusing you, I should have posted a link about an actual banking trojan, let's take Gozi as example, see first link.

In the article you can read which API's it's trying to hook. So it's needed not needed to monitor "thousands" of API's. BTW, they tried to make Edge more safer by blocking unsigned injections, FF and Chrome will also implement this, but apparently it's not bulletproof, see link number 2.

https://securityintelligence.com/go...build-to-inject-into-windows-10-edge-browser/
http://www.sekoia.fr/blog/microsoft-edge-binary-injection-mitigation-overview/

 

I would rate it "better than nothing" but a long way to go.

 

Yes, but it will for sure raise the bar. BTW, I believe that HIPS that are capable of detecting API hooking, are also looking at if injected DLL's are signed or not. This way they know when to block or alert, because AV's often hook the browser, and you don't want to interfere with that.

 

Vary it degree of detection with some only detecting global hooking explicitly via rule option. However, most are internally monitor for all API's used in process memory modification activities.

Some have like default rules, many do not. I wouldn't make any assumptions in this regard with actual user test verification needed.

 

Not all HIPS have got the ability to detect API hooking, which is different from global hooking. For example, ESET doesn't have this ability. Tools like Trusteer, HMPA, Zemana and SpyShelter do have this ability, and that is what made them stand out, when they introduced this feature. But all of them of course don't alert about AV's that are legitimately hooking the browser, that's what I meant.

 

Yes, it does. The difference is you can't monitor the API's individually. They are included in rule settings such as process debugging, event interception, and modification.

 

I don't believe that's the same thing, can you post a screenshot of it?

 

Here's a detailed analysis of Win32/Gapz which probably remains the most advanced bootkit every discovered: https://www.welivesecurity.com/wp-content/uploads/2013/04/gapz-bootkit-whitepaper.pdf

What makes Gapz unique is its ability to bypass any HIPS monitoring of its activities including the detection of hooking API's you're so obsessed with. Gapz worked equally well on both x86 and x64 OS versions. It was stuff like this that prompted MS to created Secure Boot and related protections in Win 8/10.

 

I'm not sure if it will be able to bypass all HIPS, but it sure is advanced as hell. But anyway, you didn't answer my question, can you post a screenshot of the behaviors that are being monitored by ESET? Because I really don't think it can detect API hooking.

 

I can't because its default HIPS rules are hidden and stored in such a way that only Eset techs can decipher them.

 

OK I see. But like I said, the stuff that you mentioned is not the same as the ability to block/detect API hooking, after code injection has already taken place. And to get back at the article, a few notes: Only methods, 1,2 and 5 are common and sometimes used by legitimate tools. The others are mostly only being used by malware. Also, method 5 isn't that dangerous, it's often used by key-loggers but you can easily defeat them with keystroke encryption, as offered by KeyScrambler, SpyShelter and HMPA.