How does malware avoid AV's when using a simple DLL injection technique?

Question

As far as I understand it, a simple approach for a malware DLL injection would require 2 DLLs. The first for the DLL side loading, while the malicious DLL remains encrypted. And then this 'loader' would decrypt the DLL and inject the payload into a victims valid process using VirtualAllocEx, LoadLibrary, CreateRemoteThread and all that yadda. But how do malware authors get to avoid heuristic detection AFTER the payload has been decrypted? I mean, I don't think most (if any) malware authors are actually loading their DLL's directly from memory just after decrypting the payload. Rather they decrypt it and use the DLL decrypted path in LoadLibrary. But how come that they are successful in bypassing AV this way, since most AV's use hook functions into all these Windows API functions (LoadLibrary I'd guess is heavily monitored), and so even if the malware escaped static AND dynamic analysis in the first glance since the AV won't be able to sandbox the encrypted the DLL through the hijacked one (there are hundreds of simple techniques to avoid AV sandboxing to access the decryption phase, and if it doesn't reach the decryption phase, the sandbox simulation does not raise any alarms) how does it escape it when its time to actually inject the payload into a process?

Won't the AV grab the DLL path that Windows is being requested to load through LoadLibrary and re-scan it? And this time the payload will be a completely malicious and decrypted DLL, easily recognized by static signature and/or heuristic analysis thus raising the AV alarm? How come any malware ever passed any AV with this method? What conceptual part am I missing?

Answer 1

Malwares decode their payloads in memory and manually map their PE structure. The PE is a very simple format, it's doesn't take long to write a PE loader from scratch.

For an AV to be able to monitor a program memory it would either need to pause it periodically and inspect every page of its working area or hook the memory allocation and protection APIs and fiddle with the permission to intercept every write.
Either way that would slow down the programs so much that nobody would use an AV.

By working on memory malwares avoid the AV signatures check, the AV could intercept a call to CreateRemoteThread (and all the one thousand tricks that exploit other APIs or call directly into the kernel) but at that point only the thread starting address is known, that's not enough for the signature check.
By the way, a malware could simply inject the decoding stage in the target process, and since there are infinitely many encoding, the signature check will always fail.

AVs typically work by intercepting malwares when they are written to disk, launched, and when they communicate over the network. These are all relatively inexpensive hooks.
With heuristics and signature checks, they can block the malwares of yesterday.
But AVs are generally useless at catching unknown and updated malwares, so be more surprised when they block a malware than when they don't.
IoCs and base heuristic like "every script interpreted or file downloaded by an Office document is malicous" are far more effective than playing a cat and mouse game with injection techniques.

Almost all malwares want what your user can already access without the need to inject a privileged process (that is probably protected by its high integrity level) and an AV can't arbitrarily block DLL injections between low privileged processes as, alas, there are legitimate use cases for them.