Shellcode Placement

PE (EXE) File Format

Malware payload can be stored in one of the following PE sections: .data, .rdata, .text, .rsrc

NOTE: The compiler might decide to store global variables and constants in .text section anyway. There is no 100% sure method to determine where the data will be finally stored.

.data section

To store payload in .data section initialize global variable. This section is readable and writable.

unsigned char shellcode[] = { 0xde, 0xad, 0xbe, 0xef }
 
int main() { /* ... */ }

.rdata section

To store payload in .rdata section initialize global constant. This section in read-only.

const unsigned char shellcode[] = { 0xde, 0xad, 0xbe, 0xef }
 
int main() { /* ... */ }

.text section

To store data in .text (code) section, one must explicitly instruct the compiler to do this. This section is executable. It's good for small payloads.

#pragma section(".text")
__declspec(allocate(".text")) const unsigned char shellcode[] = {
    0xde, 0xad, 0xbe, 0xef
}
 
int main() { /* ... */ }

.rsrc section

Visual Studio has an option to embed binary resources (icons, etc.) into PE .rsrc section. This section is read-only. The payload cannot be accessed directly at runtime. Instead, several WinAPI functions (especially from libloaderapi.h) must be used to access it.

External Resources

Shellcode can also be kept outside the main executable file of the malware, in some other external resources (websites, cache files, config files). It then requires additional operations to access it. So on the one hand, AV won't detect shellcode in the executable file (because it's not there), but the malware leaves more traces by referring to external resources.

Actually, the only limitation is our imagination. Threat actors use all manner of ways to deliver shellcode through various channels.