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 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 artifact), build paths, developer usernames from the final build of a binary. | Raises the difficulty for analysis and reverse-engineering, and removes artifacts 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 crashdump files, coredump files, "Blue" screens, Dr Watson or other dialog pop-ups and/or other artifacts in the event of a program crash. (NOTE: This requires forcing a program crash during testing in order to properly verify) |
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. |
| 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 <feature>") the procedures, permissions required and side effects of removal. | 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 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. |
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 (aka jitter) of beacons/network communications. DO NOT send fixed size and timing packets. |
Raises the difficulty of network analysis and correlation of network activity. |
| DO proper cleanup of network connections. DO NOT leave around stale network connections. | Raises the difficulty of network analysis and incident response. |
Disk I/O
| Directive | Rationale |
|---|---|
DO explicitly document the "disk footprint" on target that could be potentially created by various features of a binary/tool. |
Enables better operational risk assessments with knowledge of potential file system forensic artifacts. |
| 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 utilize a secure erase when removing a file from disk that wipes at a minimum the file's filename, datetime stamps (create, modify and access) and its content. (Note: The definition of "secure erase" varies from filesystem to filesystem, but at least a single pass of zeros of the data should be performed. The emphasis here is on removing all filesystem artifacts used in a forensic analysis) |
Raises difficulty of forensic analysis. |
|
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. |
Dates/Time
| Directive | Rationale |
|---|---|
| DO use GMT/UTC/Zulu as the time zone when comparing date/time. | Provides consistent behavior and helps ensure "triggers/beacons/etc" fire when expected. |
| DO NOT use US-centric timestamp formats such as MM-DD-YYYY. YYYYMMDD is generally preferred. | Maintains consistency across tools, and avoids associations with the United States. |
PSP/AV
| Directive | Rationale |
|---|---|
| DO NOT assume "free" PSPPersonal Security Product (Anti-Virus) product is the same as a "retail" copy. Test on all SKUs where possible. | While the PSP/AV product may come from the same vendor and appear to have the same features despite having different SKUs, they are not. Test on all SKUs where possible. |
|
DO test PSPs with live (or recently live) internet connection where possible. NOTE: This can be a risk vs gain balance that requires careful consideration and should not be haphazardly done with in-development software. It is well known that an PSP/AV products with a live internet connection can and do upload samples software based varying criteria (some of which are unknown). |
PSP/AV products can display significant differences when connected to the internet vise not. |
Encryption
NOD 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