The Adallom Labs team recently discovered an unusual variant of the Zeus Trojan that targets Salesforce.com users. We’ve been internally referring to this type of attack as “landmining”, since the attackers targeted an employee’s unprotected family computer, essentially laying landmines, waiting for a user to connect to Salesforce.com in order to exfiltrate company data from the Salesforce.com instance.

A few remarks before we dive in:

1) This is a technically unsophisticated attack. Its tailored company data exfiltration capability is what we believe makes this variant significant. While Zeus is traditionally used to pilfer online banking credentials and transactions, as far as we know, this is the first time a Zeus variant in the wild has been found to target an enterprise SaaS application for the purpose of data exfiltration.

2) This is not an exploit of a SaaS application vulnerability. This Zeus attack is simply taking advantage of the trust relationship that exists between an end-user and the SaaS application once the user has authenticated. Only once that trust relationship is legitimately established does the attack truly begin.

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.

On to the good stuff…

A few weeks ago, high activity behavior on Salesforce.com at one of our customers triggered an Adallom alert. A single user performed hundreds of operations in just a few seconds, all of them simple View operations.

This irregularity triggered an automatic alert by Adallom to that company’s SOC team, notifying them of the suspicious activity. 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 the corporate security team investigated the “rolodexing” situation, the user disclaimed knowledge of the activities in question. The person simply had no idea what they were talking about. The user’s work computer was found clean of malware and it seemed they had no intention of leaving the company any time soon. At this point our customer’s SOC team, unable to make further progress, engaged Adallom Labs to assist with the investigation (cue Sherlock Holmes theme).

A quick analysis of the logs indicated that the crawling behavior didn’t originate from the employee’s work device. We could see 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 user’s spouse’s computer which was being used from time to time (weekends and nights) to catch up on work.

But what on that computer was behind the crawl? A standard malware scan on the machine revealed, among countless adware and other junk, our first clue: It was infected by Zeus, W32/Zbot to be exact (the open sourced version readily available on Github). Not a big surprise, this was unpatched IE running on XP and the “bundled” AV subscription expired long ago. A petri dish like this can get infected on the internet in less than 5 minutes.

Further investigation revealed the missing piece – the Zeus variant we found was configured to detect Salesforce sessions instead of banking sites.

Though originally created 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 simply crawled the entire site and created a real time copy of the company CRM. A copy of the temporary folder created (shown below) contained all the information from the company account. While we’re still investigating the intent behind this attack, it’s easy to imagine how having real time access to a competitors’ CRM might be helpful in one’s 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) 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 repurposed 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 how these machines were infected 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 the sample analysis together with Zeus experts and the Salesforce security team and update you as our 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. SaaS vendor security receives a lot of attention, and indeed most SaaS providers, like Salesforce.com, are highly secure organizations with state-of-the-art network security controls. However, the other side of the equation – the users, are largely ignored. The users are the weakest link, they access company resources, outside of the company protective reach and can be easily exploited. However, the SaaS dynamic enables 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 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).