This is basically Do's and Don'ts for a Malware author. Below table explains how a malware author can bypass different AntiVirus engines, by reversing the logic we can use similar concepts to detect the malware. Below pointers apply to PE files, Mach-O, ELF and other binaries.
DO obfuscate or encrypt all strings and configuration data that directly relate to tool functionality. Consideration should be made to also only de-obfuscating strings in-memory at the moment the data is needed. When a previously de-obfuscated value is no longer needed, it should be wiped from memory.
|String data and/or configuration data is very useful to analysts and reverse-engineers.|
|DO NOT decrypt or de-obfuscate all string data or configuration data immediately upon execution.||Raises the difficulty for automated dynamic analysis of the binary to find sensitive data.|
DO explicitly remove sensitive data (encryption keys, raw collection data, shellcode, uploaded modules, etc) from memory as soon as the data is no longer needed in plain-text form.
DO NOT RELY ON THE OPERATING SYSTEM TO DO THIS UPON TERMINATION OF EXECUTION.
|Raises the difficulty for incident response and forensics review.|
|DO utilize a deployment-time unique key for obfuscation/de-obfuscation of sensitive strings and configuration data.||Raises the difficulty of analysis of multiple deployments of the same tool.|
|DO strip all debug symbol information, manifests(MSVC artefact), build paths, developer usernames from the final build of a binary.||Raises the difficulty for analysis and reverse-engineering, and removes artefacts used for attribution/origination.|
|DO strip all debugging output (e.g. calls to printf(), OutputDebugString(), etc) from the final build of a tool.||Raises the difficulty for analysis and reverse-engineering.|
|DO NOT explicitly import/call functions that is not consistent with a tool's overt functionality (i.e. WriteProcessMemory, VirtualAlloc, CreateRemoteThread, etc - for binary that is supposed to be a notepad replacement).||Lowers potential scrutiny of binary and slightly raises the difficulty for static analysis and reverse-engineering.|
|DO NOT export sensitive function names; if having exports are required for the binary, utilize an ordinal or a benign function name.||Raises the difficulty for analysis and reverse-engineering.|
DO NOT generate crash dump files, core dump files, "Blue" screens, Dr Watson or other dialog pop-ups and/or other artefacts in the event of a program crash.
DO attempt to force a program crash during unit testing in order to properly verify this.
|Avoids suspicion by the end user and system admins, and raises the difficulty for incident response and reverse-engineering.|
|DO NOT perform operations that will cause the target computer to be unresponsive to the user (e.g. CPU spikes, screen flashes, screen "freezing", etc).||Avoids unwanted attention from the user or system administrator to tool's existence and behaviour.|
|DO make all reasonable efforts to minimize binary file size for all binaries that will be uploaded to a remote target (without the use of packers or compression). Ideal binary file sizes should be under 150KB for a fully featured tool.||Shortens overall "time on air" not only to get the tool on target, but to time to execute functionality and clean-up.|
|DO provide a means to completely "uninstall"/"remove" implants, function hooks, injected threads, dropped files, registry keys, services, forked processes, etc whenever possible. Explicitly document (even if the documentation is "There is no uninstall for this ||Avoids unwanted data left on target. Also, proper documentation allows operators to make better operational risk assessment and fully understand the implications of using a tool or specific feature of a tool.|
|DO NOT leave dates/times such as compile timestamps, linker timestamps, build times, access times, etc. that correlate to general US core working hours (i.e. 8am-6pm Eastern time)||Avoids direct correlation to origination in the United States.|
DO NOT leave data in a binary file that demonstrates CIA, USG, or its witting partner companies involvement in the creation or use of the binary/tool.
|Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and futureoperations and equities.|
|DO NOT have data that contains CIA andcover terms, compartments, operation code names or other CIA and specific terminology in the binary.||Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and futureoperations and equities.|
|DO NOT have "dirty words" in the binary.||Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question.|
USG - United States Government