Evading detection is a central consideration of attackers because if detected, defenders are likely to take action to stop the attack and prevent it again in the future.
5.3. EVADING DETECTION 68
5.3.1 Using Operating System Functionality
One of the ways in which attackers can live o the land is for them to employ existing OS tools to obtain data. Such data can include machine names and IP addresses from DNS, and user account names from centralised credential services, e.g., Active Directory or LDAP. As this functionality serves an essential purpose, it is not possible to remove or disable these without negatively impacting the functioning of the network.
As seen in OddJob in Section 4.2.1, reusing OS functionality allows for small payload sizes. This can increase the di culty of detection due to it being a very small component of network tra c. SeaPea shows ingenious use of the open syscall to run rootkit commands. As seen in Section 4.1.7 the NSA used WMI to gather information and in Section 4.3.6 it is used by the CIA for persistence, process creation, monitoring, and so on. Section 4.3.6 shows the use of PowerShell by the CIA. Mans eld-Devine (2017) writes that PowerShell attacks can avoid much of the scrutiny that security products pay to le-based malware and that WMI and PowerShell attacks have increased since 2016.
5.3.2 Anti-Forensics
New developers are encouraged to learn about how to avoid basic forensics (CIA, 2015a). This includes obfuscating string and data through the use of tools, e.g., Marble Frame- work, being cognisant of the dierence between temporary and permanent storage by using the latter for persistence and the former for storing more sensitive materials where it is harder for PSP to detect. Tools are made to delete themselves, preferably doing so in a "secure" manner i.e. so that it cannot be undeleted. Developers are encouraged to consider which parts of the tool need to be encrypted versus obfuscated during the design phase.
The CIA (2015e) provides an interesting discussion of Kaspersky Lab's exposé on the Equation Group and how they can avoid the same problems. They list not using custom crypto implementations to prevent highlighting the code during RE analysis. Scanning for and removing unique strings, e.g., PDB paths, from the binary prevents leaving arte- facts for forensic analysis to discover. Sharing custom code between tools (e.g., RC5 with negative constants and positive hashing techniques) and the use of command and con- trol domains allowed the tools to be tied together by the security researchers. Internal standards that mandate such implementations, e.g., the NSA's custom crypto standard, should also be avoided. Reuse of exploits requires tracking which exploits and techniques have been discovered by defenders and ceasing to use them in other tools to avoid their discovery and subsequent correlation of the tools by defenders.
5.3.3 Malware Development Techniques
The CIA (2015) provides many guidelines for developing malware. General requirements include stripping debug and build artefacts, obfuscating or encrypting any strings or con guration data that indicate the tool's functionality and not storing sensitive data, e.g., encryption keys, shell code or plain-text, in memory when not required. Timestamps should be in the US style format and compile, linker, build or access times must not re ect core US hours to prevent correlation with the US. Similarly, data or terminology that implicates the CIA or US government is forbidden.
The forensic footprint of the tool's disk usage should be documented to understand any examinable artefacts. To lesson the potential for these unnecessary reading, writing or caching data to disk should be avoided. Files should be encrypted and securely deleted. Magic headers or footers for encrypted les should be avoided as they can serve as sig- natures. Traces or artefacts should not be left on the target and an uninstall mechanism should be provided that removes les, injected threads and forked processes, registry keys, and services. This increases the di culty of RE and attribution during malware analy- sis. Tools should not attract attention by using unusual function names, hacker terms, generating blue screens, pop-ups, core or crash dump les when the application crashes. Similarly, they must not cause the target system to become unresponsive due to CPU or disk IO spikes nor experience screen hangs or ashes.
The use of encryption has su cient requirements that it requires its own document to detail them (CIA, 2013a). All collected data should be encrypted and network com- munications should use end-to-end encryption to frustrate network analysis and protect collected data. Due to multiple MITM attacks and aws in SSL/TLS protocols these should not be relied on as the sole means of encrypting transmitted data; instead data should be encrypted prior to sending it.
Standard protocols should be used and complied with to avoid standing out from normal tra c during network analysis by an IDS or person. The replaying of network tra c, e.g., command and control packets, should be prevented to protect operational entities. The timing and size of beacon and/or network communications should be varied to prevent a predicable pattern of packets and thereby increase the di culty of network analysis. Unused network connections should be removed to avoid assisting incident response and network analysis.
All versions of PSP/AV should be tested as the free and commercial versions may not be- have the same. Live Internet connections should be used as this can change the behaviour
5.4. CIRCUMVENTING SECURITY 70