On 7th March 2017, WikiLeaks began releasing a series of leaks on the U.S. Central Intelligence Agency. .
You can read about the full details of the leak here.
Within the treasure trove of the disclosed information are some brief technical guidelines, rules for the production of malware. We’re going to take a look at exactly how the CIA builds state-of-the-art viruses and trojans. Their approach, outlined below, takes every possible precaution in the hopes of avoiding fingerprinting and hence preventing the detection of their clandestine activities. …
General Rules For All Malware
1. Obfuscate/Encrypt
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.
Rationale: String data and/or configuration data is very useful to analysts and reverse-engineers.
2. Delay De-Obfuscation/Decryption
DO NOT decrypt or de-obfuscate all string data or configuration data immediately upon execution.
Rationale: Raises the difficulty for automated dynamic analysis of the binary to find sensitive data.
3. Clean up your mess
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.
Rationale: Raises the difficulty for incident response and forensics review.
4. Obfuscate differently every time
DO utilize a deployment-time unique key for obfuscation/de-obfuscation of sensitive strings and configuration data.
Rationale: Raises the difficulty of analysis of multiple deployments of the same tool.
5. Leave no trace
DO strip all debug symbol information, manifests, build paths, developer usernames from the final build of a binary.
Rationale: Raises the difficulty for analysis and reverse-engineering, and removes artifacts used for attribution/origination.
6. Get rid of all the debugging stuff
DO strip all debugging output (e.g. calls to printf(), OutputDebugString(), etc) from the final build of a tool.
Rationale: Raises the difficulty for analysis and reverse-engineering.
7. Keep your secrets hidden
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).
Rationale: Lowers potential scrutiny of binary and slightly raises the difficulty for static analysis and reverse-engineering.
8.Be mindful of all exported data
DO NOT export sensitive function names; if having exports are required for the binary, utilize an ordinal or a benign function name.
Rationale: Raises the difficulty for analysis and reverse-engineering.
9. Don’t show any weakness
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.
DO attempt to force a program crash during unit testing in order to properly verify this.
Rationale: Avoids suspicion by the end user and system admins, and raises the difficulty for incident response and reverse-engineering.
10. Hide in plain sight
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).
Rationale: Avoids unwanted attention from the user or system administrator to tool’s existence and behavior.
11. Minify everything
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.
Rationale: Shortens overall “time on air” not only to get the tool on target, but also the time to execute functionality and clean-up.
12. Document everything
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
Rationale: 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.
12. Be loyal
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).
Rationale: Avoids direct correlation to origination in the United States.
13. Avoid being blamed
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.
Rationale: Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future US government operations and equities.
13. Seriously. Be loyal.
DO NOT have data that contains CIA and US government cover terms, compartments, operation code names or other CIA and US government specific terminology in the binary.
Rationale: Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future US government operations and equities.
14. Mind your language
DO NOT have “dirty words” in the binary.
Rationale: Dirty words, such as hacker terms, common shorthands may cause unwarranted scrutiny of the binary file in question.
Rules for Networking
1. Encrypt every connection
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.
Rationale: Stifles network traffic analysis and avoids exposing operational/collection data.
2. Don’t slack off
DO NOT solely rely on SSL/TLS to secure data in transit.
Rationale: Numerous man-in-middle attack vectors and publicly disclosed flaws in the protocol.
3. Once is enough
DO NOT allow network traffic to be re-playable.
Rationale: Protects the integrity of operational equities.
4. Stick to the standards
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. HTTPS)
Rationale: Custom protocols can stand-out to network analysts and IDS filters.
5. Blend in
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)
Rationale: Broken network protocols can easily stand-out in IDS filters and network analysis.
6. Chaos and Confusion are your friends
DO use variable size and timing (aka jitter) of beacons/network communications. DO NOT predicatively send packets with a fixed size and timing.
Rationale: Raises the difficulty of network analysis and correlation of network activity.
7. Cover your tracks
DO proper cleanup of network connections. DO NOT leave around stale network connections.
Rationale: Raises the difficulty of network analysis and incident response.
Rules for Disk I/O
1. Know thy malware
DO explicitly document the “disk forensic footprint” that could be potentially created by various features of a binary/tool on a remote target.
Rationale: Enables better operational risk assessments with knowledge of potential file system forensic artifacts.
2. Act only when necessary
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.
Rationale: Lowers potential for forensic artifacts and potential signatures.
3. Plaintext is a mortal sin
DO NOT write plain-text collection data to disk. Rationale: Raises difficulty of incident response and forensic analysis.
4. Doesn’t matter what it is, hide it.
DO encrypt all data written to disk.
Rationale: Disguises intent of file (collection, sensitive code, etc) and raises difficulty of forensic analysis and incident response.
5. Prevent recovery
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 that could be useful during forensic analysis
Rationale: Raises difficulty of incident response and forensic analysis.
6. Stay in the shadows
DO NOT perform Disk I/O operations that will cause the system to become unresponsive to the user or alerting to a System Administrator.
Rationale: Avoids unwanted attention from the user or system administrator to tool’s existence and behavior.
7. Don’t leave any signs
DO NOT use a “magic header/footer” for encrypted files written to disk. All encrypted files should be completely opaque data files. Rationale: Avoids signature of custom file format’s magic values.
8. Be a team player
DO NOT use hard-coded filenames or filepaths when writing files to disk. This must be configurable at deployment time by the operator.
Rationale: Allows operator to choose the proper filename that fits with in the operational target.
9. Stay in your lane
DO have a configurable maximum size limit and/or output file count for writing encrypted output files.
Rationale: 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.
Dealing with Dates or Time
1. Stay consistent
DO use GMT/UTC/Zulu as the time zone when comparing date/time.
Rationale: Provides consistent behavior and helps ensure “triggers/beacons/etc” fire when expected.
2. You didn’t forget about loyalty, did you?
DO NOT use US-centric timestamp formats such as MM-DD-YYYY. YYYYMMDD is generally preferred.
Rationale: Maintains consistency across tools, and avoids associations with the United States.
So there you have it. . From a statement to WikiLeaks, the source wishes to initiate a public debate about the security, creation, use, proliferation and democratic control of cyberweapons.
State sponsored agencies around world, not just the CIA, operate outside the bounds of the law with little oversight and a blank cheque. This leak has conclusively proven that the most powerful blackhats are the ones meant to be protecting us. The source is asking you - Are you okay with this?
Want to be a real hacker? Sign Up!
