Shamoon Mitigation Strategies

Wednesday, May 1, 2013 @ 05:05 PM gHale

Shamoon, an information-stealing malware that also includes a destructive module, renders infected systems useless by overwriting the Master Boot Record (MBR), the partition tables, and most of the files with random data. Once overwritten, the data are not recoverable.

Based on initial reporting and analysis of the malware, no evidence exists that Shamoon specifically targets industrial control systems (ICSs) components or U.S. government agencies. But it did total at least 30,000 hard drives at Saudi Arabia oil giant Saudi Aramco and also injured systems at Qatar natural gas player, RasGas.

Iran Offshore Platforms Targeted
Stuxnet Older than We Think
Cyber War Stakes Rising
Shamoon Target: Aramco Production
Stuxnet Hit 4 Oil Companies
Iran behind Shamoon Attack

Shamoon has three primary functional components, according to Symantec:
1. Dropper: The main component and source of the original infection. It installs a number of other modules.
2. Wiper: This module is responsible for the destructive functionality of the malware.
3. Reporter: This module is responsible for reporting infection information back to the attacker.

After the initial infection, Shamoon spreads via network shares to infect additional machines on the network. Symantec first detected Shamoon, or W32.DistTrack, August 16 and estimates only few infections exist worldwide.

Organizations that observe any suspected malicious activity should follow their established internal procedures and report their findings to ICS-CERT and US-CERT for tracking and correlation against other incidents.

Because of the highly destructive functionality of the Shamoon “Wiper” module, an organization infected with the malware could experience operational impacts including loss of intellectual property (IP) and disruption of critical systems.

ICS-CERT and US-CERT recommend the following mitigation strategies:

Tactical Mitigations
• Encourage users to transfer critical files to network shares, to allow for central backed up.
• Execute daily backups of all critical systems.
• Periodically execute an “offline” backup of critical files to removable media.
• Establish emergency communications plans should network resources become unavailable.
• Isolate any critical networks (including operations networks) from business systems.
• Identify critical systems and evaluate the need for having on-hand spares to quickly restore service.
• Ensure antivirus is up to date. There are reports antivirus does not detect some variants. However, updating signatures is still prudent.
• Disable credential caching for all desktop devices with particular importance on critical systems such as servers and restrict the number of cached credential for all portable devices to no more than three if possible. This can occur through a Group Policy Object (GPO).
• Disable AutoRun and Autoplay for any removable media device.
• Prevent or limit the use of all removable media devices on systems to limit the spread or introduction of malicious software and possible exfiltration data, except where there is a valid business case for use. This business case needs approval by the organization Chief IT Security Officer.
• Consider restricting account privileges. It is our recommendation all daily operations should be executed using standard user accounts unless administrative privileges are required for that specific function. Configure all standard user accounts to prevent the execution and installation of any unknown or unauthorized software. Both standard and administrative accounts should have access only to services required for nominal daily duties, enforcing the concept of separation of duties. Lastly, disable Web and email capabilities on administrative accounts. Compromise of admin accounts is one vector that allows malicious activity to become truly persistent in a network environment.
• Ensure password policy rules are enforced and Admin password values are changed periodically.
• Consider prohibiting hosts within the production environment or DMZ from sharing an Active Directory enterprise with hosts on other networks. Each environment should have separate forests within Active Directory, with no trust relationships allowed between the forests if at all possible. If necessary, the trust relationships should be one-way with the low integrity environment trusting the higher integrity environment.
• Consider deployment of a coaching page with click through acceptance; these are traditionally deployed in an environment to log the acceptance of network acceptable use policy or to notify users of monitoring. Coaching pages also provide some measure of protection from automated malicious activity. This occurs because automated malware is normally incapable of physically clicking an acceptance radial button. Automated malware is traditionally hardcoded to execute, then retrieve commands or additional executables from the Internet. If the malware is unable to initiate an active connection, the full train of infection is potentially halted. The danger still exists that the physical user will authorize access, but through the use of coaching pages, infections can be limited or at least the rate of infection reduced.
• Monitor logs: Maintain and actively monitor a centralized logging solution that keeps track of all anomalous and potentially malicious activity.
• Ensure all network operating systems, web browsers, and other related network hardware and software remain updated with all current patches and fixes.

Strategic Mitigations
• Always keep your patch levels up to date, especially on computers that host public services accessible through the firewall, such as HTTP, FTP, mail, and DNS services.
• Build host systems, especially critical systems such as servers, with only essential applications and components required to perform the intended function. Any unused applications or functions should be removed or disabled, if possible, to limit the attack surface of the host.
• Implement network segmentation through V-LANs to limit the spread of malware.
• Consider the deployment of Software Restriction Policy set to only allow the execution of approved software (application whitelisting).
• Recommend the whitelisting of legitimate executable directories to prevent the execution of potentially malicious binaries.
• Consider the use of two-factor authentication methods for accessing privileged root level accounts or systems.
• Consider deploying a two-factor authentication through a hardened IPsec/VPN gateway with split-tunneling prohibited for secure remote access.
• Deny direct Internet access, except through the use of proxies for Enterprise servers and workstations. Perform regular content filtering at the proxies or external firewall points of presence. Also consider the deployment of an explicit versus transparent proxy policy.
• Implement a Secure Socket Layer (SSL) inspection capability to inspect both ingress and egress encrypted network traffic for potential malicious activity.
• Isolate network services, such as email and Web application servers by utilizing a secure multi-tenant virtualization technology. This will limit the damage sustained from a compromise or attack of a single network component.
• Implement best practice guidance and policy to restrict the use of non-Foundation assets for processing or accessing Foundation-controlled data or systems (e.g., working from home, or using a personal device while at the office). It is difficult to enforce corporate policies, detect intrusions, and conduct forensic analysis or remediate compromises on non-corporate owned devices.
• Implement best practice guidance and policy to limit the use of social networking services at work, such as personal email, instant messaging, Facebook, Twitter, except where there is a valid business case for use, and this business case has been approved by the organization Chief IT Security Officer. If a valid business case exists for use, implement a guidance/policy that reduces the risk of data loss and malware threats.
• Minimize network exposure for all control system devices. Control system devices should not directly face the Internet.
• Place control system networks behind firewalls, and isolate or air gap them from the business network.
• When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPN is only as secure as the connected devices.

Leave a Reply

You must be logged in to post a comment.