How does process injection work? Self-injection? DLL injection?

[Alcinzal]

I'm trying to understand how process injection works, and I might be off here, so please correct me if I’m wrong. Let’s say we want to inject ethminer into svchost.exe. From what I gather, the process would go like this:

1. The main miner program starts svchost.exe in a suspended state.
2. It then injects the ethminer code (or bytes) into svchost.exe.
3. Finally, svchost.exe is resumed, now running the ethminer code.

This means that ethminer operates under the guise of svchost.exe, but svchost.exe itself doesn’t actually run its usual tasks alongside ethminer. They don’t coexist, rather, ethminer replaces what svchost.exe would normally do, while still appearing as svchost.exe.

Now, does this mean it's impossible for the main miner program to inject ethminer into itself? For example, if you have the miner program running as miner.exe, can miner.exe inject ethminer into itself, avoiding the need to create new processes?

This also got me thinking about DLL injection. Earlier, I managed to hide processes from Task Manager using this GitHub repo: HideProcessHook. From what I understand, it works by hooking and overwriting the NtQuerySystemInformation function, which Task Manager uses to retrieve the list of active processes. The hook allows us to modify the list and hide specific processes before Task Manager displays it.

Could a similar approach work with ethminer and xmrig? Instead of being executables, could they be compiled as DLLs that get injected into another running process or the main miner program itself, where they overwrite specific functions to run?

Not sure if this would create any benefits, just trying to think outside the box and look at various techniques for AV evasion.

[KRAFMA]

For the hide process you can use the rootkit , and for the itself inject yes is possible but more easy for find/dump ..... not sure unam want implant

[Alcinzal]

For the hide process you can use the rootkit , and for the itself inject yes is possible but more easy for find/dump ..... not sure unam want implant

Thank you, and yes you are correct. But it wasn't really something I was expecting Unam to implement, just wanted to discuss how these injection technique works and if they would have any benefits.

[UnamSanctam]

Yes you're correct, the miner currently uses the most common method which is process hollowing, previously it has also used other techniques such as ghostly hollowing and transacted hollowing. I changed it back to process hollowing since other methods started giving the same amount of detections (or even more) as process hollowing while not being as reliable.

Now, does this mean it's impossible for the main miner program to inject ethminer into itself? For example, if you have the miner program running as miner.exe, can miner.exe inject ethminer into itself, avoiding the need to create new processes?

That is possible to do, the most common way is to start a new thread in the current program and inject into that, the biggest problem is that then miner.exe will still be running, which means the miner can be easily found.

This also got me thinking about DLL injection. Earlier, I managed to hide processes from Task Manager using this GitHub repo: HideProcessHook. From what I understand, it works by hooking and overwriting the NtQuerySystemInformation function, which Task Manager uses to retrieve the list of active processes. The hook allows us to modify the list and hide specific processes before Task Manager displays it. Could a similar approach work with ethminer and xmrig? Instead of being executables, could they be compiled as DLLs that get injected into another running process or the main miner program itself, where they overwrite specific functions to run?

Yes that can be done, though that will in the end do mostly the same thing as what the miner currently does since it will still get injected https://github.com/ryan-weil/HideProcessHook/blob/master/HideProcessHookInjector/main.c. You can also load the DLL(s) with other methods such as DLL Hijacking (or DLL side-loading) but that also has its downsides, such as usually having to place the DLL(s) on the disk.

[Alcinzal]

Thank you so much for clarifying.

I have a few more questions surrounding AV evasion and the various injection methods:

1. One of the reasons I was considering self-injection was that when the miner was injected into processes like svchost.exe or cmd.exe, Defender would occasionally flag these processes as malicious and claim to have terminated them. This even happened with .exe set as a filetype exclusion. The miner process wasn't actually terminated though, which was weird. But this notification could potentially alert users, so I think I would have to add exclusions specifically for svchost.exe or the folder it was located in, even though I had already set exclusions in the ProgramData folder, which the miner process was located in. If it would inject into itself, would this problem still occur? Should note that this notification did not appear every time, just some times. Seemed random. I wonder what exactly was detected, how it was detected and why the process did not get terminated even though Defender said it did terminate it.
2. To be completely honest I’m not entirely sure how antivirus software detects malware beyond matching file hashes with a database of known malware. For example, if I have a virus.exe that initially isn’t detected as malicious, but following being spread over a few days/weeks, starts getting flagged, how does this happen? If antivirus programs can detect that it’s malicious later on, why wouldn’t they detect it the first time someone runs it? Or first time it gets scanned?
3. I assume that both your ethminer.exe and xmrig.exe files are heavily flagged by antivirus software. Shouldn’t it be possible for the antivirus to detect them immediately when they’re running, even if they’re injected into another process? I would think there is some sort of comparison possible between what's running in memory and whatever they have in a database of known malware. Perhaps this is what WD did when flagging the injected svchost.exe process, as mentioned earlier?
4. If I create a stub.exe that stores ethminer.exe and then injects it into svchost.exe, wouldn’t that raise red flags since I’m performing actions outside of the original executable’s scope? My thought was that if I injected ethminer.exe into stub.exe itself, it might be less suspicious because the stub.exe is staying inside its own territory.
5. Or if I used ethminer.dll and had stub.exe inject it into another process or into itself, would that be more effective in evading detection? I was wondering whether DLLs might be less likely to be flagged than executables, as viruses are usually not DLLs. Do DLLs and executables appear the same in memory, or do they differ? Since DLLs are not executed on their own but are used by other executables, could it be possible that if svchost.exe uses ethminer.dll in some way, it might not raise suspicion with antivirus programs? Since svchost.exe would appear to be functioning normally, even while using ethminer.dll?

Sorry if these questions seem incompetent. I must admit that it's a bit embarrassing how limited my knowledge is on antivirus detection and computer memory, especially judging by the fact that I have created stubs using memory injection, also being completely undetected from AVs. I guess I just don't grasp the fundamentals.

Thank you again Unam.

Edit: My first question might have been caused by the connection to the web panel, as I never tried it without the web panel. But I don't remember it happening when I first started out, but rather it started notifying after a little while, which could mean it started happening after my domain got flagged by abuse.ch.