A new Zeus variant targeting Salesforce.com – Research and Analysis

The Adallom Labs team recently discovered an unusual variant of the Zeus trojan that targets Salesforce users. We’ve been internally referring to this type of attack as “landmining”, since the attackers laid “landmines” on unmanaged devices used by employees to access company resources. The attackers, now bypassing traditional security measures, wait for the user to connect to *.my.salesforce.com in order to exfiltrate company data from the user’s Salesforce instance.

A few remarks before we dive in:

  1. Zeus is traditionally used to pilfer online banking credentials and transactions. As far as we know, this is the first time a Zeus variant has targeted enterprise SaaS applications for the purpose of data harvesting and exfiltration. Technically, this is not a sophisticated attack – its tailored SaaS data exfiltration capability is what we believe makes this variant significant. 

  2. This is not an exploit of a Salesforce.com vulnerability; this Zeus attack takes advantage of the trust relationship that is legitimately established between the end-user and Salesforce.com once the user has authenticated.

  3. When we searched for a MITRE CAPEC code to classify the attack pattern, we came up empty. We gratefully acknowledge Gunnar Peterson’s assistance in defining a new attack pattern classification for this scenario, and are working with MITRE on getting it added to CAPEC . I’ll update this blog with a link to the the entry when it’s live. I also wanted to thank Shahar Tal from the Checkpoint security research team for his assistance with this blog.

On to the good stuff…

A few weeks ago, high activity behavior on one of our customers’ Salesforce.com instances triggered an Adallom alert; a single user performed hundreds of view operations in a short period of time:

This anomalous event triggered the Adallom service to alert the company’s SOC team, notifying them of the suspicious activity by the user. This is a more-common-than-you’d-think “insider threat” alert, usually triggered by a technically savvy account rep “downloading” their Rolodex by mirroring their Salesforce.com instance to disk (or less frequently it could be just someone playing around with a script). Internally we refer to this behavior as “Rolodexing” (creative, we know).

When our customer’s corporate security team investigated the “rolodexing” incident, the employee disclaimed knowledge of the activities in question – he had no idea what they were talking about. The employee’s corporate laptop was found clean of malware, and he had no intention of leaving the company any time soon. At this point, our customer’s SOC team engaged Adallom Labs to assist with the investigation (cue Sherlock Holmes theme).

A quick analysis of our audit logs indicated that the offending device was mostly used during weekends and nights and was a Windows XP machine running an old version of IE. Long story short: It turned out to be that employee’s personally owned computer which they had been using from time to time (weekends and nights) to catch up on work.

But what was behind the crawl? A standard malware scan of the machine revealed, among countless adware and other junk, our first clue: it was infected by a Zeus variant (W32/Zbot). Not a big surprise since this was an unpatched IE running on XP and the “bundled” AV subscription expired long ago. A Petri dish like this can get infected on the internet very easily.

Further investigation revealed the missing piece – this Zeus variant was configured to detect Salesforce.com authenticated sessions (*.my.salesforce.com) instead of banking sites.

Though usually used as a financial malware, the Zeus code base and capabilities are highly versatile and, as seen in this case, can be used for other purposes as well. In fact, the Zeus webinject scripts are built using a specially crafted scripting language that enables the attacker to design sophisticated web injection attacks of any kind and on any site. Furthermore, while Zeus usually hijacks the user session and performs wire transactions, this variant crawled the site and created a real time copy of the user’s Salesforce.com instance. A copy of the temporary folder created (shown below) contained all the information from the company account. While our customer is still investigating the intent behind this attack, it’s easy to imagine how having real time access to a company’s CRM might be useful to its competitors’ sales process.

Since some of the Zeus parameters were hard coded, this doesn’t seem to be a large scale attack, and (again, still under investigation, so this is a hypothesis) it was probably used as a specially crafted tool as part of a larger attack. However, this same attack pattern could be easily replicated against any company using any SaaS application. Even more disturbing is the fact that all existing Zeus variants in the wild can be fairly easily re-purposed to steal information from SaaS applications, it’s just a matter of adding another webinject configuration pack.

This story’s not over yet; we have yet to figure out exactly how these machines were infected (we believe it was likely pharming) and who was behind the attack. Since we’re talking about a home environment, we have no network or device logs to further our investigation. We will continue to work with out customer’s security team on the sample analysis and attack forensics and we’ll update you as the investigation progresses.

SaaS: the new attack vector

Zeus, “the king of bots” as called by Symantec, is known to target mainly financial institutions, hijacking account credentials and injecting fake content into bank authentication pages. This is the first incident we’ve seen of this powerful, albeit antiquated, weapon turned against corporate SaaS accounts, revealing the weakness of current security controls in identifying attacks outside of the company perimeter. While this attack targeted Salesforce users, it’s important to consider that any SaaS based application could be easily targeted in this way, circumventing all enterprise security controls.

Most importantly (TL;DR)

1. This attack targeted a computer outside company control (in this case it was a family computer, but it could have easily been a kiosk).

2. The service abuse was not detected by any other existing victim or provider defensive controls.

In the world of SaaS, there are three main players: the SaaS vendors who supply the service, the company which buys the service and the end users which use it. While SaaS vendor security receives a lot of attention, most enterprise SaaS providers, like Salesforce.com, are highly secure organizations with state-of-the-art network security controls. But the security of SaaS users and usage largely falls to the customer under the shared responsibility model. Unsurprisingly, users are the weakest link. They access company resources outside of  IT’s reach and can be easily exploited. While some may believe the easiest solution is to simply disallow SaaS usage, the default nature of most SaaS applications is to allow any place/any device access without standardized user activity monitoring and anomalous behavior detection.

Banking institutions have already realized that when users access information from their own devices, the best working assumption is that the device is compromised. The European Network and Information Security Agency (ENISA) currently advises financial institutions to adopt security measures that assume all user devices are compromised. The case of SaaS applications is no different. Companies must assume that the user devices are compromised and deploy relevant security controls for better detection and prevention capabilities.

To sum things up - When was the last time you received a SaaS security alert from either your SIEM or SaaS vendor?

Don’t construe that as a dint on SIEMs or SaaS vendors – This attack raises a lot of other interesting questions, like:

As a security professional, how can you ever ensure 100% of external devices are not “landmined”?

How can a company using SaaS secure its usage if the device, network, and application are outside of IT’s purview?

We are currently under responsible disclosure with several SaaS vendors for other attacks that have impacted our customers. Some, like the Office 365 “Ice Dagger”, are sophisticated. Others, like this “landmine”, are not. However, they all target digital assets inside of SaaS applications because that’s where enterprise data is migrating. We’ve recently collaborated with EMC’s Davi Ottenheimer on a brief whitepaper that covers the particular gap introduced by SaaS adoption – it’s not rocket science, but it’s an important and of growing concern nonetheless – one that we are working hard to address and mitigate.

Lastly, we’ll be covering this and other attacks at our BsidesSF talk, and if you want to talk shop, we’ll be at the RSA conference as well (booth 2532).

27 Comments

  1. EJ

    Can you elaborate on the protections the company had in place for remote access by employees? Mgmt tends to put much faith in the fact there is a “secure” VPN tunnel in place. They tend not to comprehend the fact that malicious activity can traverse that tunnel just as easily as legitimate activity, once the tunnel is established. Some SSL VPNs have the ability to enforce minimum security standards of the endpoint attempting the remote connection: latest MS updates in place, an AV product in place with up-to-date signatures, specific browser versions being used, etc. Just wondering if this company had these provisions in place or not in order to gauge their usefulness. Instead of arguing theoreticals, which again are tough to comprehend the higher up the mgmt foodchain one travels, this might serve as a real-life example of do’s and don’t's for the purposes of educating and lobbying mgmt for better security standards to be enforced for remote connections.

    • Tal Klein

      The company had what one might call a “very good” security posture. The company’s field sales organization was internationally dispersed, so asking them to connect to Salesforce.com via VPN was a non-starter because it would have severely impacted the productivity of the field. That was one of the reasons they ditched their previous CRM to adopt Salesforce.com, so from the get-go they knew that people were going to access Salesforce.com (and Office 365) from unmanaged devices over insecure networks. Their main mistake was assuming that the SaaS providers would be accountable for 100% of the security issues associated with this type of off-perimeter usage, they were using SSO, two-factor, and encryption – but that did not protect them from this attack vector.

  2. EJ

    Thanks for the additional info, Tal. It eventually dawned on me my assumptions of a VPN connection in the mix were not applicable to the situation described. Definitely a talking point for remote access for many companies.

Leave a Reply

Your email address will not be published. Required fields are marked *