Note: Due to the historical date of this research, many product names have since been updated.
Threat Research Authors: Brian Baskin, Paul Drapeau, Chris Lord, Sarah Miller
A second supply-chain compromise of the Ask Partner Network (APN) is bringing to light how attackers are leveraging widely used general tools, such as toolbars and browser extensions, to conduct sophisticated targeted attacks, distribute malicious code, and maintain persistence in enterprises.
The latest APN compromise, detailed in this post, highlights how the continued ubiquity of potentially unwanted programs (PUPs) is increasing organizations’ attack surface and creating the need for better user education, more robust security hygiene, and immediate removal of unwanted programs.
Compromise History
In November 2016, our partner Red Canary reported on a supply-chain compromise of APN, distributors of the Ask.com toolbar. This compromise allowed malicious software to be signed and distributed as though it were a legitimate Ask software update.
APN responded quickly to address the problem, revoked the compromised certificate and distributed software updates to customers. This should have been the end of the story, but it unfortunately wasn’t.
One month later, Carbon Black detected and stopped an attack that originated from the APN Updater using malware signed with the certificate issued after the November incident. Analysis by the Carbon Black Threat Research team confirmed this to be a continuation of the earlier activity, and indicative of a sophisticated adversary based on the control of a widely used update mechanism to deliver targeted attacks using signed updates containing malicious content. The investigation revealed these activities to be part of a larger campaign spanning at least the end of 2016 and into 2017.
The attack also demonstrates a common risk with PUPs like toolbars and browser extensions. Unnecessary and unwanted software, while not necessarily malicious, increases an organization’s attack surface and exposes systems to additional threats. As this compromise illustrates, threats can extend well beyond software vulnerabilities. Widely distributed software, such as the Ask.com toolbar, is being repeatedly used for nefarious purposes.
Since December 2016, we have worked with APN to investigate this latest attack, share intelligence and monitor our install base for recurrence. APN addressed the problems leading to this attack, and we have seen no further suspicious activity across our customers since the December incident.
We are releasing details in this post to illustrate the sophistication underlying the attack, and so you can add appropriate controls and detection in your own environments.
Both Carbon Black and APN are committed to keeping their users safe and it is only by working together that we as an industry make that possible.
Compromise Timeline
On December 16 2016, a Carbon Black customer reported that CB Defense had detected an active breach of their environment. The attack started with Apnmcp.exe (b31e8146b37b6c54068437086e9bd4ed6a64f4cb65374dc71e88d9896457e89f), a component of the APN update process. This process connected to tbapi.search.ask.com and then immediately made an outbound connection to a virtual private server outside the United States and not associated with the APN environment. The updater then downloaded and ran ApnUpdateMgr.exe (d01c7abc39e1b24a76641b597426aa377db0e27369f32dfe3522f364cec4495b), a remote access Trojan that was signed with the APN LLC code signing certificate issued November 9, 2016.
This malicious process made an outbound HTTP connection to the same host and spawned a reverse command shell process. From that shell, the actor controlled the host remotely for almost 2 hours, downloaded additional tools, enumerated resources on the local network, moved laterally to other systems using stolen credentials, and established persistence mechanisms. No privilege escalation was required since the components of the APN software update process all run as system with full privileges on the compromised host.
CB Defense detected all of this activity and allowed the customer to review the attack timeline and carry out immediate response and containment activities. Clearly, key stages of this attack were preventable—and would have been stopped—but the affected systems were configured by policy to detect and not block threats.
PUPs to Pwnage in (Less Than) 60 Seconds
The Carbon Black Threat Research Team investigated the reported compromise with some interesting components and techniques that we wanted to share. We have warned about the dangers of Potentially Unwanted Programs and Applications (PUP/PUA) several times but this breach provides direct evidence that a threat actor is making use of PUPs and their infrastructure for more targeted and highly malicious activities.
Within one minute of gaining access to the target endpoint the attacker had launched a remote command shell and within 45 minutes of initial access they had captured credentials and were moving laterally in the network.
The customer had components of the Ask Partner Network (APN) software package (Apnmcp.exe b31e8146b37b6c54068437086e9bd4ed6a64f4cb65374dc71e88d9896457e89f) running on an endpoint. The threat actor used the software package to access to the environment.
The endpoint in question reached out for an update to the APN software and was immediately redirected to another IP address, external to the APN environment (shown as NJ below based on the headquarters of the hosting company, Vultr), which distributed a malicious binary (ApnUpdateMgr.exe (d01c7abc39e1b24a76641b597426aa377db0e27369f32dfe3522f364cec4495b) to the endpoint.
This binary, a downloader for a second stage trojan, was signed with a valid APN LLC signing credentials. These signing credentials are recent and were issued after APN was notified of a similar situation by Red Canary.
Several observations about the binary retrieved from the C2 IP make the Carbon Black Threat Research team believe that a threat actor had the ability to sign and inject malicious content into the APN update stream. This binary contains legitimate signature information including a certificate issued to APN at or around the time they were notified by Red Canary of a similar situation. This certificate has been used to sign over 200 publicly available binaries at this time based on publicly available samples. The malicious binary includes the following PDB strings, which also indicate its unauthorized nature:
E:测试apache2劫持2016-11-24downloaderloaderReleaseloader.pdb
测试 = “test” or “testing”
劫持 = “hijack”
After passing a number of checks this binary reaches out to the C2 server with the following URL pattern: http://45.76[.]221.212/logo.gif?1. This binary was the initial access into the target environment and was used to spawn command shells and deploy additional tools. Of note is the fact that the same IP address was used throughout the attack, from the initial backdoor download through to later phases of persistence, and lateral movement. This single VPS appears to be the complete attacker infrastructure.
Leveraging this access, the attacker immediately began interacting with the system via a remote command shell, enumerating the local users, mapping the local network, dumping credentials out of the system with a credential extraction utility and installed a batch file with encoded PowerShell commands into the registry Run keys as a persistence mechanism.
Along with the batch script, C:\ProgramData\System.bat, the attacker stored a binary file that contained raw, obfuscated shellcode. The PowerShell command in System.bat was used to load this shellcode into memory at system startup and execute it.
The decoded PowerShell content is shown in the figure below.
This shellcode has multiple layers of obfuscation, with the first layer described in the figure below.
This simply shows that the first 28 bytes of the file are used to decode the remainder by XORing each byte by 0xB4 across a total of 0x678A (26,506) bytes. The final result is another obfuscated file that ultimately it resolves to a full Remote Access Tool that is leveraged by the attacker.
Indicators
The following hashes are referenced in the article.
| Observed Name | SHA256 Hash |
| Apnmcp.exe | b31e8146b37b6c54068437086e9bd4ed6a64f4cb65374dc71e88d9896457e89f |
| ApnUpdateMgr.exe | d01c7abc39e1b24a76641b597426aa377db0e27369f32dfe3522f364cec4495b |
| System.bat | 083cf77766ce9e0c7378da74a1a729b380629b875fc791c37890850f5ecbf508 |
| system.bin | a3255ad4099745e791d85dc1a9b0917909a6b2e91d32b96911cb488e18a601d8 |
General Hygiene Recommendations to Mitigate
Check your environment for APN binaries with the filename apnmcp.exe, and examine any files that apnmcp.exe might have written to disk. If you have tools with the ability to connect network activity to specific processes, examine apnmcp.exe and its child process network activity.
We’ve included a list of static IOCs above, but it’s easy for an attacker to change IPs and hashes. Carefully consider any running processes and their relevant behavior. Reduce risk by banning or removing PUP/PUA from your environment.
