Early Cascade Injection: From Windows process creation to stealthy injection | Hacker News Reader

Early Cascade Injection: From Windows process creation to stealthy injection

outflank.nl

123 pointswsintra202215 comments

Great! We have been working on Windows Process (and COM) injection since 2003 [1][2][3]. I need to talk with the current development team about reviewing it with the EDR-Preloading technique. We have a driver also that suspends a new process before hooking it, we also hook existing processes.

Business-wise our work on this went down once Microsoft Detours was made FOSS even when our products has other capabilities. A good old thread is here [4].

[1] https://github.com/nektra/Deviare2

[2] https://github.com/nektra/Deviare-InProc

[3] https://github.com/nektra/RemoteBridge

[4] https://www.reddit.com/r/programming/comments/22crn0/gpl_alt...

Not all overriding and detouring is malicious. For instance, Steam detours Direct3D every time you launch a game in order to set up the steam overlay.

Windows offers "legal" ways of DLL injection, which is presumably what Steam does, and this article isn't about those methods.

As far as I know Steam doesn't do anything special like that and they are whitelisted by anti-cheat. Same goes for Discord's Direct3D hooks. These are often used for drawing on screen by hacks.

I'm surprised the call to WriteProcessMemory or creating suspended processes isn't being picked up, it usually gets you a lot of points on the "Detect binary as malware heuristic" detector

I suspect this is where Windows backwards compatibility bites them a bit. I've got a very old tool [1] that uses WriteProcessMemory and CreateRemoteThread to create a thread in the command process that launched it to remotely change the directory in that process.

It works to this day, despite looking exactly like what malware would do. My tool is nothing in the grand scheme, but I suspect I'm not the only one doing these sort of shenanigans, and no doubt some big important app is doing it and can't be bothered to fix itself, so MS is stuck supporting it.

[1] https://github.com/seligman/ccd

If the Windows API provides those functions in the first point, I guess there are good reasons to use them. Of course if you're watching out for malware, WriteProcessMemory looks very suspicious, but it's not enough to conclude you're in presence of malware.

Those functions are for use by debuggers, and by default you need administrator rights to call them.

They are not only for that. The documentation says:

  Typically but not always, the process with address space that is being
  written to is being debugged.

I don't really see why you'd need admin rights to do so. As far as the process being injected belongs to the same user and is not a protected process (DRM), OpenProcess will happily return a handle with PROCESS_VM_WRITE and PROCESS_VM_OPERATION rights as required by WriteProcessMemory.

On the other hand, if you want to inject a system process, you definitely need admin rights.

> OpenProcess will happily return a handle with PROCESS_VM_WRITE and PROCESS_VM_OPERATION rights

Only if the process calling it has SE_DEBUG_NAME privileges, which you must set by opening your own process and then calling AdjustTokenPrivileges. But that will fail unless you have the "Debug Programs" right enabled in the security policy.

The people who are selling those detectors are making holistic social experiences.

It’s not complicated, if you want to buy secure software, don’t use Windows.

This is a great writeup, thanks for posting it. The post mentions Early Bird APC is a fairly recent development, around 2018, but process injection has been around for a long time. Is there any theoretical work being done towards locking down processes against injection in more robust ways than simply making sure there is no temporal chance to inject a malicious code? I’m thinking something along the lines of CFI, but for processes instead of subroutines, would be useful if it could be made to work.

The whole reason this complicated method was researched is exactly because the traditional injection routes are locked down/easily monitored.

In a previous life where I had to find a way to stealthily inject Chrome (in the presence of good anti-viruses), the solution was to find an obscure type of Windows shell extension which if registered would automatically be loaded by Windows into Chrome without triggering an alert.

I can think of many reasons to do what you describe, none of them good.

Red teaming?

Reply on news.ycombinator.com