Ask Partner Network Compromise: Operational Lessons on Software Supply Chain Risk

On 5 November, Red Canary detected suspicious activity associated with Windows applications distributed by the Ask Partner Network (a.k.a. APN, Ask.com, or simply Ask). Upon further inspection, we discovered that Ask’s software was being co-opted by a malicious actor to execute malicious software on victims’ endpoints.

Ask is self-described as providing “solutions to help software developers acquire and monetize users.” This class of software is commonly referred to as “adware,” a “potentially unwanted program” (PUP) or “unwanted software.” While unwanted software is legitimately installed and can be easily removed via Add/Remove Programs on Windows systems, it is classified as such because it almost always accompanies a sought-after program and is not installed intentionally. Ask is best known for its search toolbar, which was bundled with Oracle Java installers and updates for many years, making it one of the most pervasive unwanted software suites in the wild.

This attack was discovered by Red Canary and immediately reported to Ask. Red Canary would like to extend our thanks to the team at Ask, who worked around-the-clock to investigate and publish a software update to mitigate this threat.

Read Network World’s coverage on Red Canary’s identification of the Ask Partner Network compromise: Attacks to make Ask.com Toolbar a conduit for malware are nipped in the bud

Technical Details

On 5 November, Red Canary detected a number of Windows processes associated with Portable Executable (PE, or “binary”) files having abnormal extensions. This is actually very common. Many Windows applications provide binaries that have specific extensions other than .exe. When we see legitimate applications doing this we can easily attribute and suppress those binaries based on a number of criteria. Included in these criteria are:

• Was the binary written and/or executed by a digitally signed parent or installer? Digital signatures do not equate to explicit trust, but they provide some measure of attribution.
• Have we already adjudicated the binary or its parent in another customer environment?
• With what frequency does the binary occur in this customer environment? How about across all Red Canary customers?

The majority of the time we can quickly disposition the binary and its behavior based on this type of context. And in this case, most of the questions had passable answers:

• Attribution: The parent process was a signed Ask.com component apnmcp.exe.
• Adjudication: The parent process was first observed by us several months prior, albeit exhibiting its intended behavior(s).
• Frequency: The program is present on many systems in many of our customers’ environments.

Despite the answers being “correct” in all cases, we immediately recognized this behavior as anomalous in the context of this application.

For starters, we are not talking about .bin file or another common file extension. The binary and process in question were associated with a file named logo.png. Image files should be opened by other programs, but obviously should not execute on their own. The logo.png file appears to be signed as well, though we investigate any binary that is signed a little too recently for our liking.

Learn more about what Red Canary detects and why to learn our rationale for unwanted software detection.

This behavior alone was enough to justify alerting the customer. And upon further inspection it became immediately clear that we had a case of co-opted software update mechanism. Note the network connection initiated by logo.png, which was used to pull down 2-3 unique, later-stage binary files that were then executed by logo.png before logo.png itself was deleted from the disk.

Of the dozen victims that we observed, all of the first stage (logo.png) binaries were unique, but the later-stage payloads were the same across all victims. Our suspicion is that we caught this during the early stages of deployment or testing, as these processes took very few actions on the victim endpoints. This may have been intentional, or it may have been due to bad payloads or configurations.

View a table of all binary hashes (MD5), including both the affected Ask.com updater versions as well as corresponding malware payloads, at the end of this article.

Want to hear more from Joe on detection and response? View our on-demand webinar on IR program best practices.

Parting Thoughts and Operational Lessons

Keith McCammon, Red Canary CSO, commented: “The impact of this event was minimized by the combination of Red Canary’s ability to identify behaviors not easily detected by software alone, our customers’ ability to respond, and the software vendor’s diligence with respect to mitigation. But we cannot allow the impact of one event to mask the substantial risk that this class of attack exposes. A software supply chain attack targeting a vendor with this type of reach could easily infect thousands or perhaps millions of endpoints worldwide.”

The operational lessons that we can take from this are critically important:

• In the same way that administrators should harden system services by removing or disabling services that aren’t required, the same must be done with software. “It’s not harming me today” is not a winning strategy. Third-party software that isn’t required to meet a business need should be removed, without exception.
• None of these payloads were detected by anti-virus engines at the time of execution, and most have little or no coverage a week later. Do not rely on anti-virus to detect or mitigate any new or novel attack.
• Examination of binary files alone is not sufficient to detect any new or novel attack. Start looking at behaviors, and ideally start looking at behaviors relative to specific files or applications. If you can’t do this, find a partner or service provider who can help.

 Binary hashes (MD5)