Secondary Categories: 02-Malware

General:

  • 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.
  • 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.
  • 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.
  • 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.
  • DO strip all debug symbol information, manifests(MSVC artifact), 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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 β€œ) the procedures, permissions required and side effects of removal. 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.
  • 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.
  • 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 USG operations and equities.
  • DO NOT have data that contains CIA and USG cover terms, compartments, operation code names or other CIA and USG specific terminology in the binary. Rationale: Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.
  • DO NOT have β€œdirty words” (see dirty word list – TBD) in the binary. Rationale: Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question.

Networking:

  • 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.
  • 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.
  • DO NOT allow network traffic, such as C2 packets, to be re-playable. Rationale: 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. HTTPS) Rationale: 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) Rationale: 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 predicatively send packets with a fixed size and timing. Rationale: Raises the difficulty of network analysis and correlation of network activity.
  • DO proper cleanup of network connections. DO NOT leave around stale network connections. Rationale: Raises the difficulty of network analysis and incident response.

Disk I/O:

  • 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.
  • 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.
  • DO NOT write plain-text collection data to disk. Rationale: Raises difficulty of incident response and forensic analysis.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Dates/Time:

  • 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.
  • 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.

PSP/AV:

  • DO NOT assume a β€œfree” PSP product is the same as a β€œretail” copy. Test on all SKUs where possible. Rationale: 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 PSP/AV products with a live internet connection can and do upload samples software based varying criteria. Rationale: PSP/AV products exhibit significant differences in behavior and detection when connected to the internet vise not. Encryption: NOD publishes a Cryptography standard: β€œNOD Cryptographic Requirements v1.1 TOP SECRET.pdfβ€œ. Besides the guidance provided here, the requirements in that document should also be met.

Resources:

Also Check Out:

  • PLACEHOLDER