A Runtime Crypter always works with the same principle: It decrypts its payload, starts up a process in suspended state, inserts the payload and resumes the suspended process under false flag. All this happens with calls to Winapi functions like CreateProcessA, ReadProcessMemory. WriteProcessMemory etc.

And even tho the malware that gets injected by the Runtime Crypter might be hardly detected by any AV (because it's writting into RAM instead of on the disc): How can it be that a modern Crypter itself is not detected by AV? I mean even if I add a lot of junk code to change the Signature, the suspicious function calls abovementioned have still to be there. Heuristic analysis should technically be able to detect such malware, shouldn't it?

  • 1
    When a WinAPI/OS function gets called that is not a direct malware sign. Some techniques that are being used to obfuscate malicious usage of those functions are for example staged payloads. But even then modern AVs may be able to detect the malicious shellcode that is being downloaded. So then encoding and even encryption comes into play...
    – game0ver
    Oct 3 '19 at 22:55

You can inject a stub in your target file, and make that this stub would be metamorphic and so as when it will be loaded into memory, your pe will have a lot of differentt signatures. But it's very long to create and to realize.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.