Vault7: CIA Hacking Tools Revealed
Navigation: » Latest version
Owner: User #2064619
Development Tradecraft DOs and DON'Ts
SECRET//NOFORN
DRAFT
General (e.g. all PE/Mach-O/ELF or other binary files)
| Directive | Rationale |
|---|---|
DO remove all data that demonstrates CIA, USG, or its witting partner companies involvement in the creation or use of the binary/tool/etc. |
Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USGUS Government operations and equities. |
| DO remove all data that contains CIA cover terms or operational names. | Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USGUS Government operations and equities. |
| DO remove all "dirty words" (see dirty word list – TBD) | Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question. |
|
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 and only as they are needed. When a previously de-obfuscated value is no longer needed, it should be wiped from memory. |
String data and/or configuration data is 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, 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 for analysis of multiple deployments of the same tool. |
| DO strip all debug symbol information from the final build of a tool. | Raises the difficulty for analysis and reverse-engineering. |
| 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 obfuscate the importing/calling of functions that may leak sensitive information about tool functionality (e.g. VirtualAlloc, CreateRemoteThread, etc) | Raises the difficulty for analysis and reverse-engineering. |
| DO NOT export function sensitive function names; if exported are required for the tool, utilize an ordinal or a benign function name. | Raises the difficulty for analysis and reverse-engineering. |
Networking
| Directive | Rationale |
|---|---|
| DO end-to-end encrypt all network communications between tools and/or LPs | |
| DO NOT solely rely on SSL/TLS to secure data in transit. | Numerous man-in-middle attack vectors and publicly disclosed flaws in the protocol. |
| DO NOT allow network traffic, such as C2 packets, to be re-playable. |
Disk I/O
| Directive | Rationale |
|---|---|
| DO avoid reading, writing and/or caching data to disk unnecessarily. Be cognizant of 3rd party code that may implicitly write/cache data to disk. | Lowers potential for forensic artifacts and potential signatures. |
| DO NOT write plain-text collection data to disk. | Raises difficulty of forensic analysis. |
| DO encrypt all data written to disk. | Lowers potential for forensic artifact |
Encryption
| Directive | Rationale |
|---|---|
SECRET//NOFORN