Best Practices for Handling Destructive Malware

As previously noted above, destructive malware can present a direct threat to an organization’s daily operations, impacting the availability of critical assets and data. Organizations should increase vigilance and evaluate their capabilities, encompassing planning, preparation, detection, and response, for such an event. This section is focused on the threat of malware using enterprise-scale distributed propagation methods and provides recommended guidance and considerations for an organization to address as part of their network architecture, security baseline, continuous monitoring, and incident response practices. 

CISA and the FBI urge all organizations to implement the following recommendations to increase their cyber resilience against this threat.

Potential Distribution Vectors

Destructive malware may use popular communication tools to spread, including worms sent through email and instant messages, Trojan horses dropped from websites, and virus-infected files downloaded from peer-to-peer connections. Malware seeks to exploit existing vulnerabilities on systems for quiet and easy access.

The malware has the capability to target a large scope of systems and can execute across multiple systems throughout a network. As a result, it is important for organizations to assess their environment for atypical channels for malware delivery and/or propagation throughout their systems. Systems to assess include:

• Enterprise applications – particularly those that have the capability to directly interface with and impact multiple hosts and endpoints. Common examples include:
  • Patch management systems,
  • Asset management systems,
  • Remote assistance software (typically used by the corporate help desk),
  • Antivirus (AV) software,
  • Systems assigned to system and network administrative personnel,
  • Centralized backup servers, and
  • Centralized file shares.

While not only applicable to malware, threat actors could compromise additional resources to impact the availability of critical data and applications. Common examples include:

• Centralized storage devices
  • Potential risk – direct access to partitions and data warehouses.
• Network devices
  • Potential risk – capability to inject false routes within the routing table, delete specific routes from the routing table, remove/modify, configuration attributes, or destroy firmware or system binaries—which could isolate or degrade availability of critical network resources.

Best Practices and Planning Strategies

Common strategies can be followed to strengthen an organization’s resilience against destructive malware. Targeted assessment and enforcement of best practices should be employed for enterprise components susceptible to destructive malware.

Communication Flow

• Ensure proper network segmentation.
• Ensure that network-based access control lists (ACLs) are configured to permit server-to-host and host-to-host connectivity via the minimum scope of ports and protocols and that directional flows for connectivity are represented appropriately.
  • Communications flow paths should be fully defined, documented, and authorized.
• Increase awareness of systems that can be used as a gateway to pivot (lateral movement) or directly connect to additional endpoints throughout the enterprise.
  • Ensure that these systems are contained within restrictive Virtual Local Area Networks (VLANs), with additional segmentation and network access controls.
• Ensure that centralized network and storage devices’ management interfaces reside on restrictive VLANs.
  • Layered access control, and
  • Device-level access control enforcement – restricting access from only pre-defined VLANs and trusted IP ranges.

Access Control

• For enterprise systems that can directly interface with multiple endpoints:
  • Require multifactor authentication for interactive logons.
  • Ensure that authorized users are mapped to a specific subset of enterprise personnel.
    • If possible, the “Everyone,” “Domain Users,” or the “Authenticated Users” groups should not be permitted the capability to directly access or authenticate to these systems.
  • Ensure that unique domain accounts are used and documented for each enterprise application service.
    • Context of permissions assigned to these accounts should be fully documented and configured based upon the concept of least privilege.
    • Provides an enterprise with the capability to track and monitor specific actions correlating to an application’s assigned service account.
  • If possible, do not grant a service account with local or interactive logon permissions.
    • Service accounts should be explicitly denied permissions to access network shares and critical data locations.
  • Accounts that are used to authenticate to centralized enterprise application servers or devices should not contain elevated permissions on downstream systems and resources throughout the enterprise.
• Continuously review centralized file share ACLs and assigned permissions.
  • Restrict Write/Modify/Full Control permissions when possible.

Monitoring

• Audit and review security logs for anomalous references to enterprise-level administrative (privileged) and service accounts.
  • Failed logon attempts,
  • File share access, and
  • Interactive logons via a remote session.
• Review network flow data for signs of anomalous activity, including:
  • Connections using ports that do not correlate to the standard communications flow associated with an application,
  • Activity correlating to port scanning or enumeration, and
  • Repeated connections using ports that can be used for command and control purposes.
• Ensure that network devices log and audit all configuration changes.
  • Continually review network device configurations and rule sets to ensure that communications flows are restricted to the authorized subset of rules.

File Distribution

• When deploying patches or AV signatures throughout an enterprise, stage the distributions to include a specific grouping of systems (staggered over a pre-defined period).
  • This action can minimize the overall impact in the event that an enterprise patch management or AV system is leveraged as a distribution vector for a malicious payload.
• Monitor and assess the integrity of patches and AV signatures that are distributed throughout the enterprise.
  • Ensure updates are received only from trusted sources,
  • Perform file and data integrity checks, and
  • Monitor and audit – as related to the data that is distributed from an enterprise application.

System and Application Hardening

• Ensure robust vulnerability management and patching practices are in place. 
  • CISA maintains a living catalog of known exploited vulnerabilities that carry significant risk to federal agencies as well as public and private sectors entities. In addition to thoroughly testing and implementing vendor patches in a timely—and, if possible, automated— manner, organizations should ensure patching of the vulnerabilities CISA includes in this catalog.
• Ensure that the underlying operating system (OS) and dependencies (e.g., Internet Information Services [IIS], Apache, Structured Query Language [SQL]) supporting an application are configured and hardened based upon industry-standard best practice recommendations. Implement application-level security controls based on best practice guidance provided by the vendor. Common recommendations include:
  • Use role-based access control,
  • Prevent end-user capabilities to bypass application-level security controls,
    • For example, do not allow users to disable AV on local workstations.
  • Remove, or disable unnecessary or unused features or packages, and
  • Implement robust application logging and auditing.

Recovery and Reconstitution Planning

A business impact analysis (BIA) is a key component of contingency planning and preparation. The overall output of a BIA will provide an organization with two key components (as related to critical mission/business operations):

• Characterization and classification of system components, and
• Interdependencies.

Based upon the identification of an organization’s mission critical assets (and their associated interdependencies), in the event that an organization is impacted by destructive malware, recovery and reconstitution efforts should be considered.

To plan for this scenario, an organization should address the availability and accessibility for the following resources (and should include the scope of these items within incident response exercises and scenarios):

• Comprehensive inventory of all mission critical systems and applications:
  • Versioning information,
  • System/application dependencies,
  • System partitioning/storage configuration and connectivity, and
  • Asset owners/points of contact.
• Contact information for all essential personnel within the organization,
• Secure communications channel for recovery teams,
• Contact information for external organizational-dependent resources:
  • Communication providers,
  • Vendors (hardware/software), and
  • Outreach partners/external stakeholders
• Service contract numbers – for engaging vendor support,
• Organizational procurement points of contact,
• Optical disc image (ISO)/image files for baseline restoration of critical systems and applications:
  • OS installation media,
  • Service packs/patches,
  • Firmware, and
  • Application software installation packages.
• Licensing/activation keys for OS and dependent applications,
• Enterprise network topology and architecture diagrams,
• System and application documentation,
• Hard copies of operational checklists and playbooks,
• System and application configuration backup files,
• Data backup files (full/differential),
• System and application security baseline and hardening checklists/guidelines, and
• System and application integrity test and acceptance checklists.

Incident Response

Victims of a destructive malware attacks should immediately focus on containment to reduce the scope of affected systems. Strategies for containment include:

• Determining a vector common to all systems experiencing anomalous behavior (or having been rendered unavailable)—from which a malicious payload could have been delivered:
  • Centralized enterprise application,
  • Centralized file share (for which the identified systems were mapped or had access),
  • Privileged user account common to the identified systems,
  • Network segment or boundary, and
  • Common Domain Name System (DNS) server for name resolution.
• Based upon the determination of a likely distribution vector, additional mitigation controls can be enforced to further minimize impact:
  • Implement network-based ACLs to deny the identified application(s) the capability to directly communicate with additional systems,
    • Provides an immediate capability to isolate and sandbox specific systems or resources.
  • Implement null network routes for specific IP addresses (or IP ranges) from which the payload may be distributed,
    • An organization’s internal DNS can also be leveraged for this task, as a null pointer record could be added within a DNS zone for an identified server or application.
  • Readily disable access for suspected user or service account(s), and
  • For suspect file shares (which may be hosting the infection vector), remove access or disable the share path from being accessed by additional systems.
  • Be prepared to, if necessary, reset all passwords and tickets within directories (e.g., changing golden/silver tickets). 

As related to incident response and incident handling, organizations are encouraged to report incidents to the FBI and CISA (see the Contact section below) and to preserve forensic data for use in internal investigation of the incident or for possible law enforcement purposes. See Technical Approaches to Uncovering and Remediating Malicious Activity for more information.

Protective Controls and Architecture

• Deploy application control software to limit the applications and executable code that can be run by users. Email attachments and files downloaded via links in emails often contain executable code. 

Identity and Access Management

• Use multifactor authentication where possible, particularly for webmail, virtual private networks, and accounts that access critical systems. 
• Limit the use of administrator privileges. Users who browse the internet, use email, and execute code with administrator privileges make for excellent spearphishing targets because their system—once infected—enables attackers to move laterally across the network, gain additional accesses, and access highly sensitive information. 

Phishing Protection

• Enable antivirus and anti-malware software and update signature definitions in a timely manner. Well-maintained antivirus software may prevent use of commonly deployed attacker tools that are delivered via spearphishing. 
• Be suspicious of unsolicited contact via email or social media from any individual you do not know personally. Do not click on hyperlinks or open attachments in these communications.
• Consider adding an email banner to emails received from outside your organization and disabling hyperlinks in received emails.
• Train users through awareness and simulations to recognize and report phishing and social engineering attempts. Identify and suspend access of user accounts exhibiting unusual activity.
• Adopt threat reputation services at the network device, operating system, application, and email service levels. Reputation services can be used to detect or prevent low-reputation email addresses, files, URLs, and IP addresses used in spearphishing attacks. 

Vulnerability and Configuration Management

• Install updates/patch operating systems, software, and firmware as soon as updates/patches are released. Prioritize patching known exploited vulnerabilities.

Additional Resources

• For more information on Iranian government-sponsored malicious cyber activity, see CISA’s webpage – Iran Cyber Threat Overview and Advisories and CNMF’s press release – Iranian intel cyber suite of malware uses open source tools. 
• For information and resources on protecting against and responding to ransomware, refer to StopRansomware.gov, a centralized, whole-of-government webpage providing ransomware resources and alerts.
• The joint advisory from the cybersecurity authorities of Australia, Canada, New Zealand, the United Kingdom, and the United States: Technical Approaches to Uncovering and Remediating Malicious Activity provides additional guidance when hunting or investigating a network and common mistakes to avoid in incident handling.
• CISA offers a range of no-cost cyber hygiene services to help critical infrastructure organizations assess, identify, and reduce their exposure to threats, including ransomware. By requesting these services, organizations of any size could find ways to reduce their risk and mitigate attack vectors.
• The U.S. Department of State’s Rewards for Justice (RFJ) program offers a reward of up to $10 million for reports of foreign government malicious activity against U.S. critical infrastructure. See the RFJ website for more information and how to report information securely.

References

[1] CNMF Article: Iranian Intel Cyber Suite of Malware Uses Open Source Tools
[2] MITRE ATT&CK: MuddyWater 

Caveats

The information you have accessed or received is being provided “as is” for informational purposes only. The FBI, CISA, CNMF, and NSA do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply their endorsement, recommendation, or favoring by the FBI, CISA, CNMF, or NSA.

Purpose

This document was developed by the FBI, CISA, CNMF, NCSC-UK, and NSA in furtherance of their respective cybersecurity missions, including their responsibilities to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders. The United States’ NSA agrees with this attribution and the details provided in this report.

Appendix A: IOCs

The following IP addresses are associated with MuddyWater activity:

5.199.133[.]149
45.142.213[.]17    
45.142.212[.]61
45.153.231[.]104 
46.166.129[.]159 
80.85.158[.]49 
87.236.212[.]22
88.119.170[.]124 
88.119.171[.]213
89.163.252[.]232
95.181.161[.]49
95.181.161[.]50
164.132.237[.]65
185.25.51[.]108
185.45.192[.]228 
185.117.75[.]34
185.118.164[.]21
185.141.27[.]143
185.141.27[.]248 
185.183.96[.]7
185.183.96[.]44
192.210.191[.]188
192.210.226[.]128

Appendix B: Small Sieve

Note: the information contained in this appendix is from NCSC-UK analysis of a Small Sieve sample.

Metadata

Table 2: Gram.app.exe Metadata

Table 3: Index.exe Metadata

Functionality 

Installation 

Small Sieve is distributed as a large (16MB) NSIS installer named gram_app.exe, which does not appear to masquerade as a legitimate application. Once executed, the backdoor binary index.exe is installed in the user’s AppData/Roaming directory and is added as a Run key in the registry to enabled persistence after reboot. 

The installer then executes the backdoor with the “Platypus” argument [T1480], which is also present in the registry persistence key: HKCUSoftwareMicrosoftWindowsCurrentVersionRunOutlookMicrosift. 

Configuration 

The backdoor attempts to restore previously initialized session data from %LocalAppData%MicrosoftWindowsOutlookDataPlus.txt. 

If this file does not exist, then it uses the hardcoded values listed in table 4:

Table 4: Credentials and Session Values

Tasking 

Small Sieve beacons via the Telegram Bot API, sending the configured Bot ID, the currently logged-in user, and the host’s IP address, as described in the Communications (Beacon format) section below. It then waits for tasking as a Telegram bot using the python-telegram-bot module. 

Two task formats are supported: 

• /start – no argument is passed; this causes the beacon information to be repeated. 
• /com[BotID] [command] – for issuing commands passed in the argument. 

The following commands are supported by the second of these formats, as described in table 5: 

Table 5: Supported Commands

Any commands other than those detailed in table 5 are executed directly by passing them to cmd.exe /c, and the output is returned as a reply.

Defense Evasion 

Anti-Sandbox 

Figure 1: Execution Guardrail

Threat actors may be attempting to thwart simple analysis by not passing “Platypus” on the command line. 

String obfuscation 

Internal strings and new Telegram tokens are stored obfuscated with a custom alphabet and Base64-encoded. A decryption script is included in Appendix B.

Communications 

Beacon Format 

Before listening for tasking using CommandHandler objects from the python-telegram-bot module, a beacon is generated manually using the standard requests library:

Figure 2: Manually Generated Beacon

The hex host data is encoded using the byte shuffling algorithm as described in the “Communications (Traffic obfuscation)” section of this report. The example in figure 2 decodes to: 

admin/WINDOMAIN1 | 10.17.32.18

Traffic obfuscation 

Although traffic to the Telegram Bot API is protected by TLS, Small Sieve obfuscates its tasking and response using a hex byte shuffling algorithm. A Python3 implementation is shown in figure 3.

Figure 3: Traffic Encoding Scheme Based on Hex Conversion and Shuffling

Detection 

Table 6 outlines indicators of compromise.
 

Table 6: Indicators of Compromise

String Recover Script

Figure 4: String Recovery Script