Vault7: CIA Hacking Tools Revealed
Navigation: » Latest version
Owner: User #2064619
Draft Development Tradecraft DOs and DON'Ts
SECRET//NOFORN
General (e.g. all PE/Mach-O/ELF or other binary files)
| Directive | Rationale |
|---|---|
DO NOT have data that demonstrates CIA, USG, or its witting partner companies involvement in the creation or use of the binary/tool/etc in the binary. |
Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USGUS Government operations and equities. |
| DO NOT have data that contains CIA cover terms or operational names in the binary. | Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USGUS Government operations and equities. |
| DO NOT have "dirty words" (see dirty word list – TBD) in the binary | 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 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 of 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 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 crashdump, coredump, "Blue Screen", Dr Watson or other dialog pop-ups and/or other artifacts in the event of a program crash. | 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 freezing", etc) | Avoids unwanted attention from the user or system administrator to tool's existence and behavior. |
Networking
| Directive | Rationale |
|---|---|
|
DO use end-to-end encryption for all network communications. NEVER use networking protocols which break the end-to-end principle with respect to encryption of payloads. |
Stifles network traffic analysis and avoids exposing operational/collection data. |
| 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. | Protects the integrity of operational equities. |
|
DO use ITEF RFC compliant network protocols as a blending layer. The actual data, which must be encrypted in transit across the network, should be tunneled through a well known and standardized protocol (e.g. HTTPSHypertext Transfer Protocol Secure) |
Custom protocols can stand-out to network analysts and IDS filters. |
|
DO NOT break compliance of an RFC protocol that is being used as a blending layer. (i.e. Wireshark should not flag the traffic as being broken or mangled) |
Broken network protocols can easily stand-out in IDS filters and network analysis.
|
DO use variable size and timing of beacons/network communications. DO NOT send fixed size and timing packets. |
Raises the difficulty of network analysis and correlation of network activity. |
Disk I/O
| Directive | Rationale |
|---|---|
| DO NOT read, write and/or cache 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. | Disguises intent of file (collection, sensitive code, etc) and raises difficulty of forensic analysis and incident response. |
|
DO NOT perform Disk I/O operations that will cause the disk to become unresponsive to the user or alerting to a SysAdmin. |
Avoids unwanted attention from the user or system administrator to tool's existence and behavior. |
| DO NOT use a "magic header/footer" for encrypted files written to disk. All encrypted files should be completely opaque data files. | Avoids signaturing of custom file format's magic values. |
| DO NOT use hard-coded filenames or filepaths when writing files to disk. This must be configurable at deployment time by the operator. | Allows operator to choose the proper filename that fits with in the operational target. |
| DO have a configurable maximum size limit for writing encrypted output files. |
Avoids situations where a collection task can get out of control and fills the target's disk; which will draw unwanted attention to the tool and/or the operation. |
Encryption
Note: NODNetwork Operations Division publishes a Cryptography standard: "(C//NF) Network Operations Division Cryptographic Requirements". Besides the guidance provided here, the requirements in that document should also be met.
| Directive | Rationale |
|---|---|
SECRET//NOFORN