Windows Defender ATP thwarts Operation WilySupply software supply chain cyberattack

Credit to Author: msft-mmpc| Date: Thu, 04 May 2017 16:29:18 +0000

Several weeks ago, the Windows Defender Advanced Threat Protection (Windows Defender ATP) research team noticed security alerts that demonstrated an intriguing attack pattern. These early alerts uncovered a well-planned, finely orchestrated cyberattack that targeted several high-profile technology and financial organizations. An unknown attacker was taking advantage of a silent yet effective attack vector: the compromised update mechanism or software supply chain for a third-party editing tool. The software vendor that develops the editing tool was unaware of the issue. In fact, while their software supply chain served as a channel for attacking other organizations, they themselves were also under attack.

This cyberattack could have been much more problematic if it had gone undetected. Its early discovery allowed incident responders—a collaboration of security experts from the targeted industries and developers working for the third-party software vendor—to work with Microsoft security researchers to promptly identify and neutralize the activities associated with this cyberespionage campaign.

Thanks to the collaborative response, Microsoft was able to notify known affected parties as well as the third-party software vendor, who then worked around the clock to contain the attempted attack and mitigate potential risks.

Investigating alert timelines and process trees

Regardless of how an attack is executed, through sophisticated social engineering or a zero-day exploit, the first stage or the entry vector of a kill chain is often the most challenging aspect to understand about the attack. Windows Defender ATP initially called our attention to alerts flagging suspicious PowerShell scripts, self-deletion of executables, and other suspect activities. A quick check in the Windows Defender ATP console led us to the machine that was under attack. However, the source of the attack remained buried, requiring additional investigative effort to uncover.

By utilizing the timeline and process-tree views in the Windows Defender ATP console, we were able to identify the process responsible for the malicious activities and pinpoint exactly when they occurred. We traced these activities to an updater for the editing tool. We now had to look deeper into how this legitimate process might have been involved.

Figure 1. Initial alerts triggered by PowerShell activities as detected by Windows Defender ATP

Third-party updaters as attack vectors

During forensic analysis, an incident responder has to consider every possible explanation about how an attack took place. After ruling out a series of options—a local man-in-the-middle (MITM) attack, malware injection, or malware-bundled installers—forensic examination of the Temp folder on the affected machine pointed us to a legitimate third-party updater running as service. The updater downloaded an unsigned, low-prevalence executable right before malicious activity was observed.

The downloaded executable turned out to be a malicious binary that launched PowerShell scripts bundled with the Meterpreter reverse shell, which granted the remote attacker silent control. The binary is detected by Microsoft as Rivit.

Although it did not utilize a zero-day exploit, this cyberattack effectively compromised an asset. It took advantage of the common trust relationship with software supply chains and the fact that the attacker has already gained control of the remote update channel. This generic technique of targeting self-updating software and their infrastructure has played a part in a series of high-profile attacks, such as unrelated incidents targeting Altair Technologies’ EvLog update process, the auto-update mechanism for South Korean software SimDisk, and the update server used by ESTsoft’s ALZip compression application.

Another interesting aspect of this attack was that it only affected certain machines and ignored most of the machines that it could have targeted. To an extent, this made the investigation simpler—it resulted in a security incident that was effectively limited in scope. However, it is indicative of the more sinister intent to selectively attack the most valuable targets while keeping a low profile.

Commodity tools in a sophisticated attack

While the attack itself, including the selection of targets, appear to have been carefully planned, the attacker toolset comprised commodity tools and simple malware. These commodity tools are the same tools used in typical penetration testing exercises. The malware binary, named by the cybercriminals ue.exe, was a small piece of code with the sole purpose of launching a Meterpreter shell—a common pen-test tool—from a Base64/Gzip encoded blob downloaded using PowerShell.

Figure 2. Encrypted PowerShell command launched by the attacker binary using the updater

The use of commodity tools and common methods allow advanced attackers to evade clear attribution and hide activities amidst typical detection noise. They hinder threat intelligence systems from associating attacks with specific actors, who are often personified by unique techniques, tactics, and procedures (TTPs).

A review of the kill chain activities detected and recorded by Windows Defender ATP—network exploration, credential dumping, and lateral movement—revealed that all these activities were performed using either native system commands or scripted tools executed only in memory through PowerShell. Such in-memory techniques are becoming an increasingly common method by which advanced attackers avoid leaving obvious traces on the disk.

During this attack, we observed the following TTPs:

• Non-persistent, self-destructing initial binary
• Memory-only payloads assisted by PowerShell and Meterpreter running in rundll32
• Recon activities, including machine enumeration, using standard commands, such as NET, IPCONFIG, NETSTAT, NLTEST, and WHOAMI
• Migration into long-living processes, such as the Windows Printer Spooler or spoolsv.exe
• Use of common tools like Mimikatz and Kerberoast to dump hashes
• Lateral movement using Windows Management Instrumentation (WMI), specifically the WMIC /node command
• Persistence through scheduled tasks created using SCHTASKS and AT commands

Figure 3. Meterpreter payload used to open a reverse shell that gave control to the attacker

Operation WilySupply attack indicators

The following network addresses were actively used by the attacker to perform initial network scanning and command-and-control (C&C) communication:

• hXXp://5.39.218.205/logo.png (used for initial infection and C&C communication)
• hXXp://176.53.118.131/logo.png (used for lateral movement and C&C communication)

The same IP addresses were used with different URLs to download Meterpreter-based payloads. The logo.png files in the initial URLs contained the PowerShell scripts in base64-gzip encoding.

Figure 4. PowerShell script in base64-gzip encoding contained in the PNG files

The indicators for the malicious sample downloaded through the third-party updater are:

• Filename: ue.exe
• Size: 132.096 bytes
• SHA1: 75edd4ee11e7d3dabd191c316da637f939140e2f
• MD5: a34c930506b64f98cdf3ec2a474f5b31

We believe that the activity group behind Operation WilySupply is motivated by financial gain. They compromise third-party software packages delivered through updaters and other channels to reach victims who are mostly in the finance and payment industries.

A response network in action

Windows Defender ATP researchers worked closely with the Microsoft Cyber Defense Operations Center and the Microsoft Security Response Center to drive this attack to remediation, coordinating with the affected third-party vendor and the broader security community. After gathering evidence that an unspecified flaw in the software supply chain was being used in the attacks, Microsoft immediately notified the third-party software vendor. Their team neutralized the updater issue, dedicating resources to analyze logs and forensic evidence, collect additional attack indicators, and notify potentially affected parties.

Once we validated the indicators associated with this attack through collaboration with the affected vendor, we immediately shared indicator information with the security industry though our MAPP partnerships. We also shared our findings with trusted security partners, empowering a community of defenders to quickly respond to and track activities associated with this cyberattack.

To protect customers and expose attackers and their techniques, coordinated responses to sophisticated attacks need to happen across the software industry and other affected industries. During this attack, the collaborative response enabled everyone to promptly protect partners and customers.

Reducing the attack surface in software supply chains

To help contain the use of updaters as an attack surface, we have enhanced Windows Defender ATP to detect updater hijacks, including the activities described as part of this attempted cyberattack. To do this, Windows Defender ATP analyzes large sets of data to learn normal updater behavior and alert for deviations. In the example below, Windows Defender ATP has detected an updater designed to download only signed binaries suddenly downloading an unsigned executable.

Figure 5. Windows Defender ATP detecting anomalous updater behavior

Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge.

Microsoft encourages software vendors providing automatic updaters to review their code using SDL best practices and apply these security and hardening measures:

• Use strong encryption to protect update channels and to avoid being a target of attacks that use common pen-test tools like Evil Grade. Consider certificate pinning in the update protocol.
• Before running binaries downloaded from the update channel, always validate their digital signatures against your own certificates. Don’t allow blind execution.
• Place scripts and configuration files in signed containers. Unlike signed binaries, scripts and configuration files are often loaded unverified. Unless kept in signed containers, these files are prone to tampering.
• Be aware that clean, signed binaries might still allow malicious commands to be executed through the command-line. Likewise, web content used in the update process might allow execution of scripts when rendered.
• If your update process runs with higher privileges, don’t let it trust folders that can be modified with lower privileges such as the Temp folder. An updater process might inadvertently elevate privileges of arbitrary code that an attacker has placed in scripts, configuration files, or DLL files in these folders.
• Protect your update infrastructure from intrusion by applying regular security updates and getting critical mechanisms in place, such as a firewall, antimalware, 2FA authentication, and periodic log reviews.

Elia Florio
Windows Defender ATP Research Team

https://blogs.technet.microsoft.com/mmpc/feed/